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
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 |
emaste | |
jkim |
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
$ 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 $
No Lint Coverage |
No Test Coverage |
Buildable 50076 | |
Build 46968: arc lint + arc unit |
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.
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.
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?