In D45488#1037640, @markj wrote:

Please add Fixes: 8d5c7813061d ("libradius: Fix input validation bugs") to the commit log message.

LGTM -- thank you!

I’m not sure how one would go about communicating this change, since it mostly affects developers (Relnotes: yes?), but I would probably send out a heads up about some of the function definitions changing (the extra ellipses), and provide rationale for why they’re changing in the commit. It could confuse developers who use more naive methods of searching for function definitions (like me :)..). All the more reason to encourage others to use alternative tools like cscope or VSCode :).

-Wl,-Bsymbolic should be added to SOLINKOPTS instead of LDFLAGS

Fix the change to properly append the CFLAG to PICFLAG and do it after including bsd.lib.mk to properly compile/link libcrypto.so.

I accidentally pushed this to main (and have subsequently reverted it). I've really become used to git push.default nothing thanks to being bitten so much at work and forgot that my local forks don't use this config by default :(..

I held off on this review for a while, but I wanted to chime in about a few things:

In D42646#973954, @glebius wrote:

In D42646#973650, @ngie wrote:

Would you please add a comment to the tops of functions to note what variables are being set in the functions?

Of course I can! Let me ask question first: do you agree that this patch is worth checking in and I can add you as "reviewed by"?

P.S. I actually opened this revision again to add you as reviewer. I need review from somebody who is a general expert in the tests.

Would you please add a comment to the tops of functions to note what variables are being set in the functions?

Also, please add comments for non-obvious things: you have the context now, but I didn't understand the reasoning, and you might not have the context at a later date. The code needs to either be intuitive by design or intuitive via comments.

Ok, that part wasn't apparent before.

In D42321#965774, @jlduran_gmail.com wrote:

I think that we should import https://github.com/NetBSD/src/commit/38862c874c4a2bcca9dce5c0966ea19ddabd523e first.
I wonder if we should skip only the failing one?

Should this still be open, given that you have done a functionally equivalent change in D41970?

All of my questions relate to understanding the rationale behind some of the design choices presented in the change.

No ship-blocking comments.
Thank you 🙂!!

In D41970#957458, @fuz wrote:

Ok. Should I unhook the netbsd strcmp tests from the build and replace them with a FreeBSD-specific file then? What about the other open DRs (D41520, D41528)?

Please don't modify the NetBSD test: if the plan is to test out FreeBSD-specific behavior for strcmp, it should go in its own test.

Awesome new tests!

Thank you @lwhsu !

• Incorporate changes from @brd's patch attached to the PR
• Delete spurious whitespace added in a comment.

In D39035#949271, @yuri wrote:

Can/should this be committed?

Thank you @fuz !

In D41349#946047, @mjg wrote:

tests can be moved to a different review which will land at a different date if that helps

this is definitely not a blocker for the routine

Does this change to contrib/netbsd-tests chase an upstream change, or is it changing the tests to accommodate this change?
I'm trying to reduce the amount of unnecessary change upstream so I can drop a new version of contrib/netbsd-tests, while also upstreaming all valid changes to NetBSD and it's become a bit difficult in some areas where folks have added FreeBSD-specific tests to contrib/netbsd-tests (which was not my original intent).
(FWIW I'm not saying this change is bad -- I'm just trying to stop this from being automatically seen as mergeable)

Accepting so the affected port's build can be unbroken.

dh_depr.c and dsa_depr.c are missing.

There are other deprecated APIs that we might want to include apart from just rsa_depr.c:

./crypto/openssl/apps/lib/tlssrp_depr.c
./crypto/openssl/crypto/dh/dh_depr.c
./crypto/openssl/crypto/rsa/rsa_depr.c
./crypto/openssl/crypto/dsa/dsa_depr.c
./crypto/openssl/crypto/bn/bn_depr.c
./crypto/openssl/ssl/tls_depr.c

In D41505#945636, @emaste wrote:

In D41505#945635, @arrowd wrote:

Wait, this is probably not enough. cardano-node was failing due to missing RSA_generate_key, which is also deprecated.

Yes this change is necessary but not sufficient. I think it's enough for vbox though?

@kbowling identified rsa_depr.c for RSA_generate_key; I'm looking at what else might be needed now.

This is the right thing to do, given that this gets compiled/linked in unconditionally upstream.

In D41410#942912, @se wrote:

The patch seems correct, but this dc implementation is not built by default on FreeBSD-13 or later, and thus only relevant for STABLE-12 (unless WITHOUT_GH_BC is defined, preventing the build of Gavin D. Howards much improved bc and dc programs). It is therefore definitely relevant for STABLE-12, but a NOP on STABLE-13 and CURRENT built with default options.