Repository navigation
Idea: #236 Standard grammar for node release lines and security #323
Description
I propose an addition to the alias specification:
An alias should never resolve to a version of Node.js with known security vulnerabilities
This would require that implementations of the alias's would need a way to look up which versions of Node have known security issues. What it would do is give the node ecosystem an even better way to support and test against known good versions of Node.
What do folks think about this addition?
Activity
ljharb commentedon Mar 3, 2020
This seems like way too high a burden to place on tooling; additionally, it adds legal liability if something claims to never resolve to known vulns, and then produces some.
This is the job of security ecosystem tooling imo, and very much outside the scope of what we're doing here.
wesleytodd commentedon Mar 3, 2020
Interesting point! Yeah that alone might make this unfeasible, but my thinking was that if node is doing a security patch, it knows which are the effected versions and could publish it somehow in the versions manifest. That said, it does bring along some unintended consequences and so maybe belongs in security tooling instead!
ljharb commentedon Mar 3, 2020
Additionally, most vulnerabilities don't apply to most use cases - ie, there's a lot of false positives - and it's not actually helpful for the ecosystem to desensitize people to security updates. This is a problem that already exists, but I wouldn't want us to make it worse.
wesleytodd commentedon Mar 3, 2020
Sure! but for most folks just saying "these should be avoided in general" is a great best practice. And for almost all use cases this is done by just following the tip of LTS. So I am not sure how this would make it worse. The goal is just to make it eaiser for folks to stay on that edge.
MarcinHoppe commentedon Mar 3, 2020
What kind of tooling do you mean?
dominykas commentedon Mar 3, 2020
But all of the keywords already resolve to the latest version in the major release line? And the
allkeyword resolves to unmaintained versions, which do have known vulnerabilities?There's also the case of the latest version containing known vulnerabilities and defining what's a vulnerability anyways.
wesleytodd commentedon Mar 3, 2020
I think you all bring up good points. I think I opened this prematurely. My thought was that for the ones where there is a list, if someone was building logic based on that list (like in a CI pipeline) it would be good to help them avoid versions with security voulns. I think the phrasing in #236 is a bit unclear because it says "All releases". I think maybe we should say "the latest version of each release line" or something like that.
Also, side note, do we have a doc on this? I couldn't find one, but it seems like what is in that issue should be made into a doc draft, right?
dominykas commentedon Mar 3, 2020
Not an explicit one - it's the table in the support levels doc. I think it's worth having a separate doc for this.