Should Fedora rpms be signed?

[Peter Jones]

On Mon, 2004-11-01 at 15:24 -0600, Satish Balay wrote:

> Ok - I had to respond to this. 
> 
> The correct thing to do is to document the above text for EACH gpg-key
> redhat uses. Saying the text is the SAME for ALL keys (hence can't
> sign rawhide) is wrong.
> 
> And you haven't specified what the gpg-singer does (the process he
> uses) to provide the above checks before signing.

No, that's still a recipe for total failure.  The data has to exist
outside of the key.  All the key does is sign something.  That's all.
Nothing more.  Otherwise I have to know where (and how) to look up which
keys mean what.  This is annoying for Fedora's (and Red Hat's) keys, but
for a 3rd party repo, like freshrpms or even Fedora Legacy, it's a non-
starter.

> > I further stipulate that unless there is actually some observable,
> > immutable data to signify that a signature means only that the source
> > has been verified, many users will assume that any signature represents
> > _all_ of these things, and they are justified in this assumption.
> 
> There will always be wrong assumption. The fix is documentation.

No, the fix the software to not require users to make assumptions.
Especially not assumptions we've taught them to make.  Documentation
rots just like code does, if not quicker.  If the cert (not the key, not
the signature, but some data being signed!) says "this means only that
the package is the one we said it was", people don't need to make an
assumption to get to "this doesn't mean this is supported by Red Hat".
It clearly doesn't say that.

> > The problem that people are hoping to address is inconvenience of
> > testing rawhide packages because they are not signed.  Right now,
> > package update tools have no option but to check both if the package
> > data is correct and if the package is the one intended to be in the
> > repo.
> > 
> > Update tool authors resist making signature checking configurable on a
> > per-repo basis, which would alleviate the strain but reduce the overall
> > utility of the tools.  
> 
> yum has an option to do independent 'gpg-checks' on each repository. So this
> is not the problem.

You'll have to check with Seth, but I believe he's even come up with
this same proposal -- no checks on the package, but a signature on the
repo metadata that gives package filename and a cryptographic hash,
which would be checked.  He's also not the only person who's written an
update tool in widespread use.

> > At the same time, users of rawhide and update
> > tools really only care that the package is from the repo, not anything
> > else.  So the best answer, IMO, is to make it so that you can say "this
> > is the right package" without all of the other implications, and then to
> > change the update tools so that you *can* say "for this repo, I only
> > care that the package is really from the repo".  We don't need to check
> > our traditional "package signature" per se; we need to check only that
> 
> Now you are coming up with a complex system just to justfy using
> multiple gpg-keys with the exact same meaning.

It's not very complex at all.  It's checking one signature on one file,
per repo.  And it _is_ what people are asking for -- to paraphrase the
bazillion emails asking for it, "please don't make me click a button
just because the package is not from a released product".

-- 
        Peter