On Mon, 1 Nov 2004 13:47:32 -0600 (CST), Satish Balay balay@fastmail.fm wrote:
But unless you are saing: somehow the current non-gpg-signed packages are preventing such folks from doing the wrong things (listed above) - and 'gpg-singing' encourages them to do them - your text adds no substance to the discussion.
Fine ill repeat myself...again.
Yes... i firmly believe...that long term... as tools become more signature aware and tools become more demanding that signatures be present on consumable rpms, that signing throw away packages like rawhide packages encourages people to use those packages out of context, and encourages people to store individual rawhide packages for later use on other systems, instead of encouraging people to using a full rawhide collection.
We can argue about the techical definition of what gpg-signing means...as originally conceived in the pgp/gpg methodogy, but is a pointless thing to discuss... in the context of rpm package signing. rpm package signing is NOT a full implementation of a gpg/pgp signing system. rpm's lack of understanding of what a signed key is, greatly impacts "trust" as a quantifiable concept..and automatically elevates all signd packages to the same "trust" status. Whereas mature general use gpg/pgp implementations know what a sign signature means, and how to calculate "trust" from signatures on keys. If you trust me, and i sign someone elses key, that key earns a measure of trust from my signature. gnupg understands this concept of the web of trust.. rpm does not...that is significant in the context of how rpm package sining has been used so far. Because there is a lack of trust metric in rpm's implementation, packaging signing..by vendors..has historically meant more than prescribed by a general gpg methodology definition of signing. This isn't a matter of one or two really really stupid users doing something really really stupid. This is a matter of common peception as to what signing a package means, and what vendors has historically wanted people to think signing a package means... in the context of rpm's implementation of signing and not in the context of gnupg's or pgp's general purpose implementation. And I argue that historically... rpm package signing has meant more than "built on this host" and that many vendors including Red Hat have meant it to mean more than "built on this host." And i will argue that until rpm get support for the trust metric concept using signed keys, signing rawhide packages encourages people to "trust" rawhide packages. Where "trust" is a quantifiable measurement based on key signatures.
-jef
On Mon, 1 Nov 2004, Jeff Spaleta wrote:
On Mon, 1 Nov 2004 13:47:32 -0600 (CST), Satish Balay balay@fastmail.fm wrote:
But unless you are saing: somehow the current non-gpg-signed packages are preventing such folks from doing the wrong things (listed above) - and 'gpg-singing' encourages them to do them - your text adds no substance to the discussion.
Fine ill repeat myself...again.
Yes... i firmly believe...that long term... as tools become more signature aware and tools become more demanding that signatures be present on consumable rpms, that signing throw away packages like rawhide packages encourages people to use those packages out of context, and encourages people to store individual rawhide packages for later use on other systems, instead of encouraging people to using a full rawhide collection.
I (as a clueless user) can do the same thing with unsigned packages. gpg doesn't encourage anything new to the clueless user.
We can argue about the techical definition of what gpg-signing means.
lets not
This is a matter of common peception as to what signing a package means, and what vendors has historically wanted people to think signing a package means... in the context of rpm's implementation of signing and not in the context of gnupg's or pgp's general purpose implementation. And I argue that historically... rpm package signing has meant more than "built on this host" and that many vendors including Red Hat have meant it to mean more than "built on this host." And i will argue that until rpm get support for the trust metric concept using signed keys, signing rawhide packages encourages people to "trust" rawhide packages. Where "trust" is a quantifiable measurement based on key signatures. -jef
- Here the assumption is: EVERONE's perception about gpg-signed rpms (or rawhide) is the same.
- And perception is no excuse for proper documentaion.
- There will always be wrong assumptions by users. This doesn't equate to not signing-rawhide-packages. [And documenting it]
And as Matias already pointed out - lets not mix QA perception with 'signature'.
Satish
On Mon, 2004-11-01 at 14:51 -0600, Satish Balay wrote:
- Here the assumption is: EVERONE's perception about gpg-signed rpms
(or rawhide) is the same.
No, just that a significant number of people to make us all miserable believe it means more than "the vendor says this is the one you meant to download".
- And perception is no excuse for proper documentaion.
But when proper documentation and perception differ, perception has already won. I agree, we should document whatever is agreed upon. But let's not agree on something unlike the real world's current perception. That's just silly.
And still, proper documentation is no excuse for non-explicit data formats.
- There will always be wrong assumptions by users. This doesn't equate
to not signing-rawhide-packages. [And documenting it]
The proposal for signing rawhide packages does nothing to dissuade those wrong assumptions, even though it's a relatively easy thing.
And as Matias already pointed out - lets not mix QA perception with 'signature'.
And let's not mix "signature" with "signature on one piece of data that makes a specific claim". We don't have the latter, and it's best not to use the former at places where it's important for people to have the more limited set of expectations.
To sign or not to sign - that is the quesion - or not. Whether it is nobler ... oh never mind ...
Guys, shee enuff already. What is the big deal here.
Its completely obvious that some way of reducing spoofed mirrors is a good thing - signing (even) rawhide is a good thing - sure its not perfect but it helps.
Use a different key than is used for released versions if its your pleasure. Change the key every month or every new develop cycle - whatever makes you happy.
Noone is putting any more significance beyond a little added safety check that lessens the chance of bad things - seems enormously rational.
g/
On Mon, Nov 01, 2004 at 06:11:26PM -0500, Peter Jones wrote:
On Mon, 2004-11-01 at 14:51 -0600, Satish Balay wrote:
Le lundi 01 novembre 2004 à 15:14 -0500, Jeff Spaleta a écrit :
We can argue about the techical definition of what gpg-signing means...as originally conceived in the pgp/gpg methodogy, but is a pointless thing to discuss... in the context of rpm package signing. rpm package signing is NOT a full implementation of a gpg/pgp signing system. rpm's lack of understanding of what a signed key is, greatly impacts "trust" as a quantifiable concept..and automatically elevates all signd packages to the same "trust" status.
The "trust" in gpg, only define the trust about the origin of the key ! _NEVER_ a key will define the "trust" you should put on a package. A signed package tell the origin of the package. The origin of the package (with some documentations (QA), reputation of the provider, friend's advices, ...) tell you if you would take the risk (or not) to install the package on you system. The decision to install the package, is up to you. Not to gpg.
You can fully trust my gpg key (because my friends sign my key and you know my friends), but you should not trust me if I say you : "please, enter 'rm -r -f /' as root" :-) The trust in gpg is not an indicator of quality or intelligence.
Whereas mature general use gpg/pgp implementations know what a sign signature means, and how to calculate "trust" from signatures on keys. If you trust me, and i sign someone elses key, that key earns a measure of trust from my signature. gnupg understands this concept of the web of trust.. rpm does not...
Use something like : $ gpg --refresh-keys --keyserver pgp.mit.edu [...] $ LANG=C rpm -K -v udev-039-6.i386.rpm | sed -n -e "s/.*Header.* ([[:alnum:]]+)$/\1/p" | xargs gpg --list-key -v pub 1024D/4F2A6FD2 2003-10-27 Fedora Project fedora@redhat.com sig 3 4F2A6FD2 2003-10-27 Fedora Project fedora@redhat.com sig 3 DB42A60E 2003-10-27 Red Hat, Inc security@redhat.com sig 8DF56D05 2003-10-28 Fedora Linux (RPMS) security@fedora.us sig 3 D1C76C53 2004-04-26 Féliciano Matias (normal) feliciano.matias@free.fr sig 11E60E88 2004-08-07 [Nom utilisateur introuvable] sig 003E1D9D 2004-08-07 [Nom utilisateur introuvable] sig FAF6AFE3 2004-08-07 [Nom utilisateur introuvable] sig 2A74F90D 2004-08-07 [Nom utilisateur introuvable] sig 7BAC7F6C 2004-10-23 [Nom utilisateur introuvable] sig 2 CF4655CF 2003-12-15 [Nom utilisateur introuvable] sig 2 BE950472 2004-05-17 [Nom utilisateur introuvable] sig 3 BB4B29A7 2003-12-03 [Nom utilisateur introuvable] sig 3 A8F02EF5 2004-10-21 [Nom utilisateur introuvable] sig 3 D950C647 2004-01-20 [Nom utilisateur introuvable] sig 3 02FF71B2 2004-02-15 [Nom utilisateur introuvable] sig 3 ADD4C933 2004-02-21 [Nom utilisateur introuvable] sig 3 8B415BA9 2004-03-29 [Nom utilisateur introuvable] sig 3 DC29E554 2004-03-29 [Nom utilisateur introuvable] sig 3 R A403ECA0 2004-02-23 [Nom utilisateur introuvable] sub 1024g/FB939E34 2003-10-27 sig 4F2A6FD2 2003-10-27 Fedora Project fedora@redhat.com
Well, I have a little gpg keyring.
This only say : - I can trust the origin of the key and then the origin of the package. Nothing else. Suppose I ran this command under RHEL 2.1. Should I install udev on RHEL 2.1 ?
that is significant in the context of how rpm package sining has been used so far. Because there is a lack of trust metric in rpm's implementation, packaging signing..by vendors..has historically meant more than prescribed by a general gpg methodology definition of signing.
The vendor : trust own solution for mission-critical, because ..., because... The client : I trust you because ..., because ... The vendor : Get the product (package) here. The client : How can I be sure this package come from you ? The vendor : The package is signed with own key. Own key is signed on pgp.mit.edu by other people.
NB : The client trust the vendor as a provider of mission-critical solution, _before_ using any signature.
This isn't a matter of one or two really really stupid users doing something really really stupid. This is a matter of common peception as to what signing a package means,
What is this "common perception" ? People trust RHEL for mission-critical server but they don't trust Fedora for mission-critical. However Fedora _and_ RHEL have signed rpm.
and what vendors has historically wanted people to think signing a package means... in the context of rpm's implementation of signing and not in the context of gnupg's or pgp's general purpose implementation. And I argue that historically... rpm package signing has meant more than "built on this host" and that many vendors including Red Hat have meant it to mean more than "built on this host." And i will argue that until rpm get support for the trust metric concept using signed keys, signing rawhide packages encourages people to "trust" rawhide packages.
"trust" me, rawhide is full of bugs. We don't any "metric concept using signed keys" to know that.
Where "trust" is a quantifiable measurement based on key signatures.
-jef
-
Féliciano Matias -
Genes MailLists -
Jef Spaleta -
Peter Jones -
Satish Balay