Re: the path to openssl3

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Wed, Sep 06, 2023 at 06:49:19PM +0200, Tobias Nygren wrote:
> On Sun, 03 Sep 2023 19:25:41 -0400
> Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> >   Another path is adding security/openssl3, namespacing the binaries and
> >   adding OPENSSL_VERSIONS_ACCEPTED and OPENSSL_VERSIONS_INCOMPATIBLE as
> >   11 30 31.  Each could have a builtin.  This is messy as a program
> >   could want to have both indirectly and that's ungood, maybe doubleplus
> >   ungood.
> 
> I don't like this approach but unfortunately it is necessary. Right now
> we have the problem that some abandonware doesn't build with openssl 3.
> But a couple of years down the road we will have the opposite problem:
> Maintained software will ONLY work with openssl 3, important packages
> will start to break on NetBSD <10 and it will be necessary to blanket
> require openssl from pkgsrc on that subset of platforms to maintain
> some sort of sanity.
> 
> I would prefer however if security/openssl can just go to 3 and we
> re-import security/openssl11 with alternate libdir/incdir patches.
> Similar to how RHEL9 added a compat-openssl11 package to deal with
> this problem. The VERSIONS_ACCEPTABLE/VERSIONS_INCOMPATIBLE stuff can
> IMHO wait and we just point abandonware packages directly at
> openssl11's bl3.mk.

Inspired by today's security fix release, 've just updated
security/openssl to 3.1.4.

I've bumped pkgsrc to require OpenSSL 3 ABI (not API) (since the shlib
major of the openssl package was increased from 1 to 3). I've used "3"
instead of "3.1.4" in the buildlink3.mk file to give native OpenSSL 3
versions a chance to be selected.

Let's see from the bulk build outputs if we'll need an openssl11
package (or we can make one now, if someone feels like it).
 Thomas