[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Apt-get package verification

On Sat, Feb 10, 2001 at 07:54:49PM +0100, Carel Fellinger wrote:
> [-- PGP output follows (current time: Sat Feb 10 19:40:06 2001) --]
> gpg: Signature made Sat 10 Feb 2001 06:11:01 PM CET using DSA key ID EBF15399
> gpg: Good signature from "Marco Ghidinelli <marcogh@atdot.org>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.
> gpg: Fingerprint: 1C34 97F7 1837 D525 7E3F  C883 B572 DF1A EBF1 5399
> [-- End of PGP output --]
> But I'm quit willing to trust debian developers in general.  I trust them
> with the packages, might as well trust their identity:)  I'm a bit uncertain
> how to achieve this though.  Is it enough if I tell gpg to trust James Troup?

You don't need to assign any trust to these keys; it's enough to get the
"Good signature..." output.  As long as the signature verifies
successfully (as it does in your example above), you know that the
person who created the key you've got on your keyring is the same person
who sent the message/signed the package/whatever.

The issue of trusting the key is a separate one: it answers the
question, "was this key created by the person whose name appears in the
key?"  If you can unconditionally answer Yes to this question then go
ahead and sign the key.  Otherwise you do not REALLY know that that key
was created by that person.

For instance, when I see security advisories sent by Wichert Akkerman, I
verify the signature using his public key which is on my keyring.  As
long as it says "Good signature" then I can be certain that it was
signed by whoever created the public key I've got.  But, unless I have
actually met him in person or spoken to him, etc. or otherwise verified
WITHOUT ANY DOUBT that he created that key, I should not assign trust to
that key.

None of this is any different from how you should handle anyone else's
keys, this is all standard procedure.

Reply to: