Tracking cbits in the hackage ecosystem

[hasufell]

Following https://github.com/haskell/security-advisories/pull/157 I think it's clear that bundled c sources are an issue.

I've been advocating against it for a long time, but there are cases where the alternative is basically leaving the end user alone with compiling a system library from source. Further discussion happened here https://discourse.haskell.org/t/haskell-cryptography-group-botan-the-first-milestone/9018/11

I think the least worst option is to create packages like bzip2-clib that do nothing but install headers and allow linking against the upstream code with no Haskell pieces whatsoever. These can be more easily tracked and shared maintenance is not an issue.

What should the sec team do here? I think there are three potential missions:

• publish recommendations for package maintainers (including the cbits topic)
• create tools to track such pure cbits packages against upstream versions (which is easy, since the cbits version is corresponding to the upstream versions)
• have a list of packages that bundle cbits in non-pure ways (here it's hard to figure out if code is outdated or vulnerable)

[frasertweedale]

Thanks, these are all good suggestions. We will discuss it at the next SRT meeting and decide the priorities and next steps.