Integrating crypto functions?

[Simon Josefsson]

Hi.  I'm using some crypto functions in gsasl, shishi and gnutls that
I'd like to move to gnulib.  md5 and sha1 are already in gnulib,
although with a different API.  Before submitting patches, there are
some things I'd like to discuss:

1) Is it ok to have crypto functions in gnulib?  Is there crypto
   politics still causing problems in this area?

2) Could we re-license the sha1 module under LGPL?  There are several
   free sha1 implementations around.  The GPL sha1 in gnulib appear to
   be greatly inspired by the LGPL md5 gnulib module.  All the
   packages above need LGPL modules?

3) All my packages should optionally use crypto functionality through
   libgcrypt instead.  This means two things: First, a generalized
   crypto API that has two "backend" implementations, one API
   implementation on top of the gnulib modules, and one that wraps
   around libgcrypt.  Secondly, there need to be some M4 magic to
   detect if libgcrypt is installed and pick the right implementation.
   All of this are already part of my packages, and has been for
   months (gnutls) or years (gsasl/shishi) but they are not tightly
   synchronized with each other so they have forked slightly from each
   other due to different requirements.  (In theory, you could add
   more "backend" libraries that implement the same crypto API, other
   than the gnulib and libgcrypt back ends, or even have a hardware
   crypto accelerator, but right now I'm focusing on supporting
   libgcrypt with a fallback to gnulib crypto modules if libgcrypt is
   not available.)

How does this sound?

Thanks!