Should Fedora rpms be signed?

[Peter Jones]

On Mon, 2004-11-01 at 12:24 -0600, Satish Balay wrote:
>
> Are you saying - currently when a package is gpg-signed by a person -
> he/she actually goes through a manual process of verifying the
> following?
> 
> - source is not tampered (including the intial .tar.gz, patches, .spec files)
> - binary is not tampered
> - source -> binary process didn't introduce 'ANY' tampering?

I'm saying that when we release signed packages as Fedora or as Red Hat,
we are acknowledging that we intend for all of these to be the case, and
that we believe they are.  That is to say that when we distribute a
signed package it generally holds true, and is assumed to be true, that:

- we've not included malicious code from the upstream
- we don't think there are negative legal ramifications of
  us distributing that package in the distro
- the source has not been maliciously tampered while retrieving
  it from the upstream source
- the packaging itself is reasonable and will not harm your system
  when used appropriately
- the process of compiling it did not introduce harmful changes
  which should have or could have been known ahead of time (that is,
  that the build environment can be trusted not to introduce problems)
- for Fedora Core packages, the packages are free software
- the packages are really from us (the signer)

This is at least the case when we release a distro, a release candidate,
or a test release in which the packages are signed.  And in the very
minor variations where one of these points isn't the case, the
perception is still that they all are.  That's what's important here,
not the intent.  If the intent isn't perfectly clear when looking at the
data and the tools, then it doesn't make any difference to our users.

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.

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.  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
the package is the intended one.

> If not - I don't see any big change - as far as user perception goes
> on gpg-sigining on build system.
> 
> For us users there is no confusion:
> - 'rawhide-key' is different from 'redhat-key' - so there is no confusion here.

Make this work in a world where users draw from multiple, unrelated
repositories.  Some people (not very many) know that rawhide-key means
it isn't for a production release.  But Joe Foo's repositories have
packages signed with joefookey1 and joefookey2.  Which is which?

This is not viable.

> - 'gpg' singed packages doesn't => stability (aka rawhide can always
>   eat data) - so no confusion here..

The signature *sometimes* does imply that.  If the only difference is
the key, then there's really not any way to tell when.

-- 
        Peter

"Obviously, a major malfunction has occurred."
                -- Steve Nesbitt, voice of Mission Control, January 28,
                   1986, as the shuttle Challenger exploded within view
                   of the grandstands.