tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 9.0 is getting old...

>> > Maybe we should run netbsd-9 bulk builds with PREFER_PKGSRC=openssl?
>> > We would need to do the same to avoid libraries in base that link
>> > against libssl/libcrypto.
>> Have there been ABI changes?  Is this to deal with those changes, or to
>> force a version with a security fix (i.e., telling people that the choice
>> they made to update isn't ok :-), or ?
> This is a classical dilemma - we promise ABI stability, but some parts of
> the base system (like openssl) do not allow for that.

"Of course", OpenSSL 3.* does not provide ABI compatibility with
OpenSSL 1.1.1*, that's clear.  But how far does the ABI instability
for OpenSSL among the 1.1.1* versions go?

Can an openssl-using package built on 9.2 (with 1.1.1k) be expected
to be used with the OpenSSL which comes with 9.4 (1.1.1t)?  I would
hope for "yes", but do not know.  (9.3 is also 1.1.1k, if I
understand correctly.)

Can an openssl-using package built on 9.2 (with 1.1.1k) be expected
to be used with the OpenSSL which came with 9.0 (1.1.1c), or has the
1.1.1c to 1.1.1k upgrade introduced ABI backward incompatibilities?

In case there are incomatibilities between what a package expects
and what the in-tree OpenSSL provides, will there be an user-
understandable diagnostic warning about the incomatibility, or will
the package just mysteriously malfunction?  I fear the latter...

> See the 9.4 announcement:
> where a big note says:
> 	Important: the version of OpenSSL included with NetBSD
> 	9.x is now unsupported unless a support contract is
> 	purchased from OpenSSL, and cannot be upgraded without
> 	breaking the ABI compatibility we've promised for
> 	the netbsd-9 branch. Users are recommended to update
> 	to NetBSD 10 or use OpenSSL from pkgsrc.

OK, there are several aspects here

1) The end-of-life-ness of OpenSSL 1.1.1*, and the consequence that
   upstream will not expend any effort in providing any security
2) ...and.... probably upstream doesn't even spend any effort in
   doing vulnerability analysis of the 1.1.1* code base?
3) That we ourselves cannot commit to take on the security
   maintenance of OpenSSL 1.1.1* which is in netbsd-9.
4) We can obviously not upgrade OpenSSL to 3.x on the netbsd-9
   branch, that's clear, as that would definately break all binary
   compatibility related to OpenSSL.

While the last sentence "use pkgsrc OpenSSL or upgrade to 10.0" is
of course perfectly fine to state to users, it doesn't really
resolve what I as bulk builder for NetBSD/powerpc 9.x ought to do.

I *could* of course set PREFER_PKGSRC.openssl=yes in my /etc/mk.conf
and build with that, but I get the sense that this should be a
choice left to the user / local administrator.  And, yes, that
pushes the user making that choice in the direction of building
everything himself instead of being able to rely on binary packages.

Obviously, that would force me to toss all the pre-existing binary
packages which directly or indirectly depends on OpenSSL before

> But for users of binary pkgs there currently is no choice.  Either
> switching the official pkgs over, or providing a second set would
> be usefull (alone from the openssl PoV).

The thing I'm leaning towards is "do the minimal to clear the
py-cryptogarphy issue" and upgrade the pbulk build host to 9.2, and
just tell the few powerpc users "please upgrade to 9.2 or newer
before using this upcoming set of binary packages; use of this set
on 9.0 or 9.1 is on your own responsibility and is not guaranteed to
be trouble-free", and leave the 9.0 and 9.1 symlinks pointing to the
newest bulk build result built on 9.0 (while it's still present).


- Håvard

Home | Main Index | Thread Index | Old Index