One of the HF’s initiatives this last year has been the creation of a security advisory database for Hackage. This database tracks potential security issues with libraries, and can serve as the basis for a tool that lets you know if you’re affected. The group running the database explicitly did not sign up to build tools, however - that would have been a bit much to ask.
We’d been talking about the Right Thing for this kind of tooling, and the conclusion of an earlier thread is that we would need to access some GHC internals. The reason for this is that it’s important to avoid false positives that train users to ignore advisories. There’s an advisory for a quite obscure function in
base, for instance, and we certainly don’t want to warn every Haskell program on the planet about it - just those that use it. Thus, the database also tracks affected exports.
But this will take time and be a bit difficult to implement.
In the meantime, here’s a sketch of a tool that brings a big part of the value for much, much less labor. Let’s call it (for the sake of discussion)
konsilisto. When invoked on a project, it would do the following:
- Generate a Stack lock file or Cabal freeze file, or accept them as input
- Parse them using a combination of a YAML library (for Stack) or Cabal’s syntax and the Cabal library for the version specifiers included in it
- Now you have a build plan. For each dependency in this set of transitive dependencies,
hsec-toolsto determine whether the advisory database has any notifications about the library and version in question
b. If the advisories found haven’t been suppressed (see further down), then notify the user about them
It’s important to be able to suppress irrelevant warnings - there will be many false positives when using this kind of approach, and users should be able to investigate, see that the advisory is not relevant, and then not hear it anymore. Thus, there should be a file full of package, version, and advisory ID triples that the tool consults. The reason to give it all three elements, rather than just a list of advisories to suppress, is that an advisory may affect multiple packages, and if you come to depend on a new one where you are affected, or if an update means that your mitigation no longer is effective, you probably want to know.
This approach has a lot of advantages - there’s not many moving parts, it doesn’t need to be part of an existing tool, and it ought not require all that many dependencies. It’s certainly more annoying to use than our grand vision, but somewhat annoying tools that exist beat dreams any day. The SRT has offered to provide advice and tech support to anyone who takes this on.