Le lundi 01 novembre 2004 à 12:27 -0500, Peter Jones a écrit : > On Fri, 2004-10-29 at 12:57 +0200, Nils Philippsen wrote: > > > > The question is still one of gains versus losses. I personally think we > > > gain more by _not_ signing them. If we automatically sign them, we make > > > it more convenient for people who don't want to use --nosig or whatnot > > > on rawhide packages. > > > > If we don't sign packages we make it basically impossible for people to > > check where a specific package comes from. > > Yes, but the current signing method does not do _precisely_ that. It > does many things, and that is one affect. > > > There is nothing else that a signature on a package says. > > That's simply not true. > > It says that we intended to release it in a form that is fit to be used. > (Although clearly it does not imply any warranty, including the implied > warranties of merchantability and fitness for a particular purpose ;) > > It says we believe that the actual data in the package headers -- the > scriptlets, the triggers, the conflicts, the provides, etc. -- are of a > quality that Fedora believes is sufficient for release. An announcement (or linux/core/3 in download.fedora.redhat.com ...) tell me that there is a new release which is quality approved by the Fedora team. Not the signature of the package. A signature only say me where the package come from. > These things > are Red Hat's and Fedora's value add, and a signature says that we > believe we've actually added value. Where have you read this ? Do you have any URL ? If I remember correctly, FC2 (with all packages signed) "burn" some mbr. What is the meaning of signed package in this case ? A signature, which can be part of a quality process, ensure where the information/data/package come from. A signature is not a certificate of quality _without_ a quality process. > It also conveys that some packager whom we trust has looked over the > payload and does not consider its contents to be *hostile* to our users. > > Consider RHEL errata. When RH releases an erratum, the signature > doesn't just say "this is some package from Red Hat". The signature only say that. > It says that you > can use the signature, combined with the checksums and the data in the > erratum. For what can they be used? You should already know the answer > here. What the signature provides is a way to verify Red Hat's intent > and belief that the package in the user's hands does actually fix the > problems described in the erratum, and to some (lesser) extent that it > does not introduce more problems You are mixing quality process and signing. sure, a signature can be tighten to a quality process. But a signature "alone" is not a certificate of quality. If Red Hat sign rawhide package with a key that is not tighten to a quality process, the signature only tell where the package come from. > So, no, it's not just that it comes from Red Hat. That's really a more > minor point of what it's for. > > > > That's not a win. In fact, it's a big loss. If the packages are > > > automatically signed during the build process, the only thing the > > > signature means is "it showed up in the queue of things to be signed". > > > But if you see a signed package, the impression you get is that it is in > > > some way "trusted". Of course, it isn't trusted. It's just got a > > > signature that says "don't make the user type --nosig". > > > > That's a misinterpretation of the signature on the package. We shouldn't > > sign or not sign packages based on how people could misconceive what > > such a signature means. We should sign packages so people can verify > > that these packages are actually from us and haven't been tampered with > > in the meantime. > > We always have used signing to mean more than just this, That's almost right. This does not imply that all signature have the same meaning of the key "<security@xxxxxxxxxx>". > and the other > things are equally important, if not more so, to us. We can't mean just > that the transport is ok without giving the rest up. We cannot have it > mean one thing sometimes, and more things some other times, Why not ? Here the mean of the rawhide key : https://www.redhat.com/security/team/key/ Rawhide Package Signing From time to time Red Hat make development software available, usually as part of Rawhide. These packages may be signed by an automated build signing key. Because this key is used automatically we expect to change the key we sign with from time to time. There is not any guaranty. > unless the > signatures have actual data about what they represent *built in*. Who > is signing it is not enough, and that's currently all we have. If the > only way to tell the difference in what the signatures mean is the key > of the signer, then most people who *do* care will never know what any > signature means. > > So yes, we both agree that we "should sign packages" (or some data that > can be securely matched with it, like the metadata) "so people can > verify that these packages are actually from us and haven't been > tampered with in the meantime." What we don't agree on is the fact that > this is very much NOT what we currently do with signatures. > I remember that all package in rawhide are signed during RH8.0 and RH9 beta. Does it cause any damage to Red Hat or to the meaning of "<security@xxxxxxxxxx>" ? No. As long that where is no page that state why/when a key is used, we can give any meaning to a key.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=