On Sat, Nov 29, 2008 at 8:37 AM, Thomas Bächler <thomas@xxxxxxxxxxxxx> wrote: > Gerhard Brauer schrieb: >> >> For myself i don't accept the "md5sum is bad" argument as a "stopper" >> for each idea to provide a pacman secure concept ;-) > > I wasn't going to stop you. Signed db files are an important first step. > > My point is that it was often suggested to move from md5 to something more > secure. This suggestion was always rejected because we never used md5 for > security. If we are going to implement your suggestion (and I vote that we > do), we should really consider a better hash! I think we're confusing things here. The checksums in pacman are only used for integrity, not security. I agree that the first step towards super-omg-secure packages would be switching to a different checksum, but sha1 might be deemed insecure soon too. Why not jump over that one to something like sha256? Now, once we do that, we're still stuck with the fact that anyone with a mirror can modify a package, and change the checksum, whatever it may be, in the DB file. So changing checksums isn't doing one iota of good until we can ensure that our list of checksums can't be changed. I talked to Dan about this briefly the other day. What we concluded was that the most proper and secure way to do this is as follows: * gerolde hosts a "developer keyring" * developers sign their individual packages with their own keys * the database file still contains the integrity checksums * the database file also includes package signing data The current proposition, with one key on gerolde used to sign the DB, is insecure in that it makes the developers the weak point. If all of gerolde, or even only those with sudo rights, can see this private key, all it takes is maliciousness on one person's part and all our packages are vulnerable. The whole point of a private key is just that - that it's private. If we suddenly make this key "semi-public", we open the door to lots of other issues, at the human level. When I last spoke to Dan, the biggest issue here was that gpg doesn't have a library interface. We'd have to call the binary directly from pacman. If we look at the above solution, we can leverage the XferCommand to cover this, without affecting pacman at all: * Create a download script that will download a package, check the integrity checksum, and verify the signature in the database using the archlinux.org keyring * Pacman will continue to work as is, considering the checksum is still in the DB All we'd need is to patch repo-add to include signature data in the DB. To do this properly, signatures should be uploaded with the package itself, from the packager's machine... hmmm
