Haskell security tooling integrations

[blackheaven]

It's not a limited proposal, I hope some discussion will take place around our needs and blind spots we may have.

edit: rendered https://github.com/blackheaven/tech-proposals/blob/0e8cd229e88614162db565cc07350ecda55d182e/proposals/0000-haskell-security-tooling-integrations.md

[hasufell]

I think making security information accessible is an important goal.

What I'm not sure about is whether:

1. integrating cabal-audit into cabal
2. extending Cabal-syntax

is the right way to go.

For 1. we have cabal's external command system: https://cabal.readthedocs.io/en/stable/external-commands.html and distributors (such as ghcup) are free to bundle other tools. I don't see that as a complicated problem, but it may require us to improve certain interfaces in cabal (which is good).

Point 2. is quite delicate. Once syntax is added, it's hard to ever get rid of it. I'm also not entirely sure why the security vulnerability data has to live in the .cabal files. Revisions are also not a very good mechanism in general (now you rely on people updating the hackage index, etc.). Adding security vulnerability database info to cabal.project also seems kinda odd... why would you want to do this per project? Seems like something you'd rather do globally, e.g. because you're in a bank environment.

I think we should be able to provide an out-of-the-box experience without moving all that functionality into cabal.

[MangoIV]

I strongly agree that it would be great to have security advisory information be more prominently accessible in general and part of the usual workflow of application and package maintainers.
However, I agree with Julian in that I don't know if the way we reach it is to move more functionality into tools.
For cabal, I think the external command system is sufficient. E.g. in newer cabal-install versions it should already work out of the box with cabal-audit.
Wrt hackage I just don't know the status quo well enough. I think there's an on-going tech proposal about improving hackage. Depending on the outcome of that, hackage could surely be extended to display available information if the result is a more maintainable codebase whose extension is feasible? Otherwise I'm also aware that flora and its author @Hecate have been planning to publish advisory data on their platform.
Wrt extending the cabal stanza -- maybe this would be feasible, but I don't see the use. If something like cabal-audit was already available, it would already be able to directly query the security advisories database. If it wasn't, then discovery would be just as bad as previously as people rarely read the cabal files of their dependencies. Additionally, it doesn't replace having to report the actual vulnerability upstream (and I also think that would be an outright bad idea).
I think the most important thing that I do miss here is the check of what kind of needs large codebases actually have. For instance, I am not aware who is even using cabal-audit (or the security advisories database) today and who wants to / needs to use it.
For instance at $previous_workplace I just collected software bill of materials by traversing the nix closure of the product and then we let some third party tool do some fuzzy matching on the resulting information -- I.e. we didn't do anything haskell specific at all.
I think that would be important information to justify which improvements to tools would actually be useful.

[gbaz]

I do think that extending hackage with this data would be a good thing, bearing in mind other efforts on the hackage codebase that may affect when and how it makes sense to implement this.

On a cabal command vs plugin, I do worry that extending the cabal executable rather than using plugins will further bloat an already very complicated codebase. If there are significant advantages to integration that's reasonable (or if there's a long-term accepted plan to integrate security information with existing cabal commands). However, if the desired interaction is effectively the same with a plugin model, I'd urge the plugin model be kept for now.

And finally, I agree with others that extending the .cabal syntax itself would be a mistake. The purpose of a cabal file is specifically to provide information necessary to install and run a package, and despite revisions is intended to be basically fixed at uploadtime. Revisions are to update the information necessary to install and run a package. Other metadata about a package can be kept elsewhere in the ecosystem. Since one presumes a new upload of a new version of a package would be typically security advisory free, having data intended to go into cabal files only via revisions seems to be a distortion of their purpose.

Further, since the data about security advisories is already kept in the security advisory database, this would create a competing, and probably imperfect second source of truth. Much better to have a single reliable source that everything can use than two sources, one of which is less reliable.

If the goal is to improve usage of security advisory data, I might want to take a step back and ask how significant projects already do security advisory audits. Do they have tools for that already that work over other portions of their codebase? Would it be possible instead to ensure those tools work well with the haskell ones?

[blackheaven]

Thanks for your feed-backs, I fully agree, I have narrowed down the proposal.