[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