[Catalog-sig] How to verify cheeseshop signatures?

Phillip J. Eby pje at telecommunity.com
Sun Oct 23 18:47:44 CEST 2005


At 12:28 PM 10/23/2005 -0400, Jp Calderone wrote:
>On Sun, 23 Oct 2005 12:02:17 -0400, "Phillip J. Eby" 
><pje at telecommunity.com> wrote:
>>
>>>Jp Calderone wrote:
>>> > The required key is indicated in the message.  You just need to 
>>> retrieve it:
>>> >
>>> > gpg --import 41C6E930
>>> >
>>> > Re-running --verify should now work.
>>
>>It doesn't.  I get "gpg: can't open `41C6E930': No such file or directory".
>
>You may not have gnupg configured with any key servers.  I am currently 
>using hkp://subkeys.pgp.net, if that's any help.

This worked:

$ gpg --keyserver hkp://subkeys.pgp.net --recv-keys 41C6E930
gpg: requesting key 41C6E930 from hkp server subkeys.pgp.net
gpg: key 41C6E930: public key "Richard Jones <richard at commonground.com.au>" 
imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

$ gpg --verify roundup-0.9.0b1.tar.gz.asc roundup-0.9.0b1.tar.gz
gpg: Signature made Fri Oct  7 01:39:29 2005 EDT using DSA key ID 41C6E930
gpg: Good signature from "Richard Jones <richard at commonground.com.au>"
gpg:                 aka "Richard Jones <richard at mechanicalcat.net>"
gpg:                 aka "Richard Jones <richardjones at optushome.com.au>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 0145 FD2B 52E8 0A8E 329A  16C7 AC68 AC04 41C6 E930


>>At 01:54 PM 10/23/2005 +0200, Martin v. Löwis wrote:
>>>Partially, yes: it will verify that the signature was made by the public
>>>key with that key ID. That doesn't mean you know for sure that the
>>>person you assume to be behind the key really is the "owner" of the key.
>>>
>>>For that, you would actually have to validate the public key, e.g. by
>>>looking at the signatures on the public key, and checking whether you
>>>recognize them, and whether you believe they would only sign keys for
>>>people they have verified in person.
>>>
>>>This is nothing cheeseshop could help with: the web of trust really is
>>>between people, not between technology.
>>
>>So, from a practical perspective, the current signature implementation is 
>>of no use whatsoever to the vast majority of cheeseshop users.
>
>Well... It's PGP :)  It's as useful or useless to cheeseshop users as it 
>is to anyone else.  For anyone with a large web of trust, the likelihood 
>of there being a trust relationship with the package signer is 
>greater.  For people with a small web of trust (or no web of trust at 
>all), it's smaller.
>
>Perhaps this means it is practically useless (FWIW I think I agree, I 
>doubt I have a trust relationship with a single package owner)

If you have to meet individual authors to validate them, you could just get 
the package from them in person and skip all the certificate crap.  :)


>>It seems like it would make more sense to use a format that includes a 
>>certificate signature chain (as with Ruby Gems).  Having to manually 
>>track the keys of individual authors sort of goes against the whole point.
>
>Using a chain-based system helps spread trust relationships faster.  It 
>also means someone has to manage a certificate authority (set up the 
>certificates in the first place, manage the security of the CA cert, 
>accept and somehow process signature requests).  The attacks it is 
>vulnerable to are also more severe in their consequences: if you 
>compromise my PGP private key, you can pretend to be me to anyone in the 
>world; if you compromise a certificate authority certificate, you can 
>pretend to be anyone in the world to anyone in the world.  PGP keys are 
>also more easily revokable.
>
>Not advocating either position, just explicitly spelling out some of the 
>differences.

Well, the flip side is having no real security at all, if you just decide 
to trust each author individually.  In effect, the whole thing becomes just 
a "warm fuzzy" pseudosecurity, not unlike airline screening procedures.

The sucky bit is that my choices are now to work hard to integrate this 
with EasyInstall, and then have crypto experts complain that by making it 
actually work for people I've nullified the real security (which will be 
true, of course), or in the alternative I can just not support it, in which 
case people will gripe that it doesn't verify signatures.  *sigh*



More information about the Catalog-sig mailing list