restrict the set of accepted digest algorithms

[HW42]

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.

Yes I'm aware of this. My question here on gnupg-devel concerns only the
gpg part. I mentioned apt just as one example.

> 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: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150210/e3a3e5fd/attachment.sig>