Re: Bug#540215: Introduce dh_checksums
Frank Lin PIAT <firstname.lastname@example.org> 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
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)
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.
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
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?
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>