This seems to do the trick for me too, testing on macOS/amd64; it does not seem to harm FreeBSD/amd64.

I offered the same patch in D51897, with:

Should we involve secteam@ regarding the extra algorithms enabled?
I am not aware of any security concern there as of today, but I think we had stuck with OpenSSL's own list of default algorithms so far for the base system.

In D51897#1186369, @ngie wrote:

This is sort of what the SRCS should be in libcrypto.so: https://gist.github.com/ngie-eign/e3fb2de6dc32bdfddb9be119058c4792 (it's not a complete picture, but it's a start).

In D51897#1186364, @ngie wrote:

params_idx.c is missing from secure/lib/libcrypto/Makefile. That's where the source should be plugged in (not the legacy provider).

Committed as e7be843b4a162e68651d3911f0357ed464915629 and 4757b351ea9d59d71d4a38b82506d2d16fcd560d.

Note that I have reservations about the part adding params_idx.c to the list of files built: from what I can tell, OpenSSL expects this to be available from libcrypto.so, instead of a copy inside the legacy provider module.
I suspect the more correct fix is to add the ossl_param_find_pidx to secure/lib/libcrypto/Version.map instead - which also kinda feels wrong.

In D47933#1185773, @carlavilla wrote:

@khorben_defora.org can I commit this?
For me is ok

Got 32-bit PowerPC to build.

I am now trying to build 32-bit PowerPC with this set in secure/lib/libcrypto/Makefile.common:

In D51613#1178895, @philip wrote:

I don't think PowerPC 32 failing is a blocker for main or stable/15: we're ending support for 32 bit platforms. Do we ever plan to merge this to stable/14 though?

I think this diff should also update secure/lib/libcrypto/Makefile.inc with the corresponding OPENSSL_VER and OPENSSL_DATE.

Even though I have the approval of my mentor, it would be great to have approval from the installer group for this change before I proceed with the commit.
Please let me know!

I have managed to rebase the diff, and tested both jail and auto with bsdinstall.
This also simplifies the save/restore functions as suggested.

• Re-indented the case statement
• Added a check for empty passwords
• Reworked error management

I have added everyone on the de-facto installer group that met on Monday; sorry for the noise.
(Should we create a Phabricator group for us? Apologies if I did not find it)

Also noteworthy in terms of UX:

• With bsddialog, the <TAB> key will go straight from the first input field to the [ OK ] button; the "arrow down" key should be used instead.
• Entering a mismatching password resets both password fields. (Like the passwd(8) command)
• This does not allow setting an empty password; it then fails with error Incorrect input data. (This is unlike the passwd(8) command)

This could be frustrating to some users.

I am revisiting this revision for the following reasons:

Since I am not a doc committer, I have pushed a copy of this commit at https://github.com/khorben/freebsd-doc/tree/khorben/new-committer for convenience.

Reflect the new expiration date for the PGP/GPG key, after passing the documentation/tools/checkkey.sh test.

Thanks Tom for the patch! I have managed to test it on top of ecb3a7d43dd6:

In D49085#1123179, @jrm wrote:

It fails to build. Do you need a dependency on multimedia/v4l_compat?

Register missing dependency on multimedia/v4l_compat.

Also include the distinfo file; thanks for the heads up!

You are right, the old scheme is less confusing.
The changes proposed here look correct to me.

Updated to compile and work with the new ifabi changes.

Thanks for the heads up! Looking into it...

Integrate suggestions from Zhenlei Huang (zlei@); thank you!

In D48167#1103394, @ziaee wrote:

I'm so excited to test this driver this weekend! Thank you so much for submitting this! All of the suggestions I made are to bring it into alignment with the rest of the freebsd manual and are specified in the manual page style guide, style.mdoc(5). Sorry I'm so late.

This change applies the rest of the changes suggested to the manual pages.

This update to the diff brings:

In D48167#1103157, @khorben_defora.org wrote:

I am currently looking into adding the SPDX license identifier, but it can also be done in a separate review.

In D48167#1103156, @adrian wrote:

I think it's fine as-is to go in the tree, it's been two years and I'd like to see this in before -15.

Address feedback from lwhsu@; thanks!

In D47933#1093012, @concussious.bugzilla_runbox.com wrote:

Oops! You're right. I don't think the field descriptions help it though, the fields are very self explanatory but the comments adds bikeshedable language? This is really an architectural decision for secteam, will certainly result in increased spam, but maybe helpful. So, I'll bow out now.

Also note that the contents of this file can be signed with an OpenPGP clear-text signature by the security team, in order to clearly authenticate it as legitimate.

Add descriptions of the fields used, as per the example from securitytxt.org.

In D47933#1092988, @concussious.bugzilla_runbox.com wrote:

I really like this concept.
Why are there two policy lines?

Removed the (optional) links for "any security-related job openings in your organisation."

Moved the sanity check for len to the beginning of pci_vtcon_control_send().

In D45401#1053575, @corvink wrote:

What's CID: 1521334?

In D42146#1052635, @imp wrote:

So now that we build a smaller loader in general, do we need to build another loader for this?

Would it be more clear or accurate to mention the "Pentium MMX" instead or in addition to the Pentium Pro?
It was much more common and known to the public than the Pentium Pro.

This avoids an issue with makefs(8) when building without a manifest file. (e.g., when building as root)
Consequently it should work both when using a manifest file as well as without, although it still requires root privileges in both cases, for e.g., chroot(8) and mount(8).

In D44670#1018389, @jrtc27 wrote:

Why do we need a copy of this code rather than just tweaking bsdconfig to support this?