help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnutls] gnutls_openpgp_privkey_import() behavior seems inconsi


From: Nikos Mavrogiannopoulos
Subject: Re: [Help-gnutls] gnutls_openpgp_privkey_import() behavior seems inconsistent depending on choice of "format" variable
Date: Fri, 04 Apr 2008 23:57:51 +0300
User-agent: Thunderbird 2.0.0.6 (X11/20071022)

Daniel Kahn Gillmor wrote:
On Thu 2008-04-03 13:48:37 -0400, Nikos Mavrogiannopoulos wrote:

This is not quite easy to fix since it depends on the internals of
opencdk. As far as I remember opencdk auto detects the input data
and acts accordingly. However in gnutls we specifically set the
raw/base64 flag. An improvement I could think would be to check the
data after the import in order to verify that import was successful.

Does the attached patch solve the issue for you?

Thanks, Nikos.  That's certainly an improvement -- i now get
GNUTLS_E_OPENPGP_GETKEY_FAILED when i try a privkey_import in RAW mode
but the incoming datum is BASE64-encoded.  I think this patch should
be applied to the master branch.

Thanks for trying. Applied.

However, i don't get any failures when i set format to
GNUTLS_OPENPGP_FMT_BASE64, whether the input is raw or not.  In fact,
i can successfully import the key and use it regardless of the input
format as long as i've set format this way.

This is not easy to fix and I'll leave it for now.

So: why bother with this parameter to privkey_import, since one
setting (FMT_BASE64) works no matter what kind of input you've got?
Why would anyone choose FMT_RAW?

It is cleaner to specify what you want to import. The future API might not autodetect the input data.

The inconsistency between format flags is confusing and unpredictable
From the docs; and unpredictability is a property that's undesirable
in a library, no?

The flags should be used as documented. The functionality to being able to import raw when specified base64 is not documented and might be removed at future versions.

regards,
Nikos




reply via email to

[Prev in Thread] Current Thread [Next in Thread]