On Thu, 2004-11-04 at 11:08 +0100, Nils Philippsen wrote:
> On Mon, 2004-11-01 at 12:27 -0500, Peter Jones wrote:
> > On Fri, 2004-10-29 at 12:57 +0200, Nils Philippsen wrote:
> > > 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.
I really don't care about "Technically it does this" arguments; I care
about what most of our users understand it to do.
> > > 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.
I'm talking about how most of our users perceive *any* signature, and
about how our tools, and tools made by our users, treat signatures of
any kind.
If I can't tell the difference in how things should behave by simply
looking at the data that's *there*, then there is no difference. What I
know because I've learned it on company mailing lists or through talking
to people, even if it is part of the corpus of knowledge which we as
developers may have, is simply not real for the majority of our users.
It is not reality for them, and it is not the reality our current tools
are based on.
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. There has to actually be
data that says it's different, and the tools have to actually look at
that data.
> > 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.
But that doesn't scale past *one* key. This is not 1998, and Red Hat is
not the only supplier of packages that run on a Fedora box. The method
for telling "this signature means *this thing*" cannot be "look at the
signature, and then look the key up in a table in the code".
The right way is a method where we look at the signature, and it has
data which includes the key, and the purpose of the signature. It also
should be something usable on private networks, so having something like
an rss feed to say which key is which also pretty much sucks.
I have to be able to use a key for *exactly* one thing, and that one
thing is how much I trust the signature. Everything else needs its data
to be part of the data which is being signed.
> > 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.
Even if you do sign every package, changing update tools to accept that
signature still erodes the utility of signing things by a significant
amount, unless the signatures can say for themselves what their purpose
is. In fact, signing them the way we do erodes it some, but changing
the tools is far worse -- it's an acknowledgment that we mean to do
this.
Also note that those which are signed are currently signed by hand, and
one thing people have been advocating is automatic signing. Automatic
signing, I'll obviously argue, is a total loss. But more than that, we
don't want to convey.
> 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.
It's true to our tools, and I think it's true in the eyes of our users.
I'm not the only one who's stated this impression, either. Jef put it
pretty well the other day talking to Satish:
> On Mon, 1 Nov 2004 12:58:22 -0600 (CST), Satish Balay
> <balay@xxxxxxxxxxx> wrote:
> > No confusion here either - as rawhide packages are never mistaken
> > for erratum packages.
>
> really? noone ever mistakes a package from rawhide as a consumable
> package?
> really? no one ever does a random search for a package from an online
> rpm warehouse and finds a package meant as a piece of rawhide and not
> as a consumable update?
> really? no one ever takes packages from the rawhide tree and mixes
> them with updates and creates a homebrew repository that other users
> will be using?
There is no part of which key was being used that carries any data about
what the signature means, and this is a very significant problem. Why
isn't this point clear?
> 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 ;-).
Again, you're ignoring the difference between intent and perception. We
certainly haven't intended for the rawhide keys to say that, but at the
same time, all of our tools currently have two classes of keys for
signatures: known and unknown. They don't have "known to only mean it's
from the right place", which is what you contend the rawhide key is.
"If you're on the list, you get into the club," as it were.
And even if they *did* have that concept, there's still no good way to
make that scale to more than one source of packages.
A different key does not a different kind of signature make. Really.
--
Peter