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

Simon Josefsson simon at josefsson.org
Tue Jan 16 11:14:35 CET 2007


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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Installed in CVS now.  Could you suggest the patch to fix your
>> original problem, using this new scheme?
>
> Thanks for doing it!  Attached is the updated patch.

Applied.

>> I just realized a thing: I'm not sure we are really breaking the
>> API/ABI here though.  No public API/ABI is modified, only internal
>> _gnutls_* APIs.  The same holds for your first patch.
>
> Indeed, no _public_ ABI/API is modified.  That said, the ABI _is_
> modified: one cannot use an older `libgnutls-extra' with a newer
> `libgnutls' (or vice versa).  But that would have been an issue only if
> one had been allowed to use different versions of `libgnutls-extra' and
> `libgnutls' together.

Right.  That has never been allowed, and I don't see the point in
permitting that.  libgnutls and libgnutls-extra are tightly coupled.

> In my original message [0], I had in mind something that would implement
> a slightly higher abstraction level over certificate types, such that no
> X509/OpenPGP-specific code and no `switch (certtype)' need to appear in
> `auth_cert.c' et al.  For instance, we'd move the
> `proc_{x509,openpgp}_server_certificate ()' functions to specific files,
> and instead just call
> `_gnutls_cert_vtable[certtype].process_server_certificate ()', and so on.

Yes, I think that would be nice.  All the code could then do something
like:

 if (_gnutls_cert_vtable[certtype])
   _gnutls_cert_vtable[certtype].process_server_certificate ()
 else
   return GNUTLS_E_INIT_LIBEXTRA;

Would you like to propose a patch for that?  I'd expect it to only
require changes to gnutls_cert.c/auth_cert.c...

/Simon





More information about the Gnutls-help mailing list