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@xxxxxxxxxx
"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