On Thu, 2012-10-11 at 20:18 +0200, Kurt Roeckx wrote: > dpkg-genchanges and dak both generate md5, sha1 and sha256. So > .deb files themself are hashed by all 3 of them. A as far as I > know all tools that verify those files also check all 3 of those > hashes. Ah? Ok... I somehow had in mind that a) generating the "stronger" ones was just optional,... and that they were not yet everywhere verified. > So basicly the question is if we want to keep the md5 and sha1 in > those files or not. Probably... and nothing speaks against adding sha512... or (once it has been well introduced) Keccack. > MD5 is covered by policy :-/ > , and it's the only mentioned in policy, > maybe that should change. Guess so. > There are also the md5sums files that are stored in the .deb file. > I'm not really sure what the real use case for them is and > wouldn't have a problem with them going away. Well these are the ones for dpkg, aren't they? Where it was mentioned before, that they are not primarily intended for security (but where I replied, nothing keeps users from using them for this purpose). > I see no reason why we can't also add SHA-3 to the files when the > tools become available. :) I further looked around: e.g. the Release file seems to only use MD5.... not so good :( Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to have a "special status" (Files vs. Checksums-<algo>). That might be just historic, though. Similarly the Packages files... MD5/SHA1/SHA256... If they are all checked (and verification is considered to be failed if a single one doesn't match)... then I guess I'm quite happy. Though I would still think, that on a mid-/long-term-range it doesn't harm to drop MD5/SHA1 e.g. in favour of SHA512/Keccack. > > Or, like in the case of package files (dsc and friends) make a policy of > > verifying all hashes, and fail if any single doesn't match? > As far that's already the case? That would be good :) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature