Tracking cbits in the hackage ecosystem

[hasufell]

Following #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.

[jeannekamikaze]

leaving the end user alone with compiling a system library from source.

And if you intend to target anything other than Linux, this is kind of hopeless.
I think we should strive to make things as simple as cabal install package on all platforms, which is especially useful in books and teaching environments, and generally lowers the barrier to entry.

which is easy, since the cbits version is corresponding to the upstream versions

Would this be part of the recommendations? Most of the C bindings I have used do not follow this convention, which makes things hard to understand in general, security advisories aside. As far as I know there is also no way to enforce this convention?

that do nothing but install headers and allow linking against the upstream code with no Haskell pieces whatsoever

I like this also because it leaves it up to the user or a separate package to decide how to write the bindings. Some packages deviate from the "raw" binding style and are instead rather opinionated, which then makes them overall not as useful.

[hasufell]

Would this be part of the recommendations? Most of the C bindings I have used do not follow this convention, which makes things hard to understand in general, security advisories aside. As far as I know there is also no way to enforce this convention?

The foo-clib packages are not bindings. They are C libraries, which you can use to link bindings against. So we are essentially packaging c libraries for cabal.