[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

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 :)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: