Repository navigation
Security releases and coordinated release #1047
Description
The current security practice for nodejs project is to notify everyone of upcoming security release approximately a week in advance and then do a release centered around these security issues only. The security issues could be Node specific or in the currently bundled 3rd party dependencies.
Security notifications are limited to members of https://groups.google.com/g/nodejs-sec
There are two-fold issues here when it comes to Linux distros (or BSD),
- most distributions are subscribed to issues via oss-security mailing list - https://oss-security.openwall.org/wiki/mailing-lists/oss-security . CC'ing this mailing list would raise awareness of security issues.
- coordinated release dates (CRD) for embargoed bugs via https://oss-security.openwall.org/wiki/mailing-lists/distros
Regarding the second point, and I will use OpenSSL as an example, normally 1 week prior to a public release of a security fix, a member of openssl project would mail the distros mailing list a description of the bug along with pending patches. This allowed distributions to analyze these issues and backport fixes while keeping the issue non-public. Then when the issue is made public (generally by same person that sent the embargoed report in the first place), distributions are ready with the fixes, or at least they've had some time to analyze the impact. There is a header-only archive where you can see this followed few days later by public announcement,
https://www.openwall.com/lists/linux-distros/2020/12/01/8
https://www.openssl.org/news/secadv/20191206.txt
The question that remains is Why? The main answer is that the lifecycle of Node releases in some distributions is longer than the LTS lifecycle in the nodejs project. At SUSE we still have nodejs8 maintained for some customers. Furthermore, the release process needs to account for additional testing by distributions which also requires time. A few days advance warning would prevent this race between the issue being public and being fixable by all the integrators. This was especially important in more visible linux kernel or openssl issues in the recent past.
Finally, this is not about the 3rd party bugs, like bugs in V8 or OpenSSL or ICU (since those issues are public before being fixed in Node), but reserved to the core node code.
So, my questions here are,
- would NodeJS project consider using CRD via the already curated security-centered web-of-trust that is the distros mailing list?
- could oss-security ML be cc'ed when there is a security release from node?
Activity
Trott commentedon Jun 28, 2021
@nodejs/security @nodejs/releasers
MylesBorins commentedon Jun 28, 2021
I think this should likely be transferred to https://github.com/nodejs/release for discussion by the release wg
richardlau commentedon Jun 28, 2021
I dunno, it feels like this is more security policy rather than a release policy (that's not to say we can't also discuss this in the Release WG).
targos commentedon Jun 28, 2021
I vaguely remember an existing related discussion. It was more generally about giving early access to security patches to some trusted entities.
Trott commentedon Jun 28, 2021
@nodejs/distros
Trott commentedon Jun 28, 2021
Same and I'm frustrated I can't find it now.
mhdawson commentedon Jun 28, 2021
With my TSC "hat" on:
the project has always been open to these, but what has been missing are people who are willing to champion them
and help do extra work/co-ordination etc.
take effort to work through and then there is likely going to be additional ongoing work to support additional
process.
Putting on my Red Hat "hat".
championing this on our own would make sense. The answer has been that it would be more of a "nice-to-have" and
have no current plans to do so by ourselves.
Looking at the specific requests:
is the distros mailing list?
The second one is a small extension on what we do, and is reasonable to be PR'd into https://github.com/nodejs/node/blob/master/doc/guides/security-release-process.md (@danbev please sanity check me on this one as somebody else who has stewarded security releases).
The first one I think would require people from the distro's most interested getting more involved in the Node.js project
and then helping to champion and support the execution of the required co-ordination, planning etc. It's been proposed/discussed in the past but without somebody willing to champion and take on the work the discussions have stalled out.
danbev commentedon Jun 29, 2021
Yes, this sounds like something we could do 👍
doc: add cc oss-security@lists.openwall.com
AdamMajer commentedon Jun 29, 2021
Indeed, this would be an unattainable task for a single project hence the mention of the distros mailing list. It's already self-organized.
https://github.com/nodejs/node/blob/master/doc/guides/security-release-process.md
In the process that already exists, during the per-annoucement the patches already exist and the CVEs are assigned. The planned release date is already, well, planned and within the maximum embargoed timeframe. My request here is to forward the patches for medium and higher priority CVEs to the distros ML at the time of the pre-annoucement. Further co-ordination is not really required on the part of the project.
Regarding additional work, I understand that every addition to the security release process is like adding straw camel's back. If desired, I could help in coordinating this with distros in the future, though I'm not involved in the day to day activity of either nodejs nor am I a member of distros (we do have people at SUSE that are members).
In many ways this is a wishlist issue. All security issues in Node have been very well handled and are not difficult to backport thanks to their unit tests that accompany them.
mcollina commentedon Jun 29, 2021
The technical reason why we cannot do this at this time is that the patches are not final when we announce the security release. We cannot run CI for the security patches until we lock down CI for the security release. Adding the requirement to announce the patches one week before the release would lock our CI for 2 weeks instead of one.
Ideally this should not be needed and we would have the means to run CI for the security fixes in a secure way. However this is not possible right now and I do not think we have the bandwidth or resources to do it.
mhdawson commentedon Jun 29, 2021
Since @AdamMajer has said using CRD is a "wishlist" issue, my take would be that we add the extra CC to our process and leave it at that until there is a strong need/champions to do more. @danbev do you want to PR the change to the security process or should I do that?
danbev commentedon Jun 30, 2021
I created nodejs/node#39191 for this yesterday 👍
AdamMajer commentedon Jun 30, 2021
Thank you for the explanation. Since there are still technical issues here, the issue with the CRD should probably be punted into the future for now.
mhdawson commentedon Jun 30, 2021
@danbev thanks!
@AdamMajer thanks for the follow up. Since @danbev has opened the PR to add the CC is there anything else we should discuss before closing out this issue?
doc: add cc oss-security@lists.openwall.com
AdamMajer commentedon Jul 1, 2021
@mhdawson I believe everything has been discussed now.
doc: add cc oss-security@lists.openwall.com
doc: add cc oss-security@lists.openwall.com