Hi! I have made a small tool that can check your haskell applications against the security-advisories database kindly maintained by the haskell security working group.
It runs the cabal solver, then checks out the security-advisories repo and tells you about matches with the security-advisories database.
Output is available in human-readable and machine-readable form.
I’d be happy to help there. I’m currently trying to get cabal-audit on hackage such that this can be installed with cabal install cabal-audit but I’m also worried about not having trivial-ish distribution.
cargo_audit can be installed by running cargo install cargo_audit, cargo has a similar feature to cabal >= 3.12 where subcommands are invoked if there’s as cargo-<subcommand> command available in $PATH.
crates.io has a directive Development tools::Cargo plugins, we should probably add a documentation section in the cabal repository that asks the implementer of a plugin to tag their hackage upload with cabal-plugin (or cabal-plugins if you will)
If cabal had proper binary handling and a good install interface, this wouldn’t even be needed. You could simply create a “meta” package that depends on all those other packages. Then an install wouldn’t just install executables of the immediate target, but also of the dependencies.
Hello @MangoIV , thank you for pushing that work! During the last HSRT meeting we talked about providing a better format for such a tool so that the end users don’t need to have git. For example, when updating the website, we could push a sqlite or a tarball with the relevant files, would that helps cabal-audit?
Also, I previously worked on another cabal-audit tool and I just pushed an update to the README to points at your implementation. You can find my experiment here: GitHub - TristanCacqueray/cabal-audit
edit: I misremembered, there was already the proposal of pushing a single artifact, I proposed an actual API
Also sorry, I wasn’t aware of your … quite elaborate? experiment, super cool! How does it determine which declarations are affected by an advisory? (i.e. I didn’t see machine readable information about that in the advisories itself?)
otherwise, yes that would be nice, I found it quite troublesome that some of the information about the advisories is hidden in the git history, i.e. the advisories DB is not parseable without knowing the git history as the timestamps (?) rely on that.
I think there was some miss communications. Providing a machine readable format for the advisories is planed, it’s running a web service for it which was deemed out of scope. I think we are looking for a static file format to be published along with the website. See the following feature request: advisory distribution and caching mechanisms · Issue #170 · haskell/security-advisories · GitHub
This information is not yet available. We need to specify a format, for example:
I wonder if there’s really a complete way of doing this, sounds like an interesting problem, like, even if you manage to get no false positives for a single build, how do you avoid that you don’t get false negatives, I guess this would require the end user to run the auditing on all the different setups they also use the program on…
Currently, tbh, I’m more concerned about false negatives, especially as the amount of actual advisories isn’t so vast as that they can’t be checked for applicability by hand. Ideally any such advisory should be fixed anyway, no matter if the specific definition is used in your project, no?
That’s right, a given executable target may produce different callgraphs depending on the setup, so you’ll have to audit each individual build. I agree with you, false negatives are more important right now and I think your approach is better for the cabal-audit tool.
However, it does not seems like HSEC-2023-0007 is going to be fixed, so I worry such a warning will reduce the effectiveness of the audit tool if it is always reported.