fingerprint of key

Duane Whitty duane at
Tue Aug 15 03:12:18 CEST 2017

Hash: SHA256

On 17-08-14 09:50 PM, Duane Whitty wrote:
> On 17-08-14 08:50 PM, Daniel Kahn Gillmor wrote:
>> On Mon 2017-08-14 19:03:19 -0300, Duane Whitty wrote:
>>> I did not and still do not want to import the oracle_vbox
>>> public key into my key ring.  I am happy to download it and
>>> check it each time.
>> I think this is an interesting choice, but i don't understand
>> why you've made it.  Can you say more about why you don't want
>> to import the key, and why you prefer to fetch it each time?
> I perceive keys in my keyring as being ones I trust because of 
> out-of-band confirmation and used for two-way communications.  I
> think the VirtualBox key is just to give people assurance that they
> are downloading what they intended to download from the source
> they expected, in this case via apt or apt-get, etc. from an Oracle
> repo.
>>> Before I go down the road on offering an opinion on how the
>>> man page should be "fixed" (maybe it's not really broken) can
>>> you explain why it would be bad to let gpg generate and display
>>> the fingerprint of a key in an ascii armoured file?
>> I'm not saying it's "bad" -- it's just not what --fingerprint 
>> does.
>> --fingerprint List all keys (or the specified ones) along with 
>> their  finger‐ prints.  This  is  the  same  output as
>> --list-keys but with the additional output of a line with the
>> fingerprint.  May also  be combined  with --list-signatures or
>> --check-signatures. If this command is given twice, the
>> fingerprints of all  secondary keys are  listed  too.   This
>> command also forces pretty printing of fingerprints if the keyid
>> format has been set to "none".
>> So it's like --list-keys, which says:
>> --list-keys -k --list-public-keys List the specified keys.  If
>> no keys  are  specified,  then  all keys from the configured
>> public keyrings are listed.
>> in other words (or maybe it's not as explicitly stated as it
>> should be), "list all the keys in your keyring that match the 
>> specification".  This command is not intended for listing 
>> fingerprints of keys that come in on stdin, or of an external 
>> file.
> To me that reads as "if you provide a key then the fingerprint for 
> that key will be provided otherwise your keyring will be used". 
> Thanks for correcting my understanding.
>> That said, you could combine it with:
>> --no-default-keyring --keyring /path/to/file.gpg
>> (as long as the file wasn't ascii-armored, and as long as you 
>> weren't concerned about updating your trustdb by accident, etc).
>>> Again, i'm not saying this is particularly user-friendly, i'm 
>>> just
>> trying to help you understand the current state of the tool.
>> If you have specific suggestions for how to improve the tool, 
>> please suggest them!
>>> --dkg
> I'm not exactly sure what a good suggestion would be.  Would it be 
> correct to say that going forward usability changes would probably
> be more likely to happen in the 2.1 branch?  If so I guess I
> should upgrade to the 2.1 branch.
> I can say that what I usually end up being challenged by is
> importing keys into my keyring and on being able to choose which
> UID I want to sign with.  Maybe that just means I don't know the
> software well enough.
> For instance, last night I wanted to add a friend's new public key
> to my keyring.  Gpg wouldn't add the key based on his email.  I had
> to use his email to search the key server and then use the
> fingerprint of his new key to add it to my keyring.
> The approach I took was "gpg2 --search user at" and "gpg2 
> --recv-keys key-fingerprint".  Then I did a "gpg2 --edit-key 
> key-fingerprint" to sign the key with my default UID.  I thought I 
> would get a menu to select options from when I used --edit-key but 
> instead I was presented with the prompt "gpg>" and I had to type
> the sign command.  It worked but I might have chosen to sign the
> key with a key from a different UID.  Not sure if my method of
> importing to my keyring and signing the new public key was the
> usual or easiest method but it worked.
> Not sure there's actually a suggestion for improvement in there
> :-) but you've given me a lot to consider and digest.  Sincerely,
> thanks! I love learning this stuff.
> Best Regards, Duane
Actually one suggestion, the way options and commands are specified
look the same.  It might make things clearer if there was a difference
in the way they are expressed on the command line.  Perhaps keep the
"--" for options and enter commands without the "--".

Best Regards,

- -- 
Duane Whitty
duane at


More information about the Gnupg-users mailing list