[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Integrating crypto functions?
From: |
Simon Josefsson |
Subject: |
Integrating crypto functions? |
Date: |
Sat, 01 Oct 2005 14:21:25 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
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!
- Integrating crypto functions?,
Simon Josefsson <=