On Fri, 29 Oct 2004 17:34:48 +0200, Nils Philippsen <nphilipp@xxxxxxxxxx> 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