gnupg: request for small change in output

David Shaw dshaw at jabberwocky.com
Sat Oct 4 05:21:01 CEST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 03, 2003 at 07:29:48PM -0600, Nelson H. F. Beebe wrote:
> Greg Black <gjb at gbch.net> writes on Sat, 4 Oct 2003 10:53:25 +1000:
> 
> >> Seems like a good idea to leave things as they are.  And then
> >> somebody might get around to fixing the key servers that have
> >> the silly requirement for the leading 0x; in the meantime, it's
> >> not that hard to add it in to a cut'n'paste of the ID.
> 
> I doubt that key servers will make that change: the leading 0x shows
> definitely that the string is not a personal name, and may be used to
> redirect lookups into lookups-by-key and lookups-by-name.  There are
> legitimate personal names that can be spelled with hexadecimal letters
> A-Fa-f: Abe, Babe, Bade, Bead, Beef, Beebe (my own name), Dacca, Dade,
> Decca, ...
> 
> While experts might remember to supply the 0x prefix in lookups on key
> servers, novices will likely not, and might erroneously conclude that
> the key is not registered.
> 
> PGP includes the 0x prefix in all of its output.
> 
> I therefore contend that gnupg DOES need a change, and that the change
> is very simple ([s][n]printf formats %08x become 0x%08x), and doesn't
> impact any of the I18N language translations (apart from the trivial
> substitution of the format item).

It's not that simple.  Putting an 0x in front of the key ID (or not)
needs to be done consistently.  Putting 0x in this one place impacts
the rest of the user interface that doesn't have the 0x.

I don't find the keyserver argument convincing.  I feel that output
intended for human beings should not be designed based on input
requirements of machines.  It's a few lines of code to fix the
keyserver to handle input without the 0x (exactly 8 digits of 0-9/A-F
is a reliable indication of a key ID), and if that is where the
problem is, then better to fix the keyserver.

In any event, which keyserver are you optimizing for?
hkp://pgp.mit.edu requires 0x, but ldap://keyserver.pgp.com and
mailto://pgp-public-keys@pgp.mit.edu both require NO 0x.  (And yes,
both pgp.mit.edu servers are the same machine (even the same program),
but require two different syntaxes.)

This is really an issue of consistency.  You and I know that
"0xA93C57C2" is identical to "A93C57C2", but there are (not a small)
number of people out there who see these as two different things.

$ gpg --list-keys 0xA93C57C2
pub   1024D/A93C57C2 2003-01-30
uid        [unknown] Nelson H. F. Beebe <beebe..............>
sub   2048g/88DE0889 2003-01-30

Here, I specified 0xA93C57C2, but got A93C57C2.  If signature
verification has an 0x, but key listings don't, and --edit-key
doesn't, and some random other place does, then we have confusion.

Note that I'm not arguing against putting 0x in here.  I'm arguing
that IF an 0x is put in here, it should be put in everywhere key IDs
are displayed.  A corollary to that argument is that such a change is
significant enough to break scripts and assumptions, and therefore
shouldn't be done in the stable code branch.

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.3-cvs (GNU/Linux)
Comment: Key available at http://www.jabberwocky.com/david/keys.asc

iHEEARECADEFAj9+LuwqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk
L2tleXMuYXNjAAoJEOJmXIdJ4cvJ2XAAnA/SoAU5YUyhUNzLdVu62IniKlOfAJ9P
Sq71osSYJmyBkGcrwnwLpx5tYA==
=U68i
-----END PGP SIGNATURE-----




More information about the Gnupg-devel mailing list