On Fri, 2004-10-29 at 17:11 +0200, Nils Philippsen wrote: > So we (in a very much too broad sense of "we" ;-) are basically saying > that we should replace a mechanism that worked well for years with > another one that a) puts a burden on the people who "know what things > mean", b) doesn't really solve the problem with people doing things they > shouldn't do(*) and c) doesn't exist already? Great idea ;-). > First, I am *NOT* qualified to debate this intelligently. I am participating in this discussion mostly out of interest in learning about the subjects at hand. So I may say something incorrect, and you are hereby forbidden from beating me over the head with it. That being said, let me take your points one by one: 1. Replace something that worked well for years. What was the mechanism previously that let me verify that the updated kernel RPM on Mirror X was a bit-identical copy of the one actually published by Red Hat? I know how to verify ISO's but know of nothing that verifies a package was not tampered with after being placed on a mirror. 2. Puts a burden on people who know. Why? If a repo's metadata is signed, isn't that just one more check up2date and yum can perform to improve authentication of a package? Isn't that automatic? And can't someone also get it by hand if they choose? Besides, since you can always get the package *without* checking the metadata if you so choose with a simple "wget", what burden is put on these people? 3. Doesn't stop people from doing things they shouldn't do. No kidding... as I understood it, the idea of signing metadata had no "control" purposes in mind whatsoever. It was merely intended to be a way to know that the bits stored on server "A" were the same as those issued by the RHI buildsystem. How is this relevant? 4. Doesn't exist already. So what's your point? Tell me that it's a bad idea and explain why. But "doesn't exist yet" is a bloody silly argument. Seems to the unwashed masses here that signing repo metadata provides one benefit (knowing package A on server A is bit-identical to package A on server B) and has no real cost other than the addition of a new feature (which is even optional, since no one *has* to use it) to package managers like yum and up2date. I see no downside. Since you do, can you provide more detail on what and why? Cheers, -- Rodolfo J. Paiz <rpaiz@xxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part