[Top][All Lists]

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

Re: [Gnu-arch-users] Re: Common merge request format

From: Robin Green
Subject: Re: [Gnu-arch-users] Re: Common merge request format
Date: Mon, 12 Apr 2004 21:18:59 +0100
User-agent: Mutt/1.5.4i

On Mon, Apr 12, 2004 at 02:24:13PM -0400, Michael Poole wrote:
> > What a rigmarole! Let's just insert headers pointing to a direct download 
> > for
> > our keys. Much simpler!
> Slightly simpler and much less useful. With a keyserver, you can
> store a web of trust in one place.  With URLS to exported keys, you
> cannot.

Point taken. I should have realised that.

So how about this instead:

# A keyserver that supports hkp where the sender's key can be found
OpenPgpKeyID:     B524B126

The thing I notice with keyservers though, is they tend to get overloaded
quite often, so perhaps keeping the existing Gnupg-key: line as a web
backup would be a good thing?

Lastly, I'm a bit confused by the whole trust thing. If it is important to
get as much trust information as possible, why doesn't the gpg documentation
recommend asking multiple keyservers for trust info to make sure you receive
the maximum number of signatures? Why doesn't it recommend regularly going
back to the keyserver to see what new trust information has been added, if

It's an odd thing because if you are already assuming that the person is
who they say they are, then certainly for gnu arch purposes at least it
seems that keyserver keys give you no new information, because they merely
confirm your beliefs if they are signed, and fail to disconfirm your beliefs
at all if they happen to be unsigned. Ironically, this seems to imply
that trust information is in effect useless in this context. In a coding
context I think trust is gained through submitting lots of good code -
not through having a key with a strong signature path between the submitter
and the recipient.

Attachment: pgp0IxiR04XtF.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]