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

[Ludovic Courtès]

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.

> 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?

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.

> 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

> 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')!  ;-)

Thanks,
Ludovic.