gnupg: request for small change in output
jeffm at iglou.com
Sat Oct 4 14:11:01 CEST 2003
Also Sprach David Shaw
>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.
I don't find the keyserver argument convincing, either. What I *do*
find convincing is that the keyid is a hexadecimal number. hexadecimal
numbers are nearly universally printed as "0x....", not just in gpg or
pgp, or related apps. If your argument is consistency, then that's an
argument *for* the 0x.
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. These prefixes are nearly universally used for a reason,
to disambiguate the display of these types of numbers.
>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.
Within the realm of gpg, yes, they are the same, but in the overall
world, "0x12345678" is much less ambiguous than "12345678".
>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.
Agreed...it should be changed everywhere.
>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.
Fair enough argument. I think the change should be made, but I do think
its pretty minor, and in the fact of breaking scripts, etc. it probably
should be done in a development branch, yes.
"He who laughs last, thinks slowest." -- anonymous
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
Url : /pipermail/attachments/20031004/7ceb48d0/attachment.bin
More information about the Gnupg-devel