On Mon, 2004-11-01 at 12:27 -0500, Peter Jones wrote:
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.
Technically it does only what I said, i.e. the package was signed by
someone who basically only signs "this package passed through me", as no
additional validation or QA or whatever is involved in the signing step.
But see below.
> 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.
You're talking about FC final or RHEL final keys/signing, not the
Rawhide key.
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.
That is the most I would grant a signature with the Rawhide key on a
package to convey.
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.
OK, we're getting somewhere. We do have several keys with which to sign
packages. We do specifically have a Rawhide key which kind of
invalidates what you said in an earlier post:
No, nobody is "proposing that Rawhide packages shouldn't be
signed at
all". That's pure spin. They are not currently signed, and I'm
arguing against the proposal that they *should* be.
Indeed they are currently signed -- with the exception of a handful of
packages. I say that we should close this gap.
> > 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.
Your argumentation implies that all package signing keys convey the same
message, i.e. "this package was built there and there and fulfils
certain quality criteria" which is certainly not true for the Rawhide
key. Rawhide packages explicitly do not fulfil any criteria, in fact
Rawhide packages have been announced as:
[...]
Raw Hide Can Be a Bit Tough to Chew on So Run at Your Own Risk (and
Enjoyment)
These releases have not been quality tested by Red Hat's Quality
Assurance team. They may not boot. If they boot, they may not install.
If they install, they may not do anything other then waste CPU cycles.
If anything breaks, you most assuredly own the many fragments which will
be littered across your floor.
[...]
The Rawhide key did not ever tell me more than that this package has
been built in the Red Hat build system. This surely is different from
what any other RPM signing keys may or may not mean, but it is enough
for the purposes for those people who want to test the new stuff but
still want to be at least a bit safe that the software they try won't
intentionally screw them. Beta/Testing keys might imply a bit more of
quality while final keys give me the most in that department. Not every
key is the same here ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011