On Tue, Oct 12, 2021 at 06:04:51PM +0100, Dimitri John Ledkov wrote:
> > (my apologies, this mail will likely contain quite a few links)
> > I looked a little bit into this, and as of 8 hours ago, the embedded copy
> > of OpenSSL has been updated to version 3.0.0[0]. They have an open issue
> > tracking the OpenSSL 3.0 support situation[1], and their technical
> > committee has a document specifiying which OpenSSL release is supported
> > for a given NodeJS version[2].
> > According to this comment[3] it seems they don't plan on supporting
> > OpenSSL 3.0 in the 16.x branch, but rather in the 17.x which will have
> > its first release next week according to their release schedule[4].
> > Sadly, the new 17.x branch isn't planned as an LTS one.
> > Looking inwards, we currently ship a NodeJS version based on the 12.x
> > branch, and Debian seems to be planning[5] a transition towards the 14.x
> > branch. None of which support OpenSSL 3.0.
> > Unless I'm missing something, I see the following options, in no
> > particular order:
> > (a) Remove NodeJS from the archive. Had to be mentioned, but I don't
> > think it's realistic ;-)
> > (b) Keep in sync with Debian, use the 14.x branch, but keep OpenSSL 1.1.1
> > in the archive via a compat package.
> > (b') The same but using the embedded copy of OpenSSL (if even possible?).
> (b') has been done in the past in Debian, and can be done again in
> Debian/Ubuntu.
> I'm not sure how well extensions compile when one does that and if we
> will still need to package nodejs-openssl headers somewhere. Doing
> (b') imho is less liability than packaging and providing 1.1.1 in the
> archive, as despite all pleas people tend to assume that they don't
> need to do anything and can stick with 1.1.1 for another ten years
> without doing any work to migrate to 3.0.0.
I wanted to argue that this was not an openssl-specific problem, but rather
that if there were problems with understanding the support of main vs
universe it should be addressed by more systematically socializing this.
However, ESM makes this all a lot more fuzzy.
An openssl 1.1.1 used by only one reverse-dependency (hypothetically) is not
going to be high on the list of packages to get security updates on in ESM;
but its presence in universe plus the existence of ESM could easily give
users a different impression and lead them to rely on it.
So if there are no other packages left in universe requiring openssl 1.1 at
22.04 release time (which is a big if), I am also in favor of b').
If there are other universe packages which still need 1.1.1 for 22.04, which
seems likely, then b) is the right answer.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
