the path to openssl3

[Greg Troxel <gdt%lexort.com@localhost>]

I'm opening this conversation here (where it belongs :-) after seeing a
question on another list.

I want to state upfront that updating security/openssl before 2023Q3 is
out of the question.  While surely we are going to update it, I expect
trouble, and we are past the 9/1 date for changing the major version of
important languages and big packages for this branch.  So this is about
what we might do after October 1, perhaps much after.

Background:

  upstream is being difficult about openssl 1.1.1; it's EOL very soon,
  and support is only available if you pay:
    https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/

  NetBSD 10 has openssl 3.0.9.   This is probably a pretty normal
  situation for an up-to-date OS these days.

  NetBSD 9 has 1.1.1t.  This seems pretty normal for an OS that isn't
  super recent.  It is the most rcent formal release of NetBSD.

  Debian 11 has 1.1.1n.  This is also pretty normal for a not-super
  recent OS.  11 was until June 2023, the most recent Debian release.

  pkgsrc has security/openssl at 1.1.1u, which is behind 1.1.1v release
  August 01, just 33 days ago.
    See https://www.openssl.org/source/

  3.0.10, released in August, is the openssl3 current LTS release.

  3.1.2, released in August, is the openssl3 non-LTS current release.

  3.1. is not a development release; it is merely not LTS:
    https://www.openssl.org/policies/releasestrat.html

  Lots of programs use openssl, and while many of them will build
  against 1.1.1 and 3.x both, surely a number of them are not yet ready
  for 3.  (That's just me saying surely; if you'd like to tell me I'm
  wrong, pleaes keep reading for your homework assignment.)

  wip/openssl3 is at 3.1.2

First, there is the question of 3.0 vs 3.1.  There is no incompat from
3.0 to 3.1, and 3.1 has more features.  So I think we should be on 3.1
and switch to 3.2 after a few micros, and so on.  Opinions welcome
especially if you think this is unwise.  Assuming agreement on 3.0 or
3.1, there are two basic paths forward:

  One path is to update security/openssl to the contents of
  wip/openssl3.  This means any package that doesn't build with 3 will
  break, and we can update it to a released version that does, or patch
  it, or see if it is eligible for removal on its own merits.  Note that
  "we want to updat to openssl3 and it doesn't have a release that
  supports that" is NOT a valid reason to remove a package.  Wanting to
  remove more than a tiny handful of clearly irrelevant package is clear
  evidence that the update to openssl3 is forced and inapproriate; that
  would be like the situation we had with "let's get rid of qt4".  But,
  it might not be that hard.

  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.

To evaluate this, it would be really helpful if someone could do a bulk
build, record the stats, and then swap in wip/openssl3 as if they were
going to update but just not commit, and then do another bulk build, and
see what marginal trouble there is.  This is your homework if you think
it's crazy for me to even ask the question!

My guess is that about 150 packages directly and 600 total will be lost.
But that is truly a guess.  If I'm wrong and it's 3 and 10, I'll be
happy to say "It's great that I was wrong; let's do it!".


If you think I'm asking the wrong questions, or if we should stay on
openssl1 (only) for the next year, please speak up.