HEADS UP: OpenSSL problems after GCC 4.2 upgrade

Colin Percival cperciva at freebsd.org
Mon May 21 19:37:40 UTC 2007

Kris Kennaway wrote:
> On Sun, May 20, 2007 at 07:45:18AM -0400, Colin Percival wrote:
>> For the record (since I know several people were asking at BSDCan), this is
>> a great example of why it makes sense to have libmd as well as libcrypto: A
>> minimal hashing library which we maintain ourselves is far less likely to
>> randomly break than a bloated^W more feature-complete library which is
>> maintained outside of FreeBSD and occasionally imported onto a vendor branch.
> Well that's kind of a straw man because it's not actually what I
> suggested.

You're not the only person who was asking about libmd vs. libcrypto.  There
are two suggestions which come up frequently (including at bsdcan):
1. Kill libmd entirely and tell people to link to libcrypto instead.
2. Kill src/lib/libmd/*.c and build libmd from the C code in crypto/openssl.

> I was advocating [option #2]
> At least the last time I looked at openssl this was possible, and one
> ends up with something very similar to our current libmd, plus
> additional bug fixes.

Several reasons for not doing this come to mind:
1. It takes longer to fix bugs in contrib code (e.g., the current problem had
to wait for our OpenSSL maintainer to return to .dk, while a bug in libmd
could have been fixed immediately -- I don't think the current bug affects
the hashing functions, but the point remains).
2. Importing a new version of OpenSSL is enough of a headache already without
needing to make sure that everything is where libmd expects to find it and
doesn't require any changes in the compile options.
3. The license on the current libmd code is more sane.  I don't want to have
to include "This product includes cryptographic software written by Eric Young
<eay at cryptosoft.com" every time I mention that Portsnap uses /sbin/sha256.
I don't advocate removing code from FreeBSD just because it has an advertising
clause in its license, but I do think that the spread of such licenses should
be limited.
4. Having non-contrib code rely on contrib code to build is just plain ugly.

Colin Percival

More information about the freebsd-current mailing list