Re: Bug#540215: Introduce dh_checksums
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
Reply to: