[Help-gnutls] Re: Failure to import an OpenPGP private key
ludovic.courtes at laas.fr
Tue Jan 9 15:40:48 CET 2007
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
> 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:
typedef void *gnutls_certificate_t;
typedef struct gnutls_certificate_type
const char *name;
int (* certificate_init) (gnutls_certificate_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
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?
> 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')! ;-)
More information about the Gnutls-help