restrict the set of accepted digest algorithms

[Christoph Anton Mitterer]

On Tue, 2015-02-10 at 03:45 +0100, HW42 wrote: 
> For example I would like to restrict the set of "accepted" algorithms to
> SHA2 for code verification in a package manager like apt.
I wouldn't think that you can reach *that* sepcific goal via restricting
the accepted hash algos on the GPG side... at least not per se.

The reason is how secure APT works (and note, that I'm not talking about
debsigs).
Secure APT, uses a single central "Release"[0] file per APT repository,
as the root of all verification of further repo data (including the
actual [source] packages).
This, and only this, file is OpenPGP-signed and verified via gpg.

All other files of the next level, these are for example the "Sources"
and "Packages" files, are verified via hash sums in the Release files
(which are secure, since the Release file was verified).
These files in turn, contain hashes for the next level, which are e.g.
the source packages or the binary packages.

The syntax allows for different hash algos to be used in these files.


Now comes the bad part:
APT had (at least until recently) several bugs, in that it e.g. only
verified MD5 (which has still a somewhat special status there, at least
syntactically)... IIRC *that* specific issue was fixed some months ago,
but I'm not sure about the general status.
E.g. the "best" that current production files generated by the Debian
repo servers contain is SHA256.

In my opinion, APT should have some minimum set of algo(s) that it
expects to be present (and if not, the target file should be considered
forged).
If the files would contain more hashes per target file, then *ALL*
should be validated and if a single one doesn't verify, the target file
should again be considered compromised.

As said, I don't know about the current status, but I believe that this
is *not* the case.


Unfortunately Debian doesn't take security really very serious in that
areas,... which shows also on the quite long validity times of the
Release files, which in turn allows blocking/downgrading attacks.
I've started several discussions on matters like these on debian-devel
and opened bugs (e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752450)... but it's
like fighting windmills and basically no one really cares.
Probably also, why MD5 was used so long without an outcry :-(


Cheers,
Chris.


[0] Technically there's an alternative "InRelease" but that's basically
the same in green.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: </pipermail/attachments/20150210/3fa94092/attachment.bin>