+++ This bug was initially created as a clone of Bug #2121075 +++
This now affects the nodejs:16 stream(s) as well (at least as of version 16.16.0).
+++ 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.