Re: Bug#540215: Introduce dh_checksums
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
> Frank Lin PIAT <fpiat@klabs.be> writes:
>
> > Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
> > recent checksum.
>
> > The way it is implemented, is that the dh_md5sums is a symlink to the
> > new dh_checksums. The new helper computes both md5sum (for
> > compatibility/transition) and a new checksum (SHA256, which was already
> > chosen by FTP-masters as a remplacement for md5sum for signed files)
>
> 1. Strengthen the integrity check so that it could potentially be useful
> for security purposes as well as for simple integrity checking.
Yes, this is the intended goal. Imagine the following scenario:
1. You boot a trusted device with Debian Live or D-I
2. A helper mounts the root, usr and var partitions of the inspected
system
3. It then fetches the list of installed package and version
4. It then fetches the list of signatures for the installed system, from
your trusted mirror.
5. Then it validates the installed files on the inspected system.
6. You just have to trust one GPG key (per repository).
All that relies on the current infrastructure and chain of trust
(Repository's Releases.gpg->Packages.gpg->checksum). Alternatively, what
I am currently doing is to periodically export my md5sums to a trusted
system.
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).
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
Can you elaborate? checksums are currently signed, no?
> which apparently only require active maintenance and a plan to be
> acceptable in the archive and which would need a different format
> anyway.
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.
2. You still need an infrastructure to publish valid packages version.
3. What do we do when we want to change a GPG key? we re-sign all
the packages, probably breaking existing packages checksums?
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?
> 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?
As a bottom line:
1. A package is not safe because it is signed, but because it is
up-to-date.
2. I am completely ok go for GPG packages, *if* it can be implemented
by squeeze.
Otherwise, let's move on to sha*** for squeeze, which can be quite
transparent, and move to GPG post squeeze.
Regards,
Franklin
Reply to: