[gnutls-dev] Fixing OpenPGP keyring import

[Timo Schulz]

Ludovic Courtès wrote:

> Yes, but my patch uses `CDK_DBTYPE_PK_DATA' because the data comes from
> a user-provided buffer, not from a file.  In this case,
> `cdk_keydb_new ()' just creates a temporary stream from the user buffer,
> without leaving the opportunity set/clear that stream's armor flag.

OK, I fixed it in the CVS. The backport is pretty easy and just two
lines.


> It would be best to at least have the ability to not rely on automatic
> detection of the format, especially since callers pass a FORMAT

Actually this is a format for the structure, not the data itself.
Format: file, stream, buffer. Maybe I did not describe this very well :-(.

The idea was to auto detect base64 data and decode it. With the
new code, cdk_keydb_new_from_stream () no decoding is done.


> That would allow `gnutls_openpgp_keyring_import ()' to support both
> base64 and raw in a straightforward way.

OK, the stream version is also available in the CVS.
Just for clarification, I change/patch the code in HEAD, not the
nmvav-0-5-x branch GnuTLS currently uses.

> Are you considering implementing it in a future version?

As I said, it's done. Actually the new release 0.6.0, is not released
yet but the code is in the CVS. I will wait until the discussion is
done so I definitely know what to add/change in OpenCDK.


>>> thereby fixing our problem.  It would also have the advantage of not
>>> breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in
>> ..if the only reason for the new code is that base64 data is not supported,
> 
> Then what?  :-)

Sorry. It should be "if this is the only reason for the new code". IMHO
the issue is fixed with the armor support for CDK_DBTYPE_DATA and the
new cdk_keydb_new_from_stream() function.

As I said, the backport is pretty easy. But I would suggest to think of
a migration strategy because I fixed a lot of other stuff and GnuTLS
would definitely benefit of the new code.


	Timo