On Thu, 28 Oct 2004 19:38:02 +0200, Matias Féliciano <feliciano.matias@xxxxxxx> 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 packages...by 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 security. 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. -jef