[gnutls-dev] Porting bug fixes to 1.6.x

[Simon Josefsson]

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
>> is:
>>
>> * Integrate Guile bindings.
>
> Then I'll start working on it this week (that shouldn't be too much
> work).

Great!

>> * 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
branch.

> 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
   gnutls_spkcs11_dlopen, gnutls_spkcs11_get_user_certificates,
   gnutls_spkcs11_get_ca_certificates, gnutls_spkcs11_sign_callback,
   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.

/Simon