In D53045#1212147, @glebius wrote:

In D53045#1212125, @ngie wrote:

The test uses OPENSSL_CONF to specify the test config file.

Sorry, I was blind.

In D53045#1212112, @glebius wrote:

Does OpenSSL just picks up openssl.conf from current directory?

I'll resume looking at this later. Need to get into the right mindset to make sure the conversion looks good.
Just some minor comments while here...

Incorporated into the upstream project and handled as part of the 3.5.3 version update.

Expand scope to include other files under tools/tools/nanobsd

Use local with variables for explicitness

In D52554#1200798, @gordon wrote:

Looking at what should be in the legacy provider, I fell down this rabbit hole by looking at a completely stock build of 3.5.4-dev on my Mac (I should probably check on a FreeBSD system and see if it is any different, but that would require a small amount of effort and I'm about to go to a dinner) and see this list as the primary objects that end up in the legacy provider:

crypto/des/liblegacy-lib-des_enc.o
crypto/des/liblegacy-lib-fcrypt_b.o
crypto/md5/liblegacy-lib-md5-aarch64.o
crypto/md5/liblegacy-lib-md5_dgst.o
crypto/md5/liblegacy-lib-md5_one.o
crypto/md5/liblegacy-lib-md5_sha1.o
crypto/rc4/liblegacy-lib-rc4_enc.o
crypto/rc4/liblegacy-lib-rc4_skey.o
providers/common/liblegacy-lib-provider_util.o
providers/implementations/ciphers/liblegacy-lib-cipher_blowfish.o
providers/implementations/ciphers/liblegacy-lib-cipher_blowfish_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_cast5.o
providers/implementations/ciphers/liblegacy-lib-cipher_cast5_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_des.o
providers/implementations/ciphers/liblegacy-lib-cipher_des_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_desx.o
providers/implementations/ciphers/liblegacy-lib-cipher_desx_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_idea.o
providers/implementations/ciphers/liblegacy-lib-cipher_idea_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_rc2.o
providers/implementations/ciphers/liblegacy-lib-cipher_rc2_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_rc4.o
providers/implementations/ciphers/liblegacy-lib-cipher_rc4_hmac_md5.o
providers/implementations/ciphers/liblegacy-lib-cipher_rc4_hmac_md5_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_rc4_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_seed.o
providers/implementations/ciphers/liblegacy-lib-cipher_seed_hw.o
providers/implementations/ciphers/liblegacy-lib-cipher_tdes_common.o
providers/implementations/digests/liblegacy-lib-md4_prov.o
providers/implementations/digests/liblegacy-lib-mdc2_prov.o
providers/implementations/digests/liblegacy-lib-ripemd_prov.o
providers/implementations/digests/liblegacy-lib-wp_prov.o
providers/implementations/kdfs/liblegacy-lib-pbkdf1.o
providers/implementations/kdfs/liblegacy-lib-pvkkdf.o
providers/liblegacy-lib-prov_running.o

In D52009#1197108, @ngie wrote:

In D52009#1193198, @jhb wrote:

I think it would be useful (if possible) to reformat the list of existing SRCS as a separate commit. It will be clearer what the differences from the regeneration are when it comes to reviewing those, and will also be easier to bisect if needed.

I don't have a ton of time to deliver this before 15.0-RELEASE, so I'm going to manually "massage" the Makefiles in order to deliver something working for 3.5.1, then pivot to 3.5.2 (which has been out for over a month now).

In D52554#1200774, @gordon wrote:

How did you come up with these changes? What was the methodology that got this changeset?

Is anyone interested in reviewing this change?

Address comments from @sjg.

In D52009#1193198, @jhb wrote:

I think it would be useful (if possible) to reformat the list of existing SRCS as a separate commit. It will be clearer what the differences from the regeneration are when it comes to reviewing those, and will also be easier to bisect if needed.

Oh, also.. this probably should be serialized. I don't think it would be terribly wise to try parallelizing efforts (seems like you'd run into potential TOCTTOU bugs..).
Finally, for loadable subsystems compiled into the kernel the name can differ between the module and the static subsystem name. It might be worth adding support to handle that eventuality.

1. This probably won't work in jails. This scenario needs to be detected and handled correctly.
2. Having a way to override the behavior of automatically loading in kyua.conf might be desired, similar to require.config="allow_sysctl_side_effects". I think it should default to on in the configuration on FreeBSD, but be opt-out if needed.

Remove bogus MLINKS in the section 7 manpages

In D51136#1196756, @igoro wrote:

No, they are not expected as this patch was intended to be pushed only after the fix of the cleanup logic which is there already: https://cgit.freebsd.org/src/commit/?id=9bf14f2a475e221c48488984dc5a02a4608bb877

It's fine. I'd just watch out for adding more per-MACHINE/MACHINE_ARCH logic to the file.

In D51136#1170880, @igoro wrote:

In D51136#1170613, @ngie wrote:

What was the behavior prior to this change?

It's turned out that kyua test catches issues with temporary dir/files cleanup but does not propagate it -- that's obvious from the code where test_result is not used actually. As a result, a test is marked as passed leaving garbage behind (tmp dirs/files), while by design and code comments it is expected to be broken instead.

I kind of wonder if it makes sense to provide multiple host OS share/mk/bsd.cpu.mk files (or something similar) to avoid cluttering this file with support for a number of other OS hacks.
@sjg : do you have any thoughts on doing something like this? Has Juniper solved a similar problem in the past?

atf_set "require.config" "allow_sysctl_side_effects" should be tested as well in the testcase headers for the tests that modify the systemwide sysctls.

Hey there!

Do not install internal headers

Update with working content