Re: fingerprint of key

2017-08-17 Thread Daniel Kahn Gillmor
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

2017-08-17 Thread Daniel Kahn Gillmor
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

2017-08-17 Thread Duane Whitty
-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

2017-08-17 Thread Duane Whitty
-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

2017-08-17 Thread Daniel Kahn Gillmor
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

2017-08-17 Thread Daniel Kahn Gillmor
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

2017-08-14 Thread Duane Whitty
-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

2017-08-14 Thread Duane Whitty
-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

2017-08-14 Thread Daniel Kahn Gillmor
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

2017-08-14 Thread Duane Whitty
-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

2017-08-14 Thread Daniel Kahn Gillmor
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

2017-08-14 Thread Daniel Kahn Gillmor
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

2017-08-14 Thread Todd Zullinger

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

2017-08-14 Thread Duane Whitty
-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

2017-08-14 Thread Daniel Kahn Gillmor
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