gnupg: request for small change in output
dshaw at jabberwocky.com
Tue Oct 7 15:10:01 CEST 2003
On Sun, Oct 05, 2003 at 07:19:50PM -0400, Michael H. Warfield wrote:
> On Sat, Oct 04, 2003 at 09:48:18AM -0400, David Shaw wrote:
> > On Sat, Oct 04, 2003 at 07:13:05AM -0400, Jeff McAdams wrote:
> > > 8 digits of 0-9/A-F is not a reliable indication of a key ID (maybe
> > > within gpg it is, but not in the overall), because that includes the
> > > possibility of 8 digits of just 0-9, which could be a decimal number,
> > > not hexidecimal, or 8 digits of 0-7, which could be an octal number, not
> > > hexadecimal.
> > I am unconcerned about the various possible sequences and meanings of
> > 8 digits in the outside world because in our particular problem space
> > (PGP, GnuPG, and keyservers), 8 digits of 0-9/A-F means keyid.
> DEADBEEF :-)
> True, this one is problematical, anyways...
> your interpretation is!
Yes, the whole idea of signaling "this is a keyid", or "this isn't a
keyid" in-band is a problem. The same thing happens if a string
prefixed with an 0x is searched for, but isn't a keyid.
Search for 0xD79D3451. Should you get back key D79D3451 or key
01B3AF49 (look at the user ID string on this key)? Or both?
The LDAP keyserver moves the keyid indicator out of band and avoids
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 330 bytes
Desc: not available
Url : /pipermail/attachments/20031007/008f7e58/attachment.bin
More information about the Gnupg-devel