[gnutls-dev] Porting bug fixes to 1.6.x
simon at josefsson.org
Tue May 29 15:44:55 CEST 2007
ludovic.courtes at laas.fr (Ludovic Courtès) writes:
>> Yes, I think we should push out 1.8.0 (or 2.0.0) within a few weeks or
>> so, if we can settle all open issues with it. Perhaps that would be
>> sufficient, and you don't need 1.6.x with (only some of) the OpenPGP
>> fixes? 1.8 will contain the new OpenCDK 0.6.x and all the fixes.
> If 1.8 is so close, then we (at least I) can probably live without
> back-porting bug fixes into 1.6. Initially, I thought 1.8 was further
> away from now.
Well, let's try to make 1.8 happen as soon as possible. If it takes
more than a month, then we can re-evaluate it. Of course, if you want
to go through the trouble of applying the patches to the 1.6.x branch on
some git clone, I could probably learn how to pull in those changes into
my own git tree and make a 1.6.4 release of it. Might even be useful as
git learning experience...
>> Btw, having the guile bindings be part of 1.8 is a good idea. I think
>> it should be a blocking milestone for it. So now my todo-list for 1.8
>> * Integrate Guile bindings.
> Then I'll start working on it this week (that shouldn't be too much
>> * Fix sign callback API to be per-credential rather than per-session.
> Oh, good.
I'll probably start to do that on a new branch, based on the most recent
1.7.x. The current pkcs11-branch did it per-session, and it is probably
more work involved trying to revert those changes than creating a new
> BTW, will your PCKS#11 work get into 1.8?
I'm not sure how it should be integrated. I strongly want GnuTLS to
support OpenPGP cards easily, although I'm not sure it makes sense to
have GnuTLS provide a full-blown native PKCS#11 interface.
I'm currently not sure whether to label the support as 'libgnutls-scute'
since it links to scute at build-time, or rename it as
'libgnutls-simple-pkcs11' and add some dlopen() stuff.
One reason against calling it 'libgnutls-pkcs11' (the current name) is
that we probably won't support all variations of pkcs11 modules, with
PIN entry callbacks and so on. On the other hand, if we can support 90%
of the common uses of PKCS#11 through a simple API, I think we should
include that into GnuTLS natively.
I suppose the options are:
1) Ship libgnutls_scute.so which links directly to scute, and provides
some APIs like gnutls_scute_get_user_certificates,
gnutls_scute_get_ca_certificates, gnutls_scute_sign_callback. The
problem here is that it is scute-specific, even though I think other
PKCS#11 plugins may easily be supported too by just replacing
libscute.so with something else.
2) Ship libgnutls_simple_pkcs11, or perhaps rather libgnutls_spkcs11.so,
which would dlopen a library, and provide an API like
possibly gnutls_spkcs11_set_pin_callback. The problem here is that
we might not be a full-blown PKCS#11 implementation at day one, with
support for every variation of PKCS#11 features. However, if we can
support some other PKCS#11 plugins easily through this route, I think
it is the best one.
Of course, applications can always be able to use the sign callback
interface themselves, and implement a really full-blown PKCS#11
interface using an external library, or a CrytoAPI interface, or
whatever. Neither option 1) and 2) forces applications to use PKCS#11
or Scute through our libraries.
I think I'm leaning towards 2) and stating in the release notes that we
haven't tried all PKCS#11 provides on the earth, and that there may be
significant missing functionality, and that patches are welcome.
However, implementing the dlopen() stuff may be non-trivial, and to save
time, perhaps we could settle with a gnutls-scute solution. It feels
somewhat sub-optimal though.
More information about the Gnutls-devel