On Sat, 1 Apr 2000, Marcus Brinkmann wrote: > We already use link 1 (signed changes files), and trust it. This won't > be changed by either proposal. Yes, even in the signed packages file you > trust all developers keys.
We only trust link1 due to the vigilance of our FTP masters and people reading -changes lists to make sure that, say, glibc is not uploaded by someone other than Joel. That is a critical part of the trust in that step. > Now link 2. It is currently absent. What you seem to suggest is to add a key > (dinstall-key) here, so the user can verify the archive. This adds a point > of weakness. As the dinstall key can't be used automatically and kept > "truly"[1] How about this, if someone was able to hack master to the point of being able to get the dinstall key, I assure you they would be able to hack some]weak developer machine and lift their key too. I also assert that the chance of a hacker getting the security key is lower than say 50% of the keys in our keyring. Furthermore it is comparitively easy to revoke a dinstall key - much harder to detect and revoke individual keys. > What link 2 asserts instead is that the packages come from master. It solves > the mirror problem, but does not solve the master problem. The master problem cannot be solved in an automatic fashion, it will always require skilled intervention by a human. Jason
