From a quick glance: I think it might be a bit misleading to present sel as “bindings to libsodium”. It seems to be a fine “cryptography toolkit for the unsuspecting developer”, but if you approach it with the expectation of finding all the familiar libsodium functionality wrapped in straightforward Haskell, then this is not it (but libsodium-bindings looks like it would be).
Also, though I’m not 100% sure whether this warrants any action, sel does not explicitly address the mlocking issues it inherits from libsodium. The issue, specifically, is that sodium_malloc() will attempt to mlock any memory it allocates, but if it fails, it will silently carry on without mlocking. For many applications this is perfectly acceptable, but when you rely on secret keys never being written out to disk, or when your swap volumes are not encrypted (for whatever reasons), this can be a problem. Libsodium itself recommends calling sodium_mlock() explicitly in such cases, but doing so uncritically can lead to other problems, especially when, like sel does, you rely on finalizers and GC to deallocate your keys, because quota on mlocked memory tend to be pretty strict, and you can easily overrun those.
For a turn-key-don’t-make-me-think-about-cryptography library like sel, this is of course a conundrum - if you want to offer users a “just works” experience, you can’t mlock everything uncritically, but that also means you will not be able to offer adequate security for some use cases. Personally, I would consider at least warning about this in the documentation.
