New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LTS planning #5120

Closed
rvagg opened this Issue Jan 20, 2018 · 9 comments

Comments

Projects
None yet
4 participants
@rvagg
Copy link

rvagg commented Jan 20, 2018

https://www.openssl.org/policies/releasestrat.html

  • Version 1.1.0 will be supported until 2018-08-31.
  • Version 1.0.2 will be supported until 2019-12-31 (LTS).

We may designate a release as a Long Term Support (LTS) release. LTS releases will be supported for at least five years and we will specify one at least every four years. Non-LTS releases will be supported for at least two years.

In addition, during discussion about our OpenSSL version planning in Node.js, @kroeckx helpfully expanded on this with the following:

We currently don't know yet when to announce the next LTS release, and which version it's going to be. According to our release strategy we should announce a new LTS this year, and so it'll be a release we make this year. This could be the upcomming 1.1.1, or even a higher number (1.2.0, 1.1.2). We at least want to make this API compatible to 1.1.0, not sure if it's going to be ABI compatible.

We are now less than a year away from EOL for 1.1.0, it's clear that it's not the version to use for anything meaningful. But, we're also now less than 2 years away from 1.0.2 EOL, which makes it difficult for those of us looking at longer time horizons to plan.

To give you some insight into the Node.js dilemma:

  • All versions of Node.js are pinned to 1.0.2, although Node.js 8.x and above now have the ability to compile against 1.1.0 and we test this support as part of our CI, but this is not something we recommend for users.
  • Node.js designates a new LTS release line every 12 months. Prior to becoming LTS, a release line exists as what we call "Current" for 6 months then gets an LTS lifetime of 30 months beyond that—a total of 3 years of support where we attempt to guarantee no "breaking changes", either API or ABI. (more info about the schedule here)
  • Node.js' latest LTS release line, version 8, started its LTS life in October 2017 and under normal circumstances, should be supported until April 2020. However, because it uses OpenSSL 1.0.2, we have artificially contracted its support timeframe by 4 months to coincide with 1.0.2 EOL (we've communicated this from the begining).
  • Node.js is due to cut a new major version, 10, for release this April. It will become our next LTS in October and will then get support until April 2021 (that's the plan anyway).

So, the dilemma is what to do about OpenSSL support?

  • Sticking with 1.0.2 would extend us beyond OpenSSL's support timeframe by 16 months, a burden we can't shoulder.
  • Upgrading to 1.1.0 would give us only ~4 months of support.
  • Waiting for 1.1.1 means we (a) have to cross our fingers that it'll be released before April, (b) need to ensure we can integrate it in time and (c) that it actually gives us a path to OpenSSL LTS and we have no indication that 1.1.1 will be LTS or that there is a clear path from 1.1.1 to an LTS.
  • Having a hybrid approach where we switch versions of OpenSSL part-way through the lifetime of Node 10 leaves us in the position of potentially having to break ABI and/or API, which would be a nasty break to the stability that we've worked so hard to ensure since Node 4 (and have gained a lot of trust because of). We may be able to make this palatable if we had a plan to work with and could communicate that plan ahead of time, but we don't have timeframes, versions or much else to work with.
  • FIPS is another dilemma. Node.js supports FIPS today, but my reading of the policies and comments about FIPS is that it we may not see new FIPS support for some time. This is not necessarily a big deal, it's a matter of communication as we could just be explicit that Node 10 doesn't support FIPS and if you want FIPS you'll have to use an earlier, supported version or wait for perhaps Node 12 which may have new FIPS support.

I'm acutely aware of the difficulty of roadmaps in open source software, and I hope this doesn't come off as entitled or rude. I'm genuinely grateful for the current team's work on OpenSSL and think you've done an amazing job at modernising both the code and the policies surrounding the project. Even the fact that the project has got to a place where we can have such a conversation as this is awesome.

Perhaps someone could provide additional insight into the thinking behind OpenSSL LTS planning, or whether there's even been much discussion about this? If not, I'd like to suggest that accelerating such a discussion would be of benefit to downstream users that are looking at a rapidly closing support window and need to do planning beyond that window.

@nickthetait

This comment has been minimized.

Copy link
Contributor

nickthetait commented Jan 20, 2018

I consider this issue to be significant. Commenting to mark it as "participating" rather than "watching" when it reappears in my notifications...

@mattcaswell

This comment has been minimized.

Copy link
Member

mattcaswell commented Jan 21, 2018

We did discuss this issue at our f2f meeting in December but unfortunately we did not come to a conclusion on it. Thanks for raising it again.

As one more thing to consider (and I know this isn't really a solution to your main problem): 1.1.1 will be fully API and ABI compatible with 1.1.0 - so starting with 1.1.0 and later moving to 1.1.1 should not cause you any problems (with some caveats around TLSv1.3 behaviour explained in my blog post https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/)

@richsalz

This comment has been minimized.

Copy link
Contributor

richsalz commented Jan 21, 2018

Also, thanks for your thoughtful and detailed note. It's a hard problem.

@mattcaswell mattcaswell added this to the Other milestone Jan 22, 2018

@rvagg

This comment has been minimized.

Copy link

rvagg commented Feb 23, 2018

FYI I've proposed a formal OpenSSL policy for Node.js, along with details about how we use it. The context here is around planning for Node.js 10 which is due out in April.

This proposal does note that TLS 1.3 is due to be finalised in March 🤞 and that we could potentially see an OpenSSL 1.1.1 final in early May 🤞. It's possible that we could defer release of Node.js 10 to align with this if we're able to make a prediction that the stars will align with some confidence as we approach release date.

As things stand though, here's the relevant part of the proposal, I'd love to hear if there's anything you can help us clarify that might adjust our position.


OpenSSL LTS support timing, the lack of OpenSSL LTS planning and the lack of a clear timeframe for a new FIPS module complicates Node.js 10.

As of the time of writing, the strategy for OpenSSL with Node.js 10 is:

  • OpenSSL 1.1.0 to initially be the assumed default compile target.
  • Bundle a copy of OpenSSL 1.1.0 in the source tree, along with any floating patches still required for improved Windows support and test-runner speed-ups.
  • Remain backward-compatible with OpenSSL 1.0.2 via dynamic linking for the lifetime of Node.js 10. This will cease being an official policy at the OpenSSL 1.0.2 EOL date which will occur 4 months prior to Node 10 entering Maintenance LTS. However, this support will be maintained as long as it does not cause security problems and there are contributors available to maintain such support. The lack of a passing test suite with Node.js 10 compiled against OpenSSL 1.0.2 past the EOL date will not hold up further releases of Node 10.
  • Upgrade to OpenSSL 1.1.1 when made generally available and Node.js 10 can retain ABI and API compatibility.
  • No support for FIPS unless a new FIPS module becomes available during the Node.js 10 lifetime and is compatible without requiring breaking changes.

ABI and API compatibility cannot be guaranteed in a switch from 1.1.0 to 1.1.1 although, as previously mentioned, the OpenSSL team have signaled their intention for this to be the case. The Node.js team should work with the OpenSSL team to ensure this is the case and smooth the upgrade path.

The lack of FIPS support is unfortunate, however, unless a new FIPS module takes an inordinate amount of time, Node.js users requiring FIPS support should be able to use Node.js 8 and switch to a future Node.js version that supports the new FIPS module (ideally Node.js 12).

This strategy must be communicated to users of Node.js 10 early and often. There is potential for instability and a change in default OpenSSL version is unprecedented and therefore unexpected. The potential for breaking API and/or ABI may also cause disruption, potentially requiring an increment of NODE_MODULE_VERISION, which will also be unprecedented within a single release line. It is important that users be aware of this possibility.

@mattcaswell

This comment has been minimized.

Copy link
Member

mattcaswell commented Feb 23, 2018

ABI and API compatibility cannot be guaranteed in a switch from 1.1.0 to 1.1.1 although, as previously mentioned, the OpenSSL team have signaled their intention for this to be the case.

That is our policy and intention. It would be good if the Node.js team were able to test the pre-release 1.1.1 versions to confirm that we haven't inadvertently broken something. Note also that the introduction of TLSv1.3 support does imply some potential configuration issues (see: https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/, (the ciphersuites issue mentioned in that blog is being addressed in #5392)).

@rvagg

This comment has been minimized.

Copy link

rvagg commented Feb 23, 2018

Working on it, nodejs/node#18770. We can can compile without any changes on top of our 1.1.0 support so 👍 so far. We have a bunch of test failures that I haven't dug in to at all yet. There's a suggestion that it could be largely to do with our lack of recognition of the TLS 1.3 support that's coming along with this.
@shigeki is working on this on our end and I'm sure he'll be reporting back here if he finds anything amiss.

@richsalz

This comment has been minimized.

Copy link
Contributor

richsalz commented Feb 23, 2018

I think "signalled our intention" is not strong enough. It is our policy and if we didn't do that, we consider it a bug we will fix.

@richsalz

This comment has been minimized.

Copy link
Contributor

richsalz commented Jul 12, 2018

We announced 1.1.1, to be released, as our next LTS release. Does this close the issue?

@rvagg

This comment has been minimized.

Copy link

rvagg commented Aug 9, 2018

aye 👌, thanks

@rvagg rvagg closed this Aug 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment