Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi,
On Mon, Jun 23, 2008 at 11:20:33AM +0200, Goswin von Brederlow wrote:
> The beauty of signatures is that you do not have to trust the source
> of the key, only the signatures. It truely doesn't matter wher you get
> the key from.
yes, you are right (given that you mean signatures on the key from
"third parties", e.g. someone I trust).
> As for the signature there is no difference between trusting apts key
> to safeguard the Release file or a new key. So normal key updates will
> not change its trust level with this.
Thats true, as long as the key does have signatures from people I trust
or I'm willing to trust without knowing it well.
> Further, on first install, you probably will have to trust a signature
> from the debian keyring for closely debian related repositories. I'm
> assuming there will always be some maintainers there to sign the
> archive key. But every debian user has the debian keyring from a
> trusted source. While you might not be integrated into that web of
> trust you already do have to trust it. Those keys do sign every
> package upload after all.
Exactly. I know that I must trust a key that I cannot verify now. For
example the Debian keyring. Obvious I can only see if it was signed by
some people, but as I probably don't have any of these signatures in my
trusted keyring I cannot me sure that this isn't a compromised
signature. In this case I (as any other user) give a trust bonus. Thats
okay as long as I don't have to give a trust bonus to other external
repositories, like backports.org, without at least a signature from
someone whose signature I partly trust.
But as far as I understand your proposal you do have this, so everything
is right. Good idea, needing a reference implementation.
> Overall having the key on the archive server looses you nothing but
> gains you flexibility and transparency. Now if only someone would
> write a proof-of-concept implementation...
Yep it losses me nothing if it is signed by a third party (that I know
or at least is reasonable trusted). Right. If it isn't then not.
> > I now understood. Its an interesting idea, I just think that some factors
> > need to be worked out, because there should be a chance for the *average*
> > user to understand if a key could possibly be trusted or not. (Not every user
> > understands those web of trust thing and this is something that can't
> > really be asked for).
>
> I think you are wrong there. I think it is something that must be
> asked. You can't have security without understanding. Just think how
> many users blindly accept ssl ceritificates and then think https is
> save because it is encrypted. It is just a false sense of security.
Although it might have sounded so, but it isn't what I tried to say.
What I meant is that security has to be as easy as possible for them.
Because you have to consider the reason *why* they click "ok" if they
see SSL warnings. It is because they are overwhelmed with the
decision. Because its to complex for them to understand. You can't ask
them to understand everything you understand. Some people are not able
to understand that, but they have a right on security, as well.
Regards,
Patrick
Reply to: