Avoid symbol clashes between libmd and libcrypto

[thomas]

Summary

This change ensures that libmd does not define any symbol that is also present in libcrypto, providing a fix for PR 199119.

Test Plan

Tested by rebuilding and reinstalling libmd, rebuilding and reinstalling crontab(1), and observing that it did not hang anymore in a context where nss_ldap is used and connects to an LDAP server using SSL.

[roberto]

Looks reasonable to me.

[cperciva]

Looks reasonable to me; I use the same approach in the hash code I have in libcperciva. Is there a reason you're not doing this to md4 and md5 as well though?

[thomas]

I deliberately prefixed only those specific symbols that do clash with libcrypto. But indeed we could just as well consistently prefix all symbols in libmd.

[thomas]

Alternate version prefixing all symbols in libmd.

[bapt]

I was exactly looking into doing that ! that will allow to modify things in base to always only depend on libmd like libarchive (making it easier have the ports tree use only openssl from ports and/or libressl from ports)!

[thomas]

@cperciva @roberto would you mind commenting on the second version (updated to uniformly prefix all symbols in libmd, rather than just those that actually, currently conflict with libcrypto)?

Thanks!
Thomas.

[roberto]

Still OK with it, thanks.

[delphij]

Hi,

I got bite by this and used rS281372 to workaround it. Are you going to commit this anytime soon?

[delphij]

A second thought -- I wonder if we could use versioned symbols to achieve the same goal?

[thomas]

Not entirely clear to me how symbol versioning would help here. libmd provides just one version of these symbols, and we need to prevent any reference to the same-named symbols in libcrypto from getting (erroneously) resolved to the libmd version.

[bapt]

Version symbols will only help if openssl also have version symbol

[delphij]

In D2216#29, @thomas wrote:

Not entirely clear to me how symbol versioning would help here. libmd provides just one version of these symbols, and we need to prevent any reference to the same-named symbols in libcrypto from getting (erroneously) resolved to the libmd version.

I think @bapt was right that symbol versioning will not help (and it does not solve the conflict issue anyway).

BTW. @ume have pointed D1542 to me which uses __weak_reference to create compatibility symbols that would only be used when libcrypto is not present, could you please take a look at that changeset and see if it's sensible to adopt the same technique in this changeset? That would avoid the shared library bump and make the change MFC'able.

[thomas]

Indeed, the weak aliases make sense, and avoid the need to bump the major. I'll produce an update patch. Thanks!

[ume]

In D2216#33, @thomas wrote:

Indeed, the weak aliases make sense, and avoid the need to bump the major. I'll produce an update patch. Thanks!

I believe the patch in D1542 should solve your problem. Please try it.

[thomas]

New version introducing weak aliases

This is to avoid having to rebuild other binaries, or bump the
shared library major version. Succesfully tested against the
original issue as described in PR 199119 (crontab(1) hanging
when using LDAP with SSL for the password database).

[roberto]

Ok for me.

[delphij]

Looks good to me, thanks for working on this!

[thomas]

Unless further discussion takes place, I intend to commit the last version of this change at the end of the week.

[thomas]

Committed to head.