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! _______________________________________________ bug-gnulib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnulib
