Le lundi 01 novembre 2004 à 12:27 -0500, Peter Jones a écrit :
On Fri, 2004-10-29 at 12:57 +0200, Nils Philippsen wrote:
> > The question is still one of gains versus losses. I personally think we
> > gain more by _not_ signing them. If we automatically sign them, we make
> > it more convenient for people who don't want to use --nosig or whatnot
> > on rawhide packages.
>
> If we don't sign packages we make it basically impossible for people to
> check where a specific package comes from.
Yes, but the current signing method does not do _precisely_ that. It
does many things, and that is one affect.
> There is nothing else that a signature on a package says.
That's simply not true.
It says that we intended to release it in a form that is fit to be used.
(Although clearly it does not imply any warranty, including the implied
warranties of merchantability and fitness for a particular purpose ;)
It says we believe that the actual data in the package headers -- the
scriptlets, the triggers, the conflicts, the provides, etc. -- are of a
quality that Fedora believes is sufficient for release.
An announcement (or linux/core/3 in
download.fedora.redhat.com ...) tell
me that there is a new release which is quality approved by the Fedora
team. Not the signature of the package.
A signature only say me where the package come from.
These things
are Red Hat's and Fedora's value add, and a signature says that we
believe we've actually added value.
Where have you read this ?
Do you have any URL ?
If I remember correctly, FC2 (with all packages signed) "burn" some mbr.
What is the meaning of signed package in this case ?
A signature, which can be part of a quality process, ensure where the
information/data/package come from. A signature is not a certificate of
quality _without_ a quality process.
It also conveys that some packager whom we trust has looked over the
payload and does not consider its contents to be *hostile* to our users.
Consider RHEL errata. When RH releases an erratum, the signature
doesn't just say "this is some package from Red Hat".
The signature only say that.
It says that you
can use the signature, combined with the checksums and the data in the
erratum. For what can they be used? You should already know the answer
here. What the signature provides is a way to verify Red Hat's intent
and belief that the package in the user's hands does actually fix the
problems described in the erratum, and to some (lesser) extent that it
does not introduce more problems
You are mixing quality process and signing. sure, a signature can be
tighten to a quality process. But a signature "alone" is not a
certificate of quality.
If Red Hat sign rawhide package with a key that is not tighten to a
quality process, the signature only tell where the package come from.
So, no, it's not just that it comes from Red Hat. That's
really a more
minor point of what it's for.
> > That's not a win. In fact, it's a big loss. If the packages are
> > automatically signed during the build process, the only thing the
> > signature means is "it showed up in the queue of things to be
signed".
> > But if you see a signed package, the impression you get is that it is in
> > some way "trusted". Of course, it isn't trusted. It's just
got a
> > signature that says "don't make the user type --nosig".
>
> That's a misinterpretation of the signature on the package. We shouldn't
> sign or not sign packages based on how people could misconceive what
> such a signature means. We should sign packages so people can verify
> that these packages are actually from us and haven't been tampered with
> in the meantime.
We always have used signing to mean more than just this,
That's almost right. This does not imply that all signature have the
same meaning of the key "<security(a)redhat.com>".
and the other
things are equally important, if not more so, to us. We can't mean just
that the transport is ok without giving the rest up. We cannot have it
mean one thing sometimes, and more things some other times,
Why not ?
Here the mean of the rawhide key :
https://www.redhat.com/security/team/key/
Rawhide Package Signing
From time to time Red Hat make development software available,
usually as part of Rawhide. These packages may be signed by an
automated build signing key. Because this key is used
automatically we expect to change the key we sign with from time
to time.
There is not any guaranty.
unless the
signatures have actual data about what they represent *built in*. Who
is signing it is not enough, and that's currently all we have. If the
only way to tell the difference in what the signatures mean is the key
of the signer, then most people who *do* care will never know what any
signature means.
So yes, we both agree that we "should sign packages" (or some data that
can be securely matched with it, like the metadata) "so people can
verify that these packages are actually from us and haven't been
tampered with in the meantime." What we don't agree on is the fact that
this is very much NOT what we currently do with signatures.
I remember that all package in rawhide are signed during RH8.0 and RH9
beta.
Does it cause any damage to Red Hat or to the meaning of
"<security(a)redhat.com>" ?
No.
As long that where is no page that state why/when a key is used, we can
give any meaning to a key.