[Help-gnutls] Re: Failure to import an OpenPGP private key

[Simon Josefsson]

ludovic.courtes at laas.fr (Ludovic Courtès) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Good ideas!  I agree that we should use function indirections rather
>> than variables, because having variables be part of a API/ABI is a bad
>> idea, and causes problems on mingw32.  So there would be two
>> functions:
>>
>> void gnutls_certtype_add (int certtype, struct gnutls_certtype_functions *hooks)
>>
>> struct gnutls_certtype_functions * gnutls_certtype_get (int certtype)
>>
>> which would register a new certtype with GnuTLS.
>>
>> As prototyped, that would use global variables, which probably is a
>> bad idea, but I'm not sure what a good alternative would be -- more
>> thoughts about that is required.  Perhaps this should be set
>> per-session?  But that creates some extra work for every session, and
>> that seems annoying...  OTOH, that could be hidden in
>> gnutls_credentials_set() when it detects an openpgp cert.  Or even
>> more generally, when gnutls_credentials_set() detects a unknown
>> certtype, it requests a vtype for the certtype.  Somehow.
>
> I don't see any benefit in having per-session certificate types:
> certificate types exist independently of sessions, conceptually.

Yup.  Making them per-session would be a way to avoid global
variables, though.

>> OTOH, if we call the functions _gnutls_certtype_add and
>> _gnutls_certtype_get instead, and document that they should only ever
>> be called by libgnutls-extra, and never by external programs, it seems
>> fine to use a global variable to store the function pointers --
>> different applications will never set different pointers, and they
>> will only ever be either NULL values or pointers to the loaded
>> gnutls-extra library.  What do you think?
>
> The question to ask is how much flexibility is needed, and how
> independent `libgnutls' and `libgnutls-extra' should be from each other?
>
> Currently, the set of certificate types is fixes and (I suppose)
> unlikely to change too often.  So we have `gnutls_certificate_type_t' as
> an enum whose values are statically assigned in `libgnutls'.
>
> If we were to opt for full flexibility (and a user-visible certificate
> type registration mechanism), then we could have something like this:
>
>   in libgnutls:
>
>     typedef void *gnutls_certificate_t;
>
>     typedef struct gnutls_certificate_type
>     {
>       const char *name;
>       int (* certificate_init) (gnutls_certificate_t *);
>       ...
>     } *gnutls_certificate_type_t;
>
>   in libgnutls-extra (initialization code):
>
>     openpgp_cert_type = gnutls_certificate_type_new ("OpenPGP", ...);
>
> The issue is that this adds quite a bit of overhead (at initialization
> time mostly) and this requires us to have a very well chosen set of
> per-certificate-type methods so that people can actually implement
> unforeseen certificate authentications.  But maybe such a thing would be
> over-designed?

Yes, I think so.  We can't anticipate what requirement future
certificate types might have, and it will likely not be generic enough
anyway.  This kind of abstraction isn't part of the TLS standard
anyway, so it makes little sense to over-design in this area.

> Thus, I had in mind a simpler approach, were `gnutls_certificate_t'
> remains unchanged (i.e., static), and where the certificate type
> registration API is purely internal.

This seems simpler, yes... so the registration functions should
probably be called _gnutls_register_extra_openpgp_certtype() or
whatever.  This avoids giving false expectation too.

>> Well, yes, but since it breaks API/ABI it is not for 1.6, and for 1.7
>> we can think bigger. :) But if you want, and write a quick fix for
>> this, that would break the API/ABI, we can install it now, and then
>> work on the above plan next (which also breaks the API/ABI, but for
>> good reasons).  I doubt it will save much time, though...
>
> Would the fix I originally posted (and which breaks API/ABI) be
> acceptable for 1.7 in the short term?
>
>   http://lists.gnu.org/archive/html/help-gnutls/2006-12/msg00005.html

Yes, that seems ok.  I'll see if I can implement the above, cleaner,
approach fast though.  Or if you want to work on that... :) If I
forget about this, just remind me and I'll apply your patch.

>> If you plan to work on this, you need to fill out a copyright
>> assignment form for us to be able to use the work.  If this is ok, I
>> can send you the form to use.
>
> Hey, you just sent it a few hours ago (and I already sent it to
> `assign at gnu.org')!  ;-)

Well, duh.  That would explains my sense of deja vu, then.  Sorry.

/Simon