Idea: #236 Standard grammar for node release lines and security

[wesleytodd]

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?

[ljharb]

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]

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]

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]

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]

This is the job of security ecosystem tooling imo, and very much outside the scope of what we're doing here.

What kind of tooling do you mean?

[dominykas]

But all of the keywords already resolve to the latest version in the major release line? And the all keyword 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]

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]

do we have a doc on this

Not an explicit one - it's the table in the support levels doc. I think it's worth having a separate doc for this.