Looks good to me.

Sounds good to me then!

I found information confirming my doubts about the keccak code.

Can you review the comment I added about crypto/sha/asm/keccak1600-armv8.pl?

We may also want to consider 40c24d74deaad8a0ad7566a68ea5ea757bc3ccef as well, from OpenSSL's Git repository:

FWIW this patch does not conflict with the import of OpenSSL 3.0.11 that I am currently preparing (vendor import in D41943).

I have the impression that with these changes, pxeldr will fail to build if MK_LOADER_LUA is not enabled. I am preparing a new patch where SUBDIR_DEPEND_pxeldr+= loader_lua_nozfs is protected by .if ${MK_LOADER_LUA} != "no", but then pxeldr is still hard-coded to L=loader_lua_nozfs; that feels wrong.

Also build aes-586.S for i386.

• Created a single new loader variant, loader_lua_nozfs
• Hard-coded the PXE loader to use loader_lua_nozfs instead of ${LOADER_INTERP}

Submitted again after rebase on -CURRENT.

You are right, with a better look I also see differences with the SHA512 files.

• Renamed the new member of struct country
• Use a switch/case for pass 1 to 3

In my tests the output is identical with and without this revision, except for avoiding the generation of temporary files on i386.
ISTM that the same optimization is possible on arm64, arm, and powerpc{,64,64le} as well by the way; would you consider applying it there as well?
Here is how I test locally: (from secure/lib/libcrypto)

#!/bin/sh

To me this looks tidier and also more sensible than before; indeed, why did it set the suffix to .pl only to remove it and add it again?

In D41298#940467, @jrtc27 wrote:

If you're moving code around and modifying it at the same time, please make two commits / revisions so it's much easier to review what's going on. Otherwise you have to flick back and forth between files.

Re-upload with arc this time (for context)

In D41250#939437, @khorben_defora.org wrote:

In D41250#939432, @mhorne wrote:

FYI: D40142

I do not know what the hesitation is there, but I know several people would prefer to see this menu disappear completely.

Thanks, I wasn't aware of this proposal. I can probably improve this patch some more, so that the default settings from the current installation are reflected.

Respect the original copyright for the "finalconfig" code.

Fix the brief summary in the commit

In D41293#940281, @emaste wrote:

review heading is wrong?

In D41250#939538, @jrtc27 wrote:

Or let's just let this abomination of a menu finally die...

In D41250#939432, @mhorne wrote:

FYI: D40142

I do not know what the hesitation is there, but I know several people would prefer to see this menu disappear completely.

With this additional change, the previous settings for all 9 possible hardening options are restored when canceling this menu.

Another improvement would be to add a "Cancel" button to this step, and keep the settings as they were before entering the dialog.

LGTM!

In D40974#934030, @salvadore wrote:

I approve, thanks for your your report.

I think you need that I commit it for you, is that right? Shall I use Pierre Pronchery <pierre@freebsdfoundation.org> as author of the commit? By the way you should also be added to https://docs.freebsd.org/en/articles/contributors/: is that contact the one to use for that list too?

Thanks.

Thanks for the patch and explanation!
Did you not mean OLD_LIBS instead of OLD_DIRS for capi.so and padlock.so inside the patch itself?

Another relevant link about how to setup the FIPS module, from the documentation within OpenSSL's source code: https://github.com/openssl/openssl/blob/master/README-FIPS.md.

I have pushed my branch at https://github.com/khorben/freebsd-doc/tree/khorben/report-openssl3 FWIW.

In D40974#932675, @salvadore wrote:

I think the links section is good. I would add only one link into the body of the report (see inline comment).

Apply suggestions from salvadore@; thanks!

I'm not familiar with AsciiDoc yet, so I have used only plain text so far. Let me know if I should make use of its capabilities somehow.
I suppose I should also capitalize the title, or add a few links. I was not sure about the right balance for not enough or too many links; I had in mind:

• https://en.wikipedia.org/wiki/OpenSSL for the Wikipedia entry on OpenSSL
• https://en.wikipedia.org/wiki/SSLeay for the ancestor of OpenSSL
• https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ for the OpenSSL 3.0 release notes
• https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards for FIPS
• https://www.netcraft.com/blog/june-2023-web-server-survey/ for the market share number
• https://www.linux.com/news/perl-removed-base-freebsd-sources/ (or the actual release notes for FreeBSD 5.0)

I can confirm that this file does belong in the build indeed (as per crypto/asn1/build.info). Thanks for the heads up, sorry I missed it.

Imported in https://github.com/freebsd/freebsd-src/commit/b077aed33b7b6aefca7b17ddb250cf521f938613

openssl: Enable support for RFC3779
openssl: Fix typos in manual pages
openssl: Limit the changes to obsolete files to us

As per https://github.com/freebsd/freebsd-src/pull/758.

The documentation from OpenSSL 3 is more clear about the behaviour of OPENSSL_init_crypto() with regard to the OPENSSL_INIT_LOAD_CONFIG option:

With this option an OpenSSL configuration file will be automatically loaded and used by
calling OPENSSL_config(). This is a default option. Note that in OpenSSL 1.1.1 this was the
default for libssl but not for libcrypto (see OPENSSL_init_ssl(3) for further details about
libssl initialisation). In OpenSSL 1.1.0 this was a nondefault option for both libssl and
libcrypto. See the description of OPENSSL_INIT_new(), below.

In the case of dumpon (similar situation), I found that some initialisation code is in .init in libcrypto.so. I think it comes from ossl_init_base() which in turns calls OPENSSL_cpuid_setup() (caught in gdb below). If I understand it correctly, OPENSSL_init_crypto() makes sure ossl_init_base() has been called or calls it explicitly. But then OPENSSL_init_crypto() also does more than that, and I do not see it being called at all here.

The documentation also says "This is not a default option for libcrypto." and this call is for libcrypto (OPENSSL_init_crypto() and not OPENSSL_init_ssl()) so @def is probably right.

Are you sure that it is still necessary to call OPENSSL_init_crypto() before entering capability mode?
OpenSSL 1.1 seems to use getentropy(3) on FreeBSD >= 12, or arc4rand(9) otherwise (through sysctl).
Anyway, better safe than sorry.

LGTM; and this also builds fine with OpenSSL 3.0.8 in src.

With these changes applied on d1639e43c589644510198dc53aef87e8908a1507 (latest main) the build fails for me in usr.bin/drill:

Reviewed with https://reviews.freebsd.org/D39832 instead.

I have added this to lib/libldns/Makefile to fix the build with GCC 12, as caught by the CI:

CWARNFLAGS.parse.c=    ${NO_WUSE_AFTER_FREE}

The build with GCC 12 now fails somewhere else (cddl/lib/libzpool) so I suppose this covers ldns.

Remove the WWW line in pkg-descr.

Remove the patch for the Makefile.