Bug 2121093

+++ This bug was initially created as a clone of Bug #2111861 +++

This bug was initially created as a copy of Bug #2060513

I am copying this bug because: 
This affects the newly added nodejs:18 in RHEL as well.


Description of problem:

At least in upstream, node.js code includes some pre-compiled code as part of some modules that are bundled in the nodejs. Like undici.js [1]. I don't think this follows the guidelines that require "No inclusion of pre-built binaries or libraries" [2].

I'm not sure yet what to do with that though.

[1] https://github.com/nodejs/node/blob/2d6aea7ff5ba41fb564c719fc896847a31e16d0b/deps/undici/undici.js#L1311-L1324
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

--- Additional comment from Honza Horak on 2022-08-10 18:11:03 UTC ---

Zuzka/Jan, can you, please, share an update here what's the current status and next steps?

--- Additional comment from Jan Staněk on 2022-08-22 13:56:56 UTC ---

Current status: The pre-build blobs are still present in the current errata builds.We have statement from legal and waiting for statement/instruction from product security.

Current work: jstanek is working on making a libc available for WASM builds. zsvetlik is working on including llhttp package into RHEL, so we can start using it in place of the bundled dependencies.

Next steps: Depending on the prodsec statement, the source tarball will need to be adjusted to conform. We expect these changes to be manual for this release, and this release to have an "exception" in this regard. The next release should hopefully use blobs created from RH-built sources.
Longer term, we are working on an upstream-compatible process of linking/bundling/utilizing RH-built WASM without resorting to excessive patching of the NodeJS sources.

--- Additional comment from Jan Staněk on 2022-08-24 11:59:17 UTC ---

Since we are still working on remediation of this situation, and customers expect having NodeJS 18 available in the upcoming RHEL batch, I'm requesting an exception from the devel freeze. We will have to do errata respins to comply with the legal and prodsec requirements.

--- Additional comment from RHEL Program Management on 2022-08-24 11:59:25 UTC ---

A request has been made to complete this BZ as an exception (that is, after the deadline).  To facilitate review, the Product Owner (or a delegate) must provide an impact statement.  This is done by clicking the [reply] link on this comment, and then replying in-line to this message. 
 This must be done to facilitate review, even if the case appears to be obvious, or is already covered elsewhere in the BZ. The exception will not be reviewed until this is done.

======= Impact Statement ======= 

What is the benefit of making this change after the deadline? What is the impact on customer satisfaction, and on the business?

a. For bugfixes, there must be support from someone in Customer Support, a Partner Manager, Product Manager, and/or a Business Unit rep. (e.g., potentially from a layered product BU). 
b. It is unusual for new features to be allowed in the release after the deadline. For this reason, additional justification must be obtained from a stakeholder outside of the SST, to ensure an objective review of the benefit to the product. 

What is the risk to the release schedule, quality, and the impact of diverting resources from other efforts? Will there be enough time to do the necessary large-scale, cross-function, regression, stress, or fault-insertion testing that may be required to verify this change? 

============================= 

In addition to the impact statement above, check the BZ to confirm the following: 

1. The Internal Target Release (ITR) field reflects the correct release.
2. Set the Internal Target Milestone (ITM) field to indicate by when the work will be done. The approval for this exception will expire on that milestone. 
3. Ensure qa_ack+ and devel_ack+ are set, and that those acks are not leftover from before the exception request.
4. Prepare a RHEL rpm scratch build and have this change validated on the latest RHEL milestone compose by someone other than the developer. A comment must be added to the Bugzilla indicating the validation is successful and there were no observed regressions.

5. Provide reasoning why this request is being solved after regular DTD cycle. This will help us to assess & improve the exception process. 

All of these steps must be complete before this change is reviewed as an exception.

--- Additional comment from Jan Staněk on 2022-08-24 12:22:12 UTC ---

(In reply to RHEL Program Management from comment #4)
> ======= Impact Statement ======= 
> 
> What is the benefit of making this change after the deadline? What is the
> impact on customer satisfaction, and on the business?

Customers expect the latest major version released by upstream (the 18.y.z versions) to be available on RHEL in the next batch (and subsequently in containers). This version contains pre-built binary blobs that are not allowed to be shipped by general RHEL legal and security policies.
This change came late in the development cycle, and developers are still waiting for statements by product security teams on allowed course of action.
Without the exception, we will not be able to respin the respective erratas, and thus deliver the expected releases to customers.
 
> What is the risk to the release schedule, quality, and the impact of
> diverting resources from other efforts? Will there be enough time to do the
> necessary large-scale, cross-function, regression, stress, or
> fault-insertion testing that may be required to verify this change?

The DTM and ITM are set to minimize time impact of the exceptions, and to cause the least amount of delay deemed necessary.
The devel/QA resources will be diverted from work on the next Y-stream release; the general development window for that should be large enough that the next release shouldn't be impacted by this.

> ============================= 
> 
> In addition to the impact statement above, check the BZ to confirm the
> following: 
> 
> 1. The Internal Target Release (ITR) field reflects the correct release.
> 2. Set the Internal Target Milestone (ITM) field to indicate by when the
> work will be done. The approval for this exception will expire on that
> milestone. 
> 3. Ensure qa_ack+ and devel_ack+ are set, and that those acks are not
> leftover from before the exception request.

qa_ack review requested

> 4. Prepare a RHEL rpm scratch build and have this change validated on the
> latest RHEL milestone compose by someone other than the developer. A comment
> must be added to the Bugzilla indicating the validation is successful and
> there were no observed regressions.

There is older build available, but without addressing the issues outlined in this bugzilla.
Scratch build will be available once statements from other teams are ready. 

> 5. Provide reasoning why this request is being solved after regular DTD
> cycle. This will help us to assess & improve the exception process.

The binary blobs were discovered late in the development window,
and getting the relevant legal and prodsec statement takes longer than anticipated.
The issue is also a non-trivial one, and the research takes significant amount of time.

> All of these steps must be complete before this change is reviewed as an
> exception.