Request for comments: What to do with opam packages that have known security vulnerabilities

Community
,
1

Dear everyone,

we (the OCaml security) team is curious what the practice should be for opam packages that have known security vulnerabilities?

One way is to mark them with available: false in the opam-repository, which will make them not installable (apart from if you manually edit the opam file).

Especially for the OCaml compiler it is a tricky question: the recent vulnerability (in Marshal) affects everything < 4.14.3 | > 5 & < 5.4.1 – so marking these compilers as unavailable will result in lots of projects that require such older OCaml versions to not be easily installable anymore. Especially since the Marshal issue is not exposed in many (any?) applications, it feels wrong to disallow / make it hard for anyone to install these compilers.

Some ideas we have for the future:

  • annotate the exact function(s) that is/are vulnerabile in the security advisory (thus, you could automatically search for use of that function)
  • provide an “opam audit” which takes the advisory database and inspects your opam switch whether you have installed any vulnerable package

But for the short & medium term, we’d appreciate input on what to do with normal opam packages that have advisories; and also whether to treat the compiler packages differently or not.

3 Likes
2

An idea could be to have a dedicated security-message: field working like post-message:. On opam update you collate these messages for the installed packages and spit them out at the end of the update. And on install you spit them out at the end of the install if you installed a vulnerable package (or if there is any vulnerable package in the install).

5 Likes
3

As the days go along, you can take a peek at opam-audit GitHub - hannesm/opam-audit: Audit your opam switch for vulnerable packages · GitHub – a utility to figure out whether (and which) vulnerable packages you have installed in your opam switch. It uses some opam functionality, and the ocaml/security-advisories “database” underneath (together with the great jsont/cmdliner/bos/fmt/logs Buenzli libraries).

Yes, of course, PRs are always welcome.

1 Like
4

Sounds like a great idea. The only downside is that it requires changes to opam. But maybe the developers thereof are reading this carefully. Another downside is someone needs to add these security-message: fields to the opam files… But I guess that is manageable.

5

Somehow I don’t see myself spontaneously run opam audit, that’s the reason why I think it should rather be integrated in the commands you find yourself running routinely.

1 Like
6

There are various paths forward with this:

  • of course your proposed security-message: can be moved forward;
  • the available: false is still an option (though it doesn’t give you any nice error message);
  • the opam audit functionality can be integrated into opam & opam install (or update);
  • likely there are more options that I can’t come up with right now…
7

You still want opam audit, it should just spit out those security-message: of the packages you have installed.

1 Like
8

I like the security-messages field and an opam audit database! Some other ideas that don’t really work on their own:

  • opam supports flags: avoid-version which causes the solver to try really hard no to install that version (it’s a lighter way to do available: false, but AFAIK opam doesn’t warn when it can’t avoid a version). Users can do a cheap “audit” with opam list --installed --field-match=flags:avoid-version(the same query would also work for --field-match=security-messages:, but in any case it deserves better integration or a custom CLI as I wouldn’t expect users to guess these flags)
  • opam-repo could ship a patch for the affected functions to alert direct users (but not transitive ones, so it’s either insufficient or a huge pain to patch every potential endpoints)
  • If we had a database of vulnerable functions, Lexify’s ocamlgrep and/or Merlin’s ocaml-index can search for occurrences in a code-base, but similarly I don’t think they support querying transitive dependencies out of the box
1 Like
9

That’d definitely be useful for advisories like the Marshal one (there is a list of affected functions in the text, but not in machine readable form yet).
AFAICT there is no standardized OSV schema yet for describing the affected functions, although there are some efforts towards that: Unified field for describing affected functions · Issue #127 · ossf/osv-schema · GitHub.
Go, Rust and Github advisories already support it, but (because it wasn’t standardized) with their own ecosystem specific fields with different names: Unified field for describing affected functions · Issue #127 · ossf/osv-schema · GitHub

For now we could adopt one of the ecosystem specific definitions from Go or Rust as the OCaml one? The symbol is ecosystem specific in some way anyway (e.g. we’ll probably specify the OCaml Module, Module.function, and not the mangled symbol name).

1 Like