It would be more idiot-proof to say that the user should run pkg upgrade perhaps.

• amd64/md5dispatch.c: remove _KERNEL conditional
• md5c.c: fuz@freebsd.org -> fuz@FreeBSD.org
• amd64: fuz@freebsd.org -> fuz@FreeBSD.org
• aarch64: fuz@freebsd.org -> fuz@FreeBSD.org

• stand/libsa: don't unroll md5 code when used in bootloader
• md5c.c: improve speed
• lib/libmd/amd64/md5dispatch.c: reorder headers
• md5c.c: bump copyright year
• amd64/md5block.S: deduplicate round keys
• aarch64/md5block.S: address comments

Yes, no objections, just possible refinements.

@mhorne Are you happy with the updated code? I would like to land the changeset soon.

Will do. I had to stop with the MD5 changeset as I noticed a performance regression on AMD Zen 4, which I will have to look into in more detail.

Looks like a reasonable safeguard.

In D52784#1208478, @markj wrote:

After looking at this some more, I suspect that using arc4random() directly here is not necessarily a good idea. Aside from wanting random TXIDs, we also want to avoid repeating them for as long as possible, so really this calls for an LCG periodic over 16 bits (which would require care to implement reseeding upon fork()) or a custom hash of the time of day. Though, it's hard to argue that the current scheme is very careful about TXID reuse...

• move lib/libopenbsd hunk to D52863

• re-add recallocarray to lib/libopenbsd when bootstrapping (for mandoc)

• move lib/libc/Versions.def change to D52878

• libc/resolv: re-add __res_rndinit as a compat symbol

One question on this one is that it drops the symbol __res_rndinit. I was unable to find any external user of this symbol and it seems like it is not meant to be used externally, but it's technically an ABI break. If desired I can go stub it out.

Your commit broke the kernel build, see: https://github.com/freebsd/freebsd-src/actions/runs/18086458935/job/51458390124

LGTM