Page MenuHomeFreeBSD

openssl: Vendor import of OpenSSL-3.0.8
AbandonedPublic

Authored by ngie on Mar 1 2023, 3:28 AM.
Referenced Files
Unknown Object (File)
Tue, Nov 12, 7:30 PM
Unknown Object (File)
Nov 9 2024, 1:50 AM
Unknown Object (File)
Nov 7 2024, 4:43 PM
Unknown Object (File)
Nov 2 2024, 3:10 AM
Unknown Object (File)
Nov 2 2024, 2:14 AM
Unknown Object (File)
Oct 31 2024, 4:48 PM
Unknown Object (File)
Oct 30 2024, 1:26 AM
Unknown Object (File)
Oct 27 2024, 8:06 PM

Details

Summary
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 <richard@levitte.org>
uid           [ unknown] Richard Levitte <levitte@lp.se>
uid           [ unknown] Richard Levitte <levitte@openssl.org>
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 <richard@levitte.org>" [unknown]
gpg:                 aka "Richard Levitte <levitte@lp.se>" [unknown]
gpg:                 aka "Richard Levitte <levitte@openssl.org>" [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
$

Diff Detail

Repository
rG FreeBSD src repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 50076
Build 46968: arc lint + arc unit

Event Timeline

ngie requested review of this revision.Mar 1 2023, 3:28 AM
ngie retitled this revision from Summary: openssl: Vendor import of OpenSSL-3.0.8 to openssl: Vendor import of OpenSSL-3.0.8.

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

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.

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.

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.

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 .

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.

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.

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