doc: describe OpenSSL maintenance strategy

[sam-github]

This replaces #479

[sam-github]

I wish I made this a draft PR, but I don't seem able to change it after the fact.

I updated some text with current information about OpenSSL reease strategies, since OpenSSL 1.1.1 has been released, and has been designated LTS and support until 2023 has been committed to.

I have started to add information about OpenSSL 3.0.0 and FIPS.

I have not yet added information about TLS1.3 strategy.

All of which is to say, probably not worth reviewing yet.

[sam-github]

@shigeki re: #479 (comment)

You bring up a couple issues:

1. I believe you already updated the assembler requirements in node.js master, and this doesn't require mentioning in the policy document. Agreed?

2. I am not familiar with the OpenSSL extensions described. The plan ATM is to land [v10.x backport] Update openssl1.1.1a node#26270, so 10.x's assembler requirements will become identical to 11.x (and master, and 12.x). Do you, or @nodejs/tsc @nodejs/crypto , see a problem with this?

If we add a new feature specific to 1.1.1, the API should check openssl version and be noted in the API doc

Maybe we should do this, but I don't believe we have to. Shared OpenSSL libraries are not supported by us, they do not necessarily support Node.js' APIs, they are probably not floating our patches, they may be several patch releases behind the version of OpenSSL we include, so have bugs our Node.js builds do not, and be missing features we have. I think we should continue to make a best effort to support shared openssll libraries, including feature detection, but I don't think we are required to document the effect of shared library builds in our documentation. For our own sanity, we probably need to keep the unit tests running against shared library builds, either against 1.1.0, or 1.1.1a. TLS1.3 won't work with OpenSSL < 1.1.1b, for example, and the Ed curves won't work with OpenSSL 1.1.0.

I'm in the middle of backporting TLS1.3 support to 11.x, and in the process I expect to run into some of the issues with shared library builds.

[sam-github]

@shigeki and sorry, I forgot

For the API simplicity, I think it is better to support one release version of OpenSSL during LTS.

I'm not sure exactly what you mean, is it that:

1. you object to updating OpenSSL from 1.1.0 to 1.1.1 during the 10.x lifetime (I don't think that's what you mean)
2. once we update to 1.1.1 in 10.x, you suggest we stop supporting 1.1.0 as a shared library (this is very attractive, if possble)
3. for 12.x and future LTS, we do not support shared OpenSSL libs that aren't the same version as "our" OpenSSL (this has happened already on master, 12.x won't build against 1.1.0).

[sam-github]

This entire section is new, and has some bad news now that the OpenSSL project has released more information about their FIPS support plan, PTAL.

[mhdawson]

This is a great doc, let us know when it is ready to be reviewed/land.

It is unfortunately related to FIPS, but there is not much we can do.

[sam-github]

OK, @nodejs/crypto @nodejs/tsc I believe this describes current policy. Not that it can't change later :-).

Note in particular that 12.x will never support FIPS, because FIPS will require openssl 3.0.0 which will NOT be ABI compatible with openssl 1.1.1.

13.x Might support FIPS, depends on when its cut (its not in the release timeline yet)

So, there is pretty much guaranteed to be "FIPS gap". Not too sure what we can do about that. I suggest once Openssl 3.0.0 FIPS is closer to reality that we revisit, to see if there are any options.

[mhdawson]

LGTM, Good work.

[sam-github]

@nodejs/tsc PTAL

https://github.com/sam-github/TSC/blob/openssl-strategy/OpenSSL-Strategy.md#nodejs-version-specific-strategy is the actual policy, the following sections are background information on Node.js and OpenSSL, for those interested.

[ChALkeR]

Belated LGTM. 🎉