On Mon, Mar 08, 2010 at 11:04:24PM +0100, Frank Lin PIAT wrote: > On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote: > > 1. Strengthen the integrity check so that it could potentially be useful > > for security purposes as well as for simple integrity checking. > > It would be much easier if a signed list of check-sums for current > packages in our archive were published (basically, when we create > Packages.gpg, we would need to extract the checksums contained in those > packages, then sign it. This list could also included the recently > updated packages, which is useful for point-releases, and unstable).
I'm a bit confused here. I think that here is a mix of package signatures and file signatures. These serve different purposes and are completely separate. A package signature lets you verfy the package before it is decompressed and, more importantly, maintainer scripts are run as root. File signatures let you check the installed files. Both should be part of the shipped package. Package signature as files in the arch archive, file signatures should be installed along with the files so you can always directly check installed files, without the need of any repository or original packages lying around. > > The benefit is that you can quickly audit if installed binaries are > pristine AND current. > > > If we take option 1, going to a stronger hash is strictly less useful in > > every respect than going to embedded PGP signatures Assuming file hashes here: create stronger hashes and then sign the hash file. This has 2 advantages: - hashes can be used to check file integrity even without the key - it can be implemented incrementally (1st: stonger hashes, 2nd: signature) > > which apparently only require active maintenance and a plan to be > > acceptable in the archive and which would need a different format > > anyway. Assuming package hashes here: a view additional files in the arch archive. > > I see some problems with signed packages: > > 1. Software developers and vendors will start distributing standalone > binary packages, and pretend they are "safe" because they are signed. > This is not safe: only an APT-like mechanism provides security > updates. Yes, there seems to be a common misconception about what a signature means. But that's no argument to deny informed people the advantages of signatures. > 2. You still need an infrastructure to publish valid packages version. Isn't that the Release file? > 3. What do we do when we want to change a GPG key? we re-sign all > the packages, probably breaking existing packages checksums? No, the signature has a timestamp and is still valid, if the revocation date of key is later. > Last but not least: > > 4. How long is it going to implement it? Does it seems realistic to > implement your proposal before Squeeze +1 (or event Squeeze +2)? > What do we do in-between? > > > If we take option 2, SHA256 offers no benefits over MD5 and just takes > > longer to compute. > > Why is that everyone seems to move away from MD5? Because it's broken? > > > There is essentially zero chance that random file corruption or > > typical local modification will result in a successful MD5 preimage > > attack. > > An attacker has plenty of time to pre-compute a valid replacement for, > let say, a library in Debian Stable. > > > I therefore have to question what utility there is in switching to SHA256. > > It doesn't seem to achieve either possible goal, unless I'm missing some > > way in which it's a step towards option 1? See above. > As a bottom line: > 1. A package is not safe because it is signed, but because it is > up-to-date. A signature hasn't got anything to do with how safe a package is. harry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309033126.ga15...@nn.nn
