Re: Bug#540215: Introduce dh_checksums
On Mon, Mar 08, 2010 at 12:59:00PM -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)
>
> If there's a general consensus that we should go this route, I'm okay with
> it, but I'm personally not sure this is the right approach.
>
> I think there are two possible directions we can take with this package
> feature:
>
> 1. Strengthen the integrity check so that it could potentially be useful
> for security purposes as well as for simple integrity checking.
>
> 2. Declare such checksums only useful for corruption and local (benign)
> modification checksumming.
>
> If we take option 1, going to a stronger hash is strictly less useful in
> every respect than going to embedded PGP signatures, which apparently only
> require active maintenance and a plan to be acceptable in the archive and
> which would need a different format anyway.
Maybe, but we're not there yet.
At any rate, a PGP signature takes a lot of data; much more so than a
checksum. It's therefore more economical to produce a signed
package.checksums file than it is to produce a package.pgpsigs.
Having package.checksums be GPG-signed will take a significant change in
our infrastructure (buildd hosts, for instance, would need to have a way
to sign checksums files as well), so it's not going to happen tomorrow.
But changing to a more secure checksum algorithm could be done easily
with current infrastructure.
And since checksum files are generated at build time rather than at
install time, it is possible to download a known-good copy of the .deb
that is installed (using snapshot.debian.org, once it gets live, for
instance, or from a not-compromised host's apt cache), and verify the
files against that copy rather than the copy that is on the disk. Until
signed packages or signed checksums are available, this would of course
be a stopgap measure, but one that would actually work -- provided, of
course, that the used checksum algorithm is cryptographically secure,
which MD5 is no longer.
> If we take option 2, SHA256 offers no benefits over MD5 and just takes
> longer to compute. There is essentially zero chance that random file
> corruption or typical local modification will result in a successful MD5
> preimage attack.
Of course, that much is true.
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
Reply to: