On Thu, 2004-11-04 at 15:02 -0600, Satish Balay wrote:
> On Thu, 4 Nov 2004, Peter Jones wrote:
>
> > Signing something with the Red Hat key and signing something with the
> > Rawhide key are currently _the same thing_, and no amount of telling
> > people that it's not is going to change that.
>
> (I didn't want to get sucked into this again - but couldn't
> resist.. this tread never dies).
>
> I hope you can give pointed answers to these 2 questions.
>
> 1. If 'Red Hat key' == 'Rawhide key' - why do you have both?
I think it's horribly ill-conceived that we have both. That is, we have
both because people have fallen into this mistake.
> 2. How does packages signed by 'at-rpms-key' fit in your grad model
> where all keys are the same - and users don't know how to distinguish
> them.
Both models have the keys being the same. One has people refusing to
acknowledge this.
The current model is that they're all the same. Look at our tools; look
at yum and up2date. They don't know anything about which key is which,
just which key you've said you trust (not even what you trust it for, or
how much). The only real difference, and certainly the only one in the
minds of the vast majority of our users, is that one comes in rpm's key
list by default and one does not.
The better question is how one of Axel's package fits into the model
Nils insists exists. The only possible answer is that it doesn't fit
very well at all. How do I know what Axel means by his signature on his
packages? I have no idea, and I don't know where to look to found out,
either. I suppose I could email him, but that certainly doesn't scale
to a 4th or 5th key very reasonably, much less any more than that.
My model is that the signature is more than just a gpg signature.
Conceptually, it's a signature on a certificate with data that specifies
exactly which ways the package may be trusted. One could actually
implement it that way, which I think we should, but it's some
significant effort.
The specific proposal here was that when you *don't* mean the things
that people infer from a signed package, don't sign the package. If all
we mean is that it's not damaged or tampered with, sign the metadata
instead. Seth's metadata proposal (which I believe he's largely
implemented) already has the format for this in place. In this case the
package is one certificate as mentioned above, and the metadata is
another. What the package signature actually means is obviously up for
some debate, but we can certainly find plenty of examples where people
think it means more than just lack of corruption.
> Or should no one other than 'Redhat' be signing packages.
With a model where we recognize the meaning from the key, this is
implied, though not necessarily intentionally. With my model, it is
not.
--
Peter
When privacy is outlawed only outlaws will have privacy.
-- Zimmermann