openssl: Vendor import of OpenSSL-3.0.8

[ngie]

Summary

Release notes can be found at
https://www.openssl.org/news/openssl-3.0-notes.html .

Obtained from: https://www.openssl.org/source/openssl-3.0.8.tar.gz

Test Plan

$ git status
On branch vendor/openssl-3.0
nothing to commit, working tree clean
$ (cd ..; fetch http://www.openssl.org/source/openssl-${OSSLVER}.tar.gz http://www.openssl.org/source/openssl-${OSSLVER}.tar.gz.asc)
openssl-3.0.8.tar.gz                                    14 MB 4507 kBps    04s
openssl-3.0.8.tar.gz.asc                               833  B   10 MBps    00s
$ set | egrep '(XLIST|OSSLVER)='
OSSLVER=3.0.8
XLIST=FREEBSD-Xlist
$ gpg --list-keys
/home/ngie/.gnupg/pubring.kbx
-----------------------------
pub   rsa4096 2014-10-04 [SC]
      7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C
uid           [ unknown] Richard Levitte <[e-mail]>
uid           [ unknown] Richard Levitte <[e-mail]>
uid           [ unknown] Richard Levitte <[e-mail]>
sub   rsa4096 2014-10-04 [E]

$ gpg --verify openssl-${OSSLVER}.tar.gz.asc openssl-${OSSLVER}.tar.gz
gpg: Signature made Tue Feb  7 05:43:55 2023 PST
gpg:                using RSA key 7953AC1FBC3DC8B3B292393ED5E9E43F7DF9EE8C
gpg: Good signature from "Richard Levitte <[e-mail]>" [unknown]
gpg:                 aka "Richard Levitte <[e-mail]>" [unknown]
gpg:                 aka "Richard Levitte <[e-mail]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7953 AC1F BC3D C8B3 B292  393E D5E9 E43F 7DF9 EE8C
$ (cd vendor.checkout/; git status; find . -type f -or -type l | cut -c 3- | sort > ../old)
On branch vendor/openssl-3.0
nothing to commit, working tree clean
$ tar -x -X $XLIST -f ../openssl-${OSSLVER}.tar.gz -C ..
$ rsync --exclude FREEBSD.* --delete -avzz ../openssl-${OSSLVER}/* . 
$ cat .git
gitdir: /home/ngie/git/freebsd-src/.git/worktrees/vendor.checkout
$ diff -arq ../openssl-3.0.8  .
Only in .: .git
Only in .: FREEBSD-Xlist
Only in .: FREEBSD-upgrade
$ git status FREEBSD*
On branch vendor/openssl-3.0
nothing to commit, working tree clean
$

[emaste]

I assume your vendor/openssl-3.0 branch started from the current vendor/openssl?

[ngie]

In D38835#884175, @emaste wrote:

I assume your vendor/openssl-3.0 branch started from the current vendor/openssl?

Yup! That’s why I cherry-picked @jkim’s commits to the branch a couple days ago (to diff reduce).

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

[jkim]

In D38835#884575, @ngie wrote:

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

Actually, we need to rewrite both FreeBSD-upgrade and FreeBSD-Xlist from scratch for OpenSSL 3.0 because it is quite different.

[ngie]

In D38835#884625, @jkim wrote:

In D38835#884575, @ngie wrote:

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

Actually, we need to rewrite both FreeBSD-upgrade and FreeBSD-Xlist from scratch for OpenSSL 3.0 because it is quite different.

I totally agree. What I was hoping to do is work on the necessary pieces in a side-branch on my personal GitHub fork of FreeBSD, then take the findings/process changes and submit them along with the upgrade itself.

[ngie]

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

[dim]

In D38835#884784, @ngie wrote:

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

If openssl3 is going to be a private lib, then ports can't use it at all, right? I see there is already security/openssl which is 1.1.1t, and security/openssl-devel which is 3.0.8 (strange, because the development version of OpenSSL is 3.1.0 but I digress). So ports would have to link against the former or the latter (and can't use both). Also, if we make a private openssl3 lib, we'll have to rename all symbols so as to not conflict with ports. Alternatively, the ports openssl versions should rename all _their_ symbols to not conflict. That might also solve the problem of mixing 1.1 and 3.0.

In any case, getting openssl3 in side-by-side is a good first step, allowing piecemeal work to be done.

[ngie]

In D38835#884813, @dim wrote:

In D38835#884784, @ngie wrote:

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

If openssl3 is going to be a private lib, then ports can't use it at all, right? I see there is already security/openssl which is 1.1.1t, and security/openssl-devel which is 3.0.8 (strange, because the development version of OpenSSL is 3.1.0 but I digress). So ports would have to link against the former or the latter (and can't use both). Also, if we make a private openssl3 lib, we'll have to rename all symbols so as to not conflict with ports. Alternatively, the ports openssl versions should rename all _their_ symbols to not conflict. That might also solve the problem of mixing 1.1 and 3.0.

In any case, getting openssl3 in side-by-side is a good first step, allowing piecemeal work to be done.

Fair. Moving OpenSSL 3 to a private library wouldn't make it usable to ports. I might call that a feature instead of a bug, but some orgs prefer managing a single copy of libraries instead of dual copies, for sanity reasons.

[ngie]

Are there any objections to continuing with the creation of the vendor/openssl-3.0 branch?

[ngie]

Merged as https://reviews.freebsd.org/rGe4520c8bd1d3 .