Should Fedora rpms be signed?

[Peter Jones]

On Fri, 2004-10-29 at 20:15 +0200, Nils Philippsen wrote:
> On Fri, 2004-10-29 at 14:06 -0400, Paul Iadonisi wrote:
> > On Fri, 2004-10-29 at 19:37 +0200, Nils Philippsen wrote:
> > > On Fri, 2004-10-29 at 11:06 -0600, Rodolfo J. Paiz wrote:
> > 
> > [snip]
> > 
> > > > I see no downside. Since you do, can you provide more detail on what and
> > > > why?
> > > 
> > > I see no downside in repo metadata signing either, it's a good thing
> > > actually. But it is not an argument on why packages shouldn't be signed
> > > individually.
> > 
> >   Um...did I miss something?  I didn't see anyone suggest *replacing*
> > package signing with repo metadata signing.  It's just an added measure
> > to help ensure that what is on the mirrors is what is on the official
> > Red Hat repo.  Granted, you still need yum or up2date to use that
> > information, but it's still a net gain.  In particular for when some
> > packages don't get signed, which seems to be what this thread is about
> > (today, anyhow ;-)).
> >   At least, I sure *hope* no one was suggesting foregoing package
> > signing.  Cuz that would be bad. :-)
> 
> Umm yeah. Some people were proposing that Rawhide packages should not be
> signed at all. I myself think this is a bad idea and that all packages,
> regardless of their quality, should be signed. Hey even more so with bad
> packages I want to know who's responsible ;-).

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.

I'm not arguing against the idea that it should be possible to strongly
verify the source of the packages.  I am arguing against the desire to
use the same mechanism as we use for saying that we think a package is
safe, either from innocent corruption or intentional tampering at any
part of the packaging process.

A signature on a package announces a degree of trust that somebody has
on the payload of that package, and that the headers belong with that
payload.  That's not what is being asked for when people ask for rawhide
packages to be signed.  What is being requested is a method to verify
that the package is truly from a known source.  That, and that alone, is
what is request at hand.

While our current signing method does guarantee the source of the
package, that is not all it guarantees.  Fedora and Red Hat (and
arguably Seth ;) are in a unique position regarding policy around RPM,
and because of this we must be very careful.  If, for any repository, we
use our current signature method to signify *only* that the repository
is the source of the package, then we necessarily give up all other
meanings of it for all other repositories.

All of that being said, this is not an insurmountable problem.  In fact,
there are fairly straightforward methods to gain this verification,
although they are not necessarily trivial by any stretch of the
imagination.

But first, we have to be clear about what we've got right now, because
it's not completely obvious.  Usually we see a package as:

1) payload
2) headers, which contain checksums on header and payload data
3) a signature on #2.

But a better way of considering these parts is this:

1) payload
2) headers, which includes checksums on header and payload data
3) a certificate, which is completely implied, derived from
   the checksum data in the headers, and the header entries
   specifying the source of the package.
4) a signature on #3.

Right now, that certificate conveys both trust that the checksums are
correct, and trust on the source of the package.  The important part of
these meanings are in the eye of the beholder.  We cannot say that a
signature means only one thing without permanently giving up the other.

So what we need if we want to imply only the source is another signed
certificate.  This can either be in the package, as our current rather
ethereal certificate is, or it can be separate.  It still has to include
some way to verify which package you're talking about, and it still
needs to have a signature.

The easy way to get this is to generate a metadata file when we push
rawhide out, and to give it a certificate with a signature.

There is still some complication, though, which is that package fetching
utilities such as yum and up2date would need to be taught to only check
that the source is correct in situations where that's all they care
about.
-- 
        Peter

"Don't everyone thank me at once!"
                -- Solo