Should Fedora rpms be signed?

[Jeff Spaleta]

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
look at gnupg. rpm can't import keys that are signed by other keys.
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.


-jef