Re: fingerprint of key
On Thu 2017-08-17 22:39:21 -0300, Duane Whitty wrote: > Sounds like a good approach but for someone who has more public keys > stored than me. I only exchange encrypted email with a very, very > small group of people and I am in regular voice communication with > them. If you're going to manage a keyring manually, this is the right way to do it, regardless of how many OpenPGP certificates you have in your keyring. (it's actually easier to do when you only have a few) > I guess using that approach I could import public keys from users on > this list and then assign them various levels of trust, right down to > no trust and not locally signed at all. Note that nothing i outlined in my earlier suggestions involved you setting "trust levels" (a.k.a. "ownertrust") at all. setting "full trust" on a key means "i'm willing to accept identity assertions made by the owner of this key" -- it's equivalent to "adding a root CA to your browser" in some sense. You can use GnuPG for years without ever setting any sort of ownertrust on any key but your own (and if you generated your key in gpg, it probably already has ultimate ownertrust). Start with "whose keys do i believe i've checked?" -- that's plain keysigning. then, only later, if you really want to get into the whole web-of-trust thing, should you consider setting ownertrust. > I suppose I chose to use apt or apt-get because it seems like a more > convenient way to update things as opposed to getting it straight from > Oracle. well said :) > What I mean is that I have 2 email addresses which each have a > different private key. The key for du...@nofroth.com has is > associated with private counterpart to the key you fetched. I have > another email address with a different private key associated to it. i see, so you're talking about signing with a different key (not a different uid). You might want to look into adding the --default-key or --local-user options before you do your next --edit-key operation. All the best, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
On Thu 2017-08-17 22:48:36 -0300, Duane Whitty wrote: > Well, I'm not familiar enough with the arcana to say whether it should > be done away with or not but, I am a big believer in software not > trying to guess what I want. As you said, in version 2.1 GnuPG would > have complained that I hadn't entered a command, correct? Does this > also mean it would have not carried out any action. nope, GnuPG took the conservative approach and just produced a warning while still trying to make a guess at what you meant. > I have to admit to being a little hesitant making these types of > comments because I don't feel I contributed enough (if anything) to > have earned that right. But perhaps as a user the comment is a small > contribution. I hope it is seen that way and not as a complaint. Please don't underestimate the value of suggestions and questions from a user. Free software gets better because its users talk about it and share ideas about how it can improve. You don't need to have contributed code to contribute ideas :) --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17-08-17 09:20 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 22:12:18 -0300, Duane Whitty wrote: >> 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 "--". > > I also prefer this kind of "subcommand" syntax -- it matches what > tools like git and notmuch use. However, that's a pretty radical > departure from the historical GnuPG command line, and it's likely > to break all sorts of existing things that expect to use the > canonical interface. > > If we're going to make radical departures like that, perhaps we > should be specifying an entirely new interface that just does "the > sensible bits" without all the rest of the arcana. > > --dkg > Well, I'm not familiar enough with the arcana to say whether it should be done away with or not but, I am a big believer in software not trying to guess what I want. As you said, in version 2.1 GnuPG would have complained that I hadn't entered a command, correct? Does this also mean it would have not carried out any action. In my opinion that would be the correct behaviour. I am also a fan of the Unix tradition of software that completes without error not having any output unless you have asked for output. Error output going to stderr of course :-) I have to admit to being a little hesitant making these types of comments because I don't feel I contributed enough (if anything) to have earned that right. But perhaps as a user the comment is a small contribution. I hope it is seen that way and not as a complaint. Best Regards, Duane - -- Duane Whitty du...@nofroth.com -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZlkdxAAoJEOJfpr8UVxtkwXwIAKg6U2hJM2v0469V3Q+dr2k8 6cn8+6nwdkARZQhABP+iSOLbFcnaGL2RLzw26+47E3pqf1X837VeHnsdBZvzQYTQ oXB/0YTmhjsjL6hpN1V5N5+CHkmMwbwyoHD7XGFpETA/1RfgrhlkqUtcfqjBCUw6 zAvUeD6/rxhASeBb1A231924iSUFqqhkf0IXGvgJmrmIU2hPCZPkdwnxEQ+Lm5K5 8AhsnEKdE3mABlqr0mMM/uuYLI1bknxYT2QtIU2Q1gwH0af4+WqLdcv9H4dMAmQS HYfYv8s8MAyoqPNZs2QXOg76TBhPHF382MYLGCzT9rHMWaRLk/6zmCZKOSiGtO0= =5mpS -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17-08-17 09:18 PM, Daniel Kahn Gillmor wrote:
> On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote:
>> I perceive keys in my keyring as being ones I trust because of
>> out-of-band confirmation and used for two-way communications.
>
> You're not the only person with this perception. But i'm afraid i
> think it's a mistake, unfortunately.
>
> Actually safely curating an OpenPGP keyring with GnuPG is a
> non-trivial task. As an example, here's a damned-if-you-do,
> damned-if-you-don't conundrum:
>
> Do you refresh the OpenPGP certificates in the keyring
> regularly (e.g. from the keyservers)? if you do not, then you risk
> missing notice of revocations, so you probably have some revoked
> keys in your keyring which you didn't know you had.
>
> If you do refresh them regularly, then it's possible that things
> (new user IDs, etc) get added to the certificates in your keyring
> during the refresh (or possibly whole new certificates get added
> entirely), and it contains things you've never actually vetted.
>
>
>
> So, how to resolve this?
>
> The short version is that you should treat your GnuPG keyring as
> an untrusted collection of OpenPGP certificates that you know
> about. But you can explicitly mark the certificates that you think
> are legitimate by certifying them ("signing the keys"). In
> particular, you can make non-exportable ("local") signatures over
> the key+userid combinations that you have actually confirmed
> out-of-band.
>
> Even better, if you do that with a key which you have marked with
> "ultimate" ownertrust, then GnuPG will report a "validity" for
> those user IDs you've signed that matches what you intended to do,
> which is to curate a list of known-valid key+userid combinations.
>
> But treating the whole local keyring as a curated store is a
> mistake. GnuPG doesn't work that way, and it doesn't expect to work
> that way :(
Sounds like a good approach but for someone who has more public keys
stored than me. I only exchange encrypted email with a very, very
small group of people and I am in regular voice communication with
them. But I definitely see the merit in what you describe and believe
that it is a cautious way of proceeding. I may even try working that
way just to practice for the day when perhaps I consider it necessary
to exchange encrypted mail with people I don't know well and don't
talk with in person or on the telephone regularly.
I guess using that approach I could import public keys from users on
this list and then assign them various levels of trust, right down to
no trust and not locally signed at all.
>
>> 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.
>
> If you fetch the key each time you download something that you want
> to check against the key, how do you know it's the right key over
> time? If it's "the right key" because it was fetched over a secure
> channel from Oracle, why not just fetch the software over that
> channel?
>
I suppose I chose to use apt or apt-get because it seems like a more
convenient way to update things as opposed to getting it straight from
Oracle.
> The advantage of having a key stored locally is that you only have
> to risk that network-fetch once; then you can make a local
> certification over its sensible VirtualBox User ID, to mark it as
> the expected key (If the User ID is *not* sensible, please complain
> to VirtualBox!). Then all future updates can be verified against
> the same key.
>
> Do you see how that's better than fetching the key each time?
>
Well, I see it potentially as less work but not less risk. I
downloaded the key using wget and https. Then I check the validity of
the key by comparing the fingerprint generated by GnuPG with what
Oracle publishes on the VirtualBox site. Downloading the key once
works if I implement your previous key/keyring management solution.
Also, bear in mind, no software gets updated automatically on my
system. I get notified of updates but when the update happens is up
to me.
>> 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.
>
> If a major change is going to happen in GnuPG, it will be in the
> 2.1 branch (or in 2.3 once 2.2 is released). the older branches of
> GnuPG (1.4.x and 2.0.x) receive very few changes from upstream.
>
>> 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.
>
> You don't sign with a UID, you sign with a key.
>
>> The approach I took w
Re: fingerprint of key
On Mon 2017-08-14 22:12:18 -0300, Duane Whitty wrote: > 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 "--". I also prefer this kind of "subcommand" syntax -- it matches what tools like git and notmuch use. However, that's a pretty radical departure from the historical GnuPG command line, and it's likely to break all sorts of existing things that expect to use the canonical interface. If we're going to make radical departures like that, perhaps we should be specifying an entirely new interface that just does "the sensible bits" without all the rest of the arcana. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote:
> I perceive keys in my keyring as being ones I trust because of
> out-of-band confirmation and used for two-way communications.
You're not the only person with this perception. But i'm afraid i think
it's a mistake, unfortunately.
Actually safely curating an OpenPGP keyring with GnuPG is a non-trivial
task. As an example, here's a damned-if-you-do, damned-if-you-don't
conundrum:
Do you refresh the OpenPGP certificates in the keyring regularly
(e.g. from the keyservers)? if you do not, then you risk missing notice
of revocations, so you probably have some revoked keys in your keyring
which you didn't know you had.
If you do refresh them regularly, then it's possible that things (new
user IDs, etc) get added to the certificates in your keyring during the
refresh (or possibly whole new certificates get added entirely), and it
contains things you've never actually vetted.
So, how to resolve this?
The short version is that you should treat your GnuPG keyring as an
untrusted collection of OpenPGP certificates that you know about. But
you can explicitly mark the certificates that you think are legitimate
by certifying them ("signing the keys"). In particular, you can make
non-exportable ("local") signatures over the key+userid combinations
that you have actually confirmed out-of-band.
Even better, if you do that with a key which you have marked with
"ultimate" ownertrust, then GnuPG will report a "validity" for those
user IDs you've signed that matches what you intended to do, which is to
curate a list of known-valid key+userid combinations.
But treating the whole local keyring as a curated store is a mistake.
GnuPG doesn't work that way, and it doesn't expect to work that way :(
> 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.
If you fetch the key each time you download something that you want to
check against the key, how do you know it's the right key over time? If
it's "the right key" because it was fetched over a secure channel from
Oracle, why not just fetch the software over that channel?
The advantage of having a key stored locally is that you only have to
risk that network-fetch once; then you can make a local certification
over its sensible VirtualBox User ID, to mark it as the expected key (If
the User ID is *not* sensible, please complain to VirtualBox!). Then all
future updates can be verified against the same key.
Do you see how that's better than fetching the key each time?
> 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.
If a major change is going to happen in GnuPG, it will be in the 2.1
branch (or in 2.3 once 2.2 is released). the older branches of GnuPG
(1.4.x and 2.0.x) receive very few changes from upstream.
> 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.
You don't sign with a UID, you sign with a key.
> The approach I took was "gpg2 --search u...@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.
Again, i'm not sure what you mean by "sign from a UID". can you be more
clear? You're signing your friend's key+uid, from (or "with") your
primary key.
> 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.
Sounds reasonable to me, except that you had to use --recv-keys, rather
than just selecting the key to fetch from the --search interface.
here's a transcript of me fetching a key that appears to be yours from the
keyservers:
0 dkg@alice:~$ gpg --search du...@nofroth.com
gpg: data source: https://145.100.185.229:443
(1) Arlen Duane Whitty (Duane)
2048 bit RSA key E25FA6BF14571B64, created: 2016-06-09
Keys 1-1 of 1 for "du...@nofroth.com". Enter number(s), N)ext, or Q)uit > 1
gpg: key E25FA6BF14571B64: public key "Arlen Duane Whitty (Duane)
" imported
gpg: Total number processed: 1
gpg: imported: 1
0 dkg@alice:~$
Note that i just typed "1" at the prompt, and it pulled your key in
directly (no need for a subsequent --recv-keys invocation).
Regards,
--dkg
signature.asc
Description: PGP signature
Re: fingerprint of key
-BEGIN PGP SIGNED MESSAGE- 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 u...@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 "--". Best Regards, Duane - -- Duane Whitty du...@nofroth.com -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZkkpvAAoJEOJfpr8UVxtkpsIH/2qGLUDNqwNMvkN+ItQw4/YZ KBhnNxomzScrGzJXN9xZ1xH5Ha0FIGZgMzYxiAA/uWU4mgkurCDpESirTxffaTBp ahuSx6EYFre4JJdYzD/3zdVMws/fSacFZ18+ODbrfo40T1VSExHcO2yVGH5SDZg+ zxvPg0jM0QrFw276eSj3uwyn9nwBKXpGAtYcW/oE7plmDvimqob0AbuNQ7AvHwKS +Uw4+JkMRTU
Re: fingerprint of key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 u...@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 - -- Duane Whitty du...@nofroth.com -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZkkVBAAoJEOJfpr8UVxtkBDsH/0zoAMEuKvkkIzVC1r6v8kq9 Tmbqvd7i4Q8YobiExGilUXSx/s0psq4JKo1qcbvpuXnsRhJM+3/tH6TTgvdLJJOq Em8NN7HygzJ3Fhb7RaGZS9dBv2FQFem3qk+oFHzUMUlUGF1gF+agpeFM/CwKGsMk ClmBW9pSqQzH2z+hWXQPdAA8k8X2Wi3KH5BlrBT3kEKw+XdUJOqme8YPqWlo97XQ /BKmpPjiBiEE7qWkOXKTdD9ySIx/XO6fmcxvJEbvqygdjh/zp/Cm5jW2MrPoQC5N jWR18G8cRa5euNfXrzvyGm5o3SZTvoOEX3VHXPvQU8tyYVOV3sQVyM2hUWpyTfg= =ZuO1 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
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? > 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. 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17-08-14 05:58 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 13:25:58 -0300, Duane Whitty wrote: >> Thanks for your response. So, what you are saying is that the >> man page is wrong ;-) > > I didn't think that was what i was saying, but there have certainly > been bugs in the documentation in the past. Is there specific text > that you think is wrong? do you have a suggestion about what it > should be changed to? > > --dkg > The situation is a little more clear since your last response. If I may quote you: "the trouble with these two invocations of gpg is that they offer no command. Each invocation of GnuPG is supposed to include exactly one command and zero or more options. ..." I ran gpg2 --with-fingerprint oracle_vbox.asc which did what I wanted and I received no complaints. 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. When I looked at the man page for how to do this it looked like gpg2 - --fingerprint oracle_vbox.asc should do the job but as you have pointed out gpg expects a key in my keyring to perform that action on. After reading the man page several times for the 1.4 and 2.0 versions I can see nothing that would make me believe that I needed to provide the program with a key from my keyring. That's fine though, I'm still learning. Now that you point it out I can see that --with-fingerprint is an option under the section "Key related options" and so it makes sense that a command should be entered as well. I am not sure I understand why it would be bad to do the following, which implies not importing the key to a keyring: gpg --with-fingerprint --fingerprint < public-key-file.asc where I substituted --fingerprint for --import However if I do that it's the same as running: gpg2 --with-fingerprint --fingerprint and the oracle_vbox.asc file containing the key is completely ignored and there are no warnings that it was ignored. 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? By the way, I really appreciate the assistance you're giving me in helping me to understand this. I know your busy. Best Regards, Duane - -- Duane Whitty du...@nofroth.com -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZkh4hAAoJEOJfpr8UVxtkwj0H/0bPfVYbKMlbvLBsF+9pTFPW 9PwNRA47dARN8eBwtRr106br0iCLFxs31ObXyh80M+cGJFTIQN61y3FfD8GsEv9/ BS9xzjHv4q/sO+pF2yOy2ygmjoxouvbPIL86yobhJA+bKBw4piH9UxaPnQmO+SLC j450uLxl2C7ZWOcSI4bi0myHTnsZkvkbrPlYfo0zjbyJXIP+3DonRZhhVR2nzUwr DNX1K5TRy2Dw4NN430o0q9Bcef05XywExJFpCaxFWDOJdTgwVOkrfodDoaXKotjx M+nqD9sduQHXiCeXR1cN7aZ9rYCJ301xeFAiRJTOHl/sTUpoEdP2sj5i3Fog+pQ= =mBYf -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
On Mon 2017-08-14 13:25:58 -0300, Duane Whitty wrote: > Thanks for your response. So, what you are saying is that the man > page is wrong ;-) I didn't think that was what i was saying, but there have certainly been bugs in the documentation in the past. Is there specific text that you think is wrong? do you have a suggestion about what it should be changed to? --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
On Mon 2017-08-14 15:09:22 -0400, Todd Zullinger wrote: > $ gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary > pub 4096R/FDB19C98 2016-03-31 Fedora 25 Primary (25) > > Key fingerprint = C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 > > $ gpg2 --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary > pub rsa4096 2016-03-31 [SCE] > C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 > uid Fedora 25 Primary (25) the trouble with these two invocations of gpg is that they offer no command. Each invocation of GnuPG is supposed to include exactly one command and zero or more options. As the gpg(1) manpage says: gpg [--homedir dir] [--options file] [options] command [args] --with-fingerprint is a GnuPG option, not a command. When you give gpg no command, you're basically saying "hey, gpg, do whatever you think is reasonable." more recent versions of gpg will complain: gpg: WARNING: no command supplied. Trying to guess what you mean ... Please see https://dev.gnupg.org/T2943 for more discussion of this situation and why it is problematic. > Also, both 2.1.13 on fedora 25 and 2.1.22 on fedora rawhide, the > command above complains about the show-only option: > > $ gpg2 --version > gpg (GnuPG) 2.1.22 > > $ gpg2 --with-fingerprint --import-options show-only --import < > /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary > gpg: unknown option 'show-only' > gpg: invalid import options > > Is there a typo in that command or is show-only not in the latest > release of the 2.1 branch? the latest release of the 2.1 branch is 2.1.23. show-only was added in 2.1.23. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
Daniel Kahn Gillmor wrote: with more modern versions of gnupg, you can just use: gpg --with-fingerprint --import-options show-only --import < public-key-file.asc FWIW, I've used "gpg --with-fingerprint public-key-file.asc" for what seems like years to do this sort of quick fingerprint check of keys. It's particularly handy with linux distribution package signing keys, which are typically not something I have any need to import to my keyring. On a fedora-25 system: $ gpg --version gpg (GnuPG) 1.4.22 $ gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary pub 4096R/FDB19C98 2016-03-31 Fedora 25 Primary (25) Key fingerprint = C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 $ gpg2 --version gpg (GnuPG) 2.1.13 $ gpg2 --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary pub rsa4096 2016-03-31 [SCE] C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 uid Fedora 25 Primary (25) I haven't looked at the documentation for --with-fingerprint in a while, but it does seem like it's at least leaving out some details regarding its use on key files which are not imported. I have no idea whether those differences are intended and should simply be documented or it's considered a bug that --fingerprint and --with-fingerprint differ in handling unimported keys. Also, both 2.1.13 on fedora 25 and 2.1.22 on fedora rawhide, the command above complains about the show-only option: $ gpg2 --version gpg (GnuPG) 2.1.22 $ gpg2 --with-fingerprint --import-options show-only --import < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary gpg: unknown option 'show-only' gpg: invalid import options Is there a typo in that command or is show-only not in the latest release of the 2.1 branch? -- Todd ~~ The most overlooked advantage to owning a computer is that if they foul up, there's no law against whacking them around a little. -- Eric Porterfield signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17-08-14 12:14 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 03:32:08 -0300, Duane Whitty wrote: >> I was recently trying to compare the fingerprint of a key I >> downloaded to its online stated value. I thought I should be >> able to accomplish my goal with "gpg --fingerprint >> public-key-file.asc". Gpg returned "gpg: error reading key: No >> public key" > > "gpg --fingerprint" displays the fingerprint of a key that is > already in the user's keyring. > > you'll need to "gpg --import public-key-file.asc" first, and then > ask for its fingerprint, especially with older versions of gnupg. > > If you really want to isolate the imported key, you can use an > ephemeral GNUPGHOME directory, like so: > > export GNUPGHOME=$(mktemp -d) gpg --import < public-key-file.asc > gpg --fingerprint rm -rf $GNUPGHOME > > with more modern versions of gnupg, you can just use: > > gpg --with-fingerprint --import-options show-only --import < > public-key-file.asc > > hth, > > --dkg > Hi Daniel, Thanks for your response. So, what you are saying is that the man page is wrong ;-) Best Regards, Duane - -- Duane Whitty du...@nofroth.com -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZkc8RAAoJEOJfpr8UVxtk+5MIAKEtESbPZG+CHDr6hh+dkRaf OhlOQyNw9HuZzAhOXKQZKXukiwDSinlOQ+cJn4JbYtYUVZtDCQz/mu/WAkgtdN5U WM4FrZYxciDdJrZKzD4i+sc6MujKo2UEeTz4MqDO1DhKaD94fJ3EqRakPzmD6t7Y 1F6mvWDquz0Camr41NTrrkB3v6ISt7b/TA3H5v/XJCfZ9Wv5GHNKxzFeftmBEcQY lw/9geYKRahIFKGdMHVA2eQQteW4uq8wMgJSDUEOuxv/WyztWxvNeiwzZtjhAYl2 3J1j3pvL9XV7Q/Y+u/sjE941ieVSr3nbm7xy/VW5GLyWxWP3/dgjsh0CEaqGTjM= =TLc2 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: fingerprint of key
On Mon 2017-08-14 03:32:08 -0300, Duane Whitty wrote: > I was recently trying to compare the fingerprint of a key I downloaded > to its online stated value. I thought I should be able to accomplish > my goal with "gpg --fingerprint public-key-file.asc". Gpg returned > "gpg: error reading key: No public key" "gpg --fingerprint" displays the fingerprint of a key that is already in the user's keyring. you'll need to "gpg --import public-key-file.asc" first, and then ask for its fingerprint, especially with older versions of gnupg. If you really want to isolate the imported key, you can use an ephemeral GNUPGHOME directory, like so: export GNUPGHOME=$(mktemp -d) gpg --import < public-key-file.asc gpg --fingerprint rm -rf $GNUPGHOME with more modern versions of gnupg, you can just use: gpg --with-fingerprint --import-options show-only --import < public-key-file.asc hth, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
