fingerprint of key
duane at nofroth.com
Tue Aug 15 03:12:18 CEST 2017
-----BEGIN PGP SIGNED MESSAGE-----
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
>>> 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
>> --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
> 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
>> 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!
> 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 domain.com" 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 "--".
duane at nofroth.com
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users