libmd, kern, stand: consolidate md5 implementations (NFC)
ClosedPublic
Actions

Authored by kevans on Mar 9 2022, 3:34 AM.

Details

Reviewers

andrew
jrtc27
emaste
allanjude
manu
delphij

Commits

rGe7a629c851d7: libmd, kern, stand: consolidate md5 implementations (NFC)

Summary

Reduce the number of md5c.c between the three of these from two to one
by just reaching into the kernel build for both userland builds. The
precedent for this already exists for sha2 in both cases.

_libmd_ symbol privatization bits have been moved to sys/md5.h and
md5.h remains to #include <sys/md5.h> for compatibility.

This stops exporting MD5Pad() in the process because the kernel stopped
exporting it in 502a35d60f4c. soversion is bumped accordingly.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 44711
Build 41599: arc lint + arc unit

Event Timeline

kevans created this revision.Mar 9 2022, 3:34 AM

Herald added a reviewer: manu. · View Herald TranscriptMar 9 2022, 3:34 AM

Herald added subscribers: dab, imp. · View Herald Transcript

kevans requested review of this revision.Mar 9 2022, 3:34 AM

Harbormaster completed remote builds in B44711: Diff 103663.Mar 9 2022, 3:34 AM

kevans added a child revision: D34498: libmd: stop exporting _block symbols.Mar 9 2022, 3:35 AM

Interesting, there are many other copies of libmd around (other BSDs, embedded in various software) that include MD5Pad, but checking Debian Code Search I see (unsurprisingly) no users. I am a little torn as our shlib guidelines desire avoiding version bumps, but it would also be silly to restore MD5Pad just to satisfy that.

In D34497#781737, @emaste wrote:

Interesting, there are many other copies of libmd around (other BSDs, embedded in various software) that include MD5Pad, but checking Debian Code Search I see (unsurprisingly) no users. I am a little torn as our shlib guidelines desire avoiding version bumps, but it would also be silly to restore MD5Pad just to satisfy that.

Yeah; I did a couple other things later in the stack to try and help justify it, as well. I think the *Transform symbols are in the same boat and they keep causing problems with various compiler/linker/flag combos because the implementation symbols should be exported as well.

Reviewed by: allanjude

This revision is now accepted and ready to land.Mar 9 2022, 6:42 PM

imp added inline comments.Mar 9 2022, 7:16 PM