Should Fedora rpms be signed?

Jeff Spaleta jspaleta at
Thu Oct 28 19:01:16 UTC 2004

On Thu, 28 Oct 2004 19:38:02 +0200, Matias Féliciano
<feliciano.matias at> wrote:
> ????
> "createrepo --addsign ...." is better than "rpm --addsign *.rpm" ?
> Why ?
> > Then there's no misplaced trust on the package, as you'd get by signing
> > it, but there is verification that it is the right package.
> ???? You mean I should not trust the right package ?

Rawhide there very nature shouldn't be trusted. Rawhide
packages may in no unspecified order:
eat your children
pollute your network
eat your children
destroy your data
eat your chidren

The problem here is interpretation of what signing a package is meant
to mean. You really really really want it to be used for something
new, to imply a level of trust intermediate of what its beeen
traditionally used for and no signing at all. The LOSS, in this case,
is confusion as to what it means when a package is signed. You may
comprehend that a rawhide key used in this manner means something
different that a full release package signed with the full release
key..but i garuntee you the majority of the userbase will NOT
understand the difference and will understand that signing by a key ==
trusted. You want shades of grey in trust, there aren't any. Signing a
package should mean exactly one thing...that the person doing the
signing vouches for the integrety of that package. You try to make
package signing mean more or less than that...and you are greatly
confuse the issue for the whole userbase, who BARELY comprehend the
need for keys as it is.
No one is going to stop and think...oh its signed with a different
key, that means its a different level of verifiable trust. Nope, thats
not going to happen. The loss in this case comes from a FALSE sense of
security inherent in using automated signing. I've seen several people
try to explain that to you, but you just don't seem to understand that
trying to change what signing means can lead to a false sense of
security for people who don't comprehend the change, and that the
absolutely worst thing one can do is to inspire a false sense of

You want to be able to have faith that mirrors are trustable? Is that
the extent of the goal?
Having signed metadata will serve much better as a verification that a
mirror is serving up mirrored packages correctly, without implying ANY
extra trustability to individual packages.
The metadata has md5sums for each package, to verify the integrity of
each package in the mirror. And signed metadata itself lets you verify
the mirror is servering up what the master repository expects, without
implying any trust to individual packages. Check the metadata
signature, then check the md5sums of each package against the metadata
at that mirror....that works, without changing the meaning of what
signing a package means.


More information about the test mailing list