Libsodium-bindings-0.0.1.0 released

Announcements
#1

libsodium-bindings-0.0.1.0 released

The Haskell Cryptography Group is glad to announce the first public release of our low-level bindings to libsodium: @hackage/libsodium-bindings

We have made sure that this library is a minimal burden in your dependency tree, which is why it does not depend on anything other than base, which guarantees low friction when upgrading GHC.

This library intentionally implements an API close to the C interface, allowing higher-level libraries to implement APIs of their choosing. It powers the Group’s sel library, which is still undergoing usability testing before release.

The documentation has been designed to be as stand-alone as possible, and links to the libsodium documentation for each C entity exposed.

What is next?

The roadmap for this library is as follows:

  • Static bindings to libsodium: Platforms are usually not in sync when it comes to distributing new versions of system libraries, and libsodium does not escape this fact of life. Hence it would improve the user experience if they knew they could rely on libsodium-bindings to provide a version of the C library. This is particularly on-topic on macOS, where Homebrew has started shipping libsodium 1.0.19.

  • User experience on Windows: This platform is unfortunately left behind when it comes to user experience, and so we commit to take the usability of the library on Windows seriously.

Links

My personal thanks to every person who chimed in to make sure the documentation was of high quality.

21 Likes
#2

Wow, excellent news! Thank you to all contributors

2 Likes
#3

How high-level is the API? Are there any parts where secrets leak into the Haskell domain?

#4

@hasufell Thank you for asking. These bindings specifically are low-level, and mimic the C API (to an extent). Regarding secrets leaks, libsodium’s memory functions functions allow higher-level libraries like sel to process secrets in a less dangerous way. You will find a number of advice on this page, including disabling swap partitions (or having the partition encrypted).

In Sel, we have made the decision of using ForeignPtrs for the keys.

Tell me if this has not answered your question. :slight_smile:

2 Likes
#5

@Kleidukos how about “vendoring in” the C library, to avoid chasing platform-dependent quirks? Does the libsodium license allow it?

#6

That is a can of worms.

Now random haskell binaries you installed may be vulnerable and you have to figure out which yourself (and it’s not necessarily version dependent either… it depends how the binary was built).

#7

… provided the version you are using has a vulnerability that’s serious enough to need an update, that is? And, isn’t this the packaging model used e.g by sqlite so with analogous problems?
A vendored libsodium-hs could use the same versioning scheme as libsodium, to let users know what they are using.

#8

Yes, static linking is for people who know what they’re doing and shouldn’t be encouraged.

#9

Please help me understand. The (current) alternative pushes the burden of security updates to the users. How can you assume all users of a low-level cryptography library have the same security awareness?

#10

No, it usually pushes it to the Distro/Operating system, which have mechanisms for updates and more resources.

2 Likes
#11

Yes that’s part of the “static bindings” roadmap. This would be implemented as a flag that the application user would switch “on” if they wished to use the bundled version. But we still want to play nice with bazel, nix, etc, so we also let the build environment provide their libsodium 1.0.18

2 Likes