Skip to content

Finally moving away from weak hash algorithms (and extra-files while we are at it) #25876

@hannesm

Description

@hannesm

Dear values maintainers and OCaml developers and watchers of this repository,

since a long time it has been known that MD5 is a weak hash algorithm. drum beat

Finally there's a CI lint check to avoid fresh md5 checksums being added to this repository (ref ocurrent/opam-repo-ci#304). \o/

Now, there's a bit of legacy: we have around 19099 occurences of the string "md5=" in this repository.

This is distributed across the URL field of opam files and extra-files of opam files. Furthermore, extra-files are slightly painful, and the extra-source fields are preferred. I propose to change the following in one PR:

  • Add to all checksum where there's only md5 a sha256,
  • Replace all extra-files with extra-source pointing to a remote git repository (preferably under the ocaml or ocaml-opam github organisation) EDIT: I'll just use the opam-source-archives repository for that, and use sha256 as checksum for these files,
  • Get a lint check in place that prevents us from accepting any opam packages with extra-files

(Of course, we can as well use sha512 if someone knows about feasible attacks on sha256, the former is unfortunately way slower esp. on e.g. Raspberry Pi hardware.)

For the first two items, based on opam admin from opam 2.2 I have OCaml code that does this automatically (see https://github.com/hannesm/opam/tree/migrate-extra-files). I'm also fine to submit a opam-repo-ci PR for the lint check.

The only leftover question is whether there is any pushback or concerns? (I'm curious whether this must wait for opam 2.1.6 since earlier versions are not able to remove files on some operating systems (such as macOS)?) -- any insights?

Please raise your concerns via comments, and express your support (👍🏾) or not support (👎🏾) via reactions here.

(PS: I proposed an earlier document/PR at #25874 - where @mseri gave positive feedback, but I believe when we do such a change, let's do it at once.)

Earlier discussion at #17315 https://discuss.ocaml.org/t/opam-repository-security-and-data-integrity-posture/6478 -- Now 4 years later, I think we can act.

This is as well a necessary step for getting cryptographic signatures -- well, or at least it simplifies the design tremendously -- both having non-weak checksums of external data, and also not having arbitrary files around.

Regards from the security engine room

Update: this has been discussed and approved in the 2024 May 22nd opam-repository meeting https://github.com/ocaml/opam-repository/wiki/Meeting-notes#2024-05-22 -- there's no blocker to move forward.

Tasks to do:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions