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. These things
are Red Hat's and Fedora's value add, and a signature says that we
believe we've actually added value.
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". 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
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, 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, 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.
--
Peter
"Obviously, a major malfunction has occurred."
-- Steve Nesbitt, voice of Mission Control, January 28,
1986, as the shuttle Challenger exploded within view
of the grandstands.