Should Fedora rpms be signed?

[Nils Philippsen]

On Fri, 2004-10-29 at 12:00 -0400, Jeff Spaleta wrote:
> On Fri, 29 Oct 2004 17:34:48 +0200, Nils Philippsen <nphilipp at redhat.com> wrote:
> > - Signing a repository is not the same as signing individual packages.
> > With the first you need to trust two "layers", i.e. you trust that the
> > repo is from Red Hat because its metadata is signed with our key and you
> > trust the package isn't compromised because its MD5 sum matches the one
> > in the list. There is a reason why my trust in GPG keys is reduced the
> > further a specific key is away from me, e.g. if I trust you because we
> > both were at a key signing party and signed out respective keys, I will
> > trust the keys you signed elsewhere less than yours because there is
> 
> This is the problem right here.... rpm has no native concept of signed
> keys... last i checked you cant rpm --import signed keys. You cant
> look at rpm's current implementation of signing in the same way you

Huh? I know no other way than looking at the source code of both, so I
guess you've lost me / I misunderstood you.

> look at gnupg. rpm can't import keys that are signed by other keys.

RPM maybe can't check the trust of these keys, but it definitely can
import signed keys (I just did it with my own which is signed by several
people).

> Its a very significant difference... rpm's keyring has no web of trust
> metric that can be used in this way...as of now.  This impacts the
> perception of what 'trust' in signing means.  If there was a trust
> metric that rpm and rpm based tools could natively take advantage of,
> in which a rawhide signing key could be endowed with far less "trust"
> than the full release key, I wouldn't be making the arguments that I'm
> making. But as it stands the lack of a trust metric for rpm beyond 'is
> it signed by a key at all or not'... impacts the perception of trust.
> And I don't want to elevate the perception of trust in the automated
> rawhide key to that equal of a release key in this black and white, on
> or off signing implementation that rpm currently has. Once rpm can
> deal with signed keys, and rpm tools can generate and use a trust
> metric natively from the rpm keyring... things are different, there
> will be an inherent way to assign shades of grey and the tools can
> inform the uninformed about where a key lives in the trust metric.

I think that we don't really need shades of grey for these keys if we
use them as just a measure for verifying the origin of a package -- this
was the intent of signed packages in the first place. Because you either
install a package or you don't, I would say that shades of grey and a
certain "threshold" that packages have to "hop over" in order to be
installed are actually not helpful -- I wouldn't want such a
complicated, not easily deterministic (because not all variables can be
known by the user) algorithm to automatically decide whether a package
should be installed or not.

IMO the "quality" of a package is another property of an RPM package
that just isn't defined for today's packages (and for today's RPM). If
we would want to introduce such a property I say it'd make sense to have
this property separately signed with a GPG key, in the sense that today
we more or less sign the "build host" and/or "vendor" property as in "I
(the undersigned) certify that package <foo> originates at <bar>". No
question that contrary to the build host one should be able to change
the quality level of a package afterwards (while requiring resigning of
course). Maybe you could even make that cumulative, i.e. that we could
have separate levels of quality each signed by one or more parties, this
way users could define that they trust these or those parties more or
less and in that case a trust metric a'la GnuPG that defines the
effective quality level could be devised. Whether this quality level
would be applied (and signed) on a package or repo level would need to
be discussed, though I'm actually in favour of leaving this at a repo
level because talking about quality when looking at an isolated package
doesn't make much sense.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"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