Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checksum enforcement, banning MD5? #833

Open
palmskog opened this issue Jul 15, 2019 · 5 comments
Open

Checksum enforcement, banning MD5? #833

palmskog opened this issue Jul 15, 2019 · 5 comments

Comments

@palmskog
Copy link
Contributor

Since MD5 is known to not be collision resistant, and has been described as "cryptographically broken and unsuitable for further use", I think it's time we actively phase out MD5 for archive checksums. Most directly, we should refuse to merge new packages with any form of MD5 checksum.

I propose that we recommend SHA512 checksums, since they are faster to check on 64-bit processors, while being cryptographically at least as strong as SHA256 checksums. However, I think we should still allow SHA256 checksums.

@silene
Copy link
Contributor

silene commented Jul 16, 2019

You seem to imply that the checksum field was meant for cryptography use in Opam. As far as I know, the field is only there to ensure the integrity of the download (e.g., truncated file), not to guarantee that the downloaded file was not modified by an attacker. So, I don't mind recommending SHA512, but using its cryptographic strength as a rationale is quite misleading, in my opinion.

@Blaisorblade
Copy link
Contributor

Based on my understanding of ocaml/opam#3320 and https://opam.ocaml.org/blog/Signing-the-opam-repository/), MD5 should indeed be deprecated.

Note that opam2 supports other hashes, so we're well on the way towards deprecation of md5 completely.

Now, that's not enough — but instead of trusting everybody on the Internet, you only have to trust the maintainers/authors of the opam repo in question, and GitHub; attacks remain possible but much less likely.

@gares
Copy link
Member

gares commented Oct 17, 2019

I guess it is up to the opam lint utility to complain, and to the opam admin one to let us update all pks in one go. When they decide to really deprecate, we can just follow their lead.

@palmskog
Copy link
Contributor Author

I still think we should try to be ahead of the opam lint deprecation, i.e., actively suggest changes to submitted packages to use SHA512 (preferred) or SHA256.

@palmskog
Copy link
Contributor Author

One proposed solution to manage trust package cryptographically (also mentioned in ocaml/opam#3320) is conex, which essentially handles signing of packages by authors. This might be more feasible to implement for the Coq OPAM repo than the general one...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants