libmd (was Re: Having a single, good arc4random in Debian)

[Guillem Jover]

Hi!

[ Just posting to debian and fdo mailing lists, but this might be of
  interest to other distros, please feel free to forward. ]

On Mon, 2016-01-18 at 18:25:36 +0100, Marco d'Itri wrote:
> On Jan 18, Steven Chamberlain <steven at pyro.eu.org> wrote:
> > More background information follows.  What do others think about going
> > in this direction;  the Debian Security Team in particular?  Thanks!

> The same issue was discussed recently for the MD5 functions.
> The first step is to create a lintian test for packages which use an 
> internal copy of these functions.

This is something I've been a bit conflicted with for a while, and I'd
probably appreciate some input, particularly from potential users.

In comparison with the BSDs, GNU/Linux does not have basic message digest
functions available from the base system, and the BSD md functions end
up being embedded in most code, because they are pretty small, and it's
better than relying on one of the many libraries that might ship those in
some form, it's also a guaranteed way to have these present.

What I've been undecided on has been whether to add those to libbsd
(which already has MD5 functions since its inception), because that's
a compatibility library I can see some upstreams not willing to use, or
releasing libmd [M], which matches what some BSDs actually provide, so
some upstream already check for its presence, and it's a clean and
targetted API.

  [M] <https://git.hadrons.org/cgit/wip/libmd.git>

I'd probably prefer libmd as an independent library, because merging
it into, say, libbsd is trivial, but taking out the symbols implies a
SOVERSION bump, which I'd rather avoid.



Also I think it would be nice to be able to have something like libmd
in the base system, so that anything can use that w/o needing to embed
the code, nor having to pull in bigger or less "standard" APIs there.

And here's a small analysis (probably outdated by now, but I'd
appreciate corrections) I did quite some time ago, on why none of the
following seem suitable to me. Either because they contain much more than
needed, the functions are namespaced and/or on "non-standard" headers, the
language used, or the license might not be adequate for the calling code:

  rhash			C; MIT; rhash_ namespace
  libtomcrypt		C; PD; bloated (ciphers)
  libcrypto++		C++; PD; bloated (ciphers)
  botan			C++; BSD-2; bloated (ciphers + other)
  libheimdal-hcrypto	C; BSD-3; bloated (ciphers)
  libaprutil1-dev	C; APL + PD; bloated (general purpose),
  			   apr_ namespace
  libbind9		C; MIT + BSD-3; bloated (general purpose),
  			   isc_ namespace, only md5, sha1, sha2
  cyrus-sasl2		C; BSD-4 + RSA-advert; bloated (ciphers)
  beecrypt		C; LGPL2.1+; bloated (ciphers)
  libgcrypt		C; LGPL2.1+; bloated (ciphers)
  nettle		C; LGPL2.1+; bloated (ciphers)
  bglibs		C; LGPL2.1+; bloated (general purpose)
  libxcrypt		C; LGPL2.1+; bloated (crypt), only md5 and sha1
  nss			C; MPL, GPL2+, LGPL2.1+; bloated (ciphers)
  polarssl		C; GPL2+; bloated (ciphers)
  matrixssl		C; GPL2+; bloated (ciphers)

Thanks,
Guillem