Jason wrote: > > I would prefer to use the idea of a trusted site (like ftp.debian.org) to > fetch package file MD5 summs from, that way we do not get involed with the > sticky issue of cyrpto hooks.
What about: 1. Every package already contains MD5 checksum. 2. Each section contains two new files. The first is a list of (package name, checksum, signer, signed checksum). The signer would be the packager, who presumably already has PGP/GPG. The packager, in turn, would normally be the package maintainer. But this isn't necessarily always true, to the system needs to be flexible enough to handle a more general case. The second file is list of (signers, public keys). With offical packages, this list is already published in a package -- something which must be considered "dirty" until we find some other way to verify it. However we *could* sign this list by a trusted public key which is available from a canonical site, e.g., ftp.debian.org. This key should rarely change, so people will rarely need to ping the site. Authentication is then fairly simple: 1. Verify we have the current top-level public key, or download it. 2. Verify the signature on the list of signers with #1. 3. Verify the MD5 checksum signatures for each package with #2. 4. For each package, verify that the three MD5 checksums match. (Signed checksum, package checksum, and computed checksum). This system has several benefits: 1. It eliminates the chokepoint of checking ftp.debian.org for all signatures and/or checksums. It's entirely self-validating once you have that particular trusted key. 2. It only requires signatures by two parties. Packagers, who are presumably entering their pass phrases already, and the list of signers. That list would only change as maintainers are added or change their keys. 3. If you allow multiple top-level signers, it can support packages which use .deb format but aren't offical debian packages. E.g., I've created "debian" packages at work to manage internal tools used by my employer. These companies were small enough that everyone who used these packages knew me and could easily verify the package, but that's not true in many packages. > and it requires that the clients > know exactly which key to expect so changing keys becomes difficult. More precisely, they need to know who did the signature. Propogation of changed keys is a separate problem which must be addressed in any protocol. > We are not very vunerable to the sort of attacks we have heard of, someone > could go onto a mirror and could change a file and change the Packages > file but they would have to do that every single day! But how many people will download the packages in the meanwhile? Bear Giles [EMAIL PROTECTED]