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

[Simon Josefsson]

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> However, your patch changes the external API/ABI, which is something
>> we _really_ don't want to do unless we can avoid it.
>
> Only `_gnutls' functions are changed so does that really count as an
> API/ABI change (given that the `_gnutls' functions are not part of the
> documented API and are not meant to be used by application programs)?
>
> However, changing `_E_gnutls_openpgp_raw_privkey_to_gkey' may be an
> issue (ABI change in `libgnutls-extra').

Hi!  Right, changing _E_gnutls_openpgp_raw_privkey_to_gkey is the
problem, and it actually affects both libgnutls and libgnutls-extra
(the variable is defined in libgnutla).

Incidentally, I have been thinking about changing that stuff anyway,
because I think it was the only thing that required us to use
--enable-runtime-pseudo-reloc for mingw32, and generally, having
variables in a public API/ABI is not very good.

> Also, my understanding was that the API/ABI policy may be less strict
> for 1.7 than for 1.6?

Somewhat, for 1.6 it is not an option, but for 1.7 it is possible to
discuss it.

>> It seems a better patch would be to have
>> _gnutls_openpgp_raw_privkey_to_gkey be able to figure out the format
>> of the input automatically -- that seems possible to implement.  Just
>> go over the input and look for non-ASCII characters (or just some
>> specific non-ASCII character like \0, which I assume is guaranteed to
>> always be present in OpenPGP binary keys, to avoid problems with
>> non-ASCII characters in a Comment: field or similar), and set the
>> armor flag accordingly.  What do you think?  If you agree, I'd
>> appreciate if you could suggest a specific patch to implement this.
>
> That seems like a fragile solution, especially since the information
> (the input format) is already explicitly passed in
> `gnutls_openpgp_privkey_import ()'.  That said, perhaps we could
> implement this solution for 1.6 and keep the other one (or something
> similar) for 1.7.  Would that be acceptable?

It doesn't seem that fragile to me...

However, maybe this is a good place to take the opportunity to get rid
of the _E_gnutls_* variables entirely, and to fix your problem at the
same time.  I think that is the cleanest solution here.  nm suggests
that the entire variable list is:

00000000 B _E_gnutls_openpgp_get_raw_key_creation_time
00000004 B _E_gnutls_openpgp_get_raw_key_expiration_time
00000004 C _E_gnutls_openpgp_raw_key_to_gcert
00000004 C _E_gnutls_openpgp_raw_privkey_to_gkey
00000008 B _E_gnutls_openpgp_verify_key
00000000 B _E_gnutls_openpgp_fingerprint
00000004 C _E_gnutls_openpgp_key_deinit
00000004 C _E_gnutls_openpgp_key_to_gcert
00000004 C _E_gnutls_openpgp_privkey_deinit
00000004 C _E_gnutls_openpgp_privkey_to_gkey
         U _E_gnutls_openpgp_raw_key_to_gcert
00000004 B _E_gnutls_openpgp_request_key

The variables are implemented in libgnutls-extra and used by
libgnutls, when libgnutls-extra is loaded, only in lib/auth_cert.c and
lib/gnutls_cert.c.  I'm not yet sure how to do this, ideas and
suggestions most welcome.  Perhaps more code related to openpgp should
be moved from libgnutls to libgnutls-extra.

>> Btw, to be able to use your patch, we'd might need a copyright
>> assignment, if the patch is large..  would that be a problem?  I can
>> send you the forms offline.
>
> No problem, you can send it to me.

Great, I'll send it by private e-mail.

/Simon