Botan bindings devlog

Whew! I needed a few days respite after last week’s writing and editing, to keep my health up.

arybczak:

Thanks for continual improvement of Haskell cryptography story

Vlix:

Also, thanks for still going at it and writing these lovely reports. It’s always a pleasure to read.

arybczak:

I suggest unconditionally including boot dependencies of GHC (i.e. ones that always get installed alongside it) to not make the work harder than it needs to be for yourself

I guess this is less important for botan than it is for memalloc. My rationale here is mostly consistency - it makes sense for memalloc because ideally it shouldn’t depend on eg ghc or bytestring , but rather they should depend on it - perhaps one day

The dependency control flags are all true by default and require turning off manually, so they aren’t unsafe, plus:

• It helps me to organize the code
• I can turn things on and off during feature development
• It helps locate / localize problems
• Better support for non-GHC compilers

But botan does not follow this, it is a genuine downstream dependent, so I suppose it does not have the same needs. Right now I’m just seeing how they feel, but I shall ponder this. The flags do provide value in a holistic context, eg considering it as part of a set of interacting libraries, and they make it easy to control the set consistently.

Vlix:

I would also love to see the memalloc library. Does it have an extensive test suite? It feels like such a fundamental library that it should really be as robust as can be.

You’ve sort of hit it dead on - it needs more tests before I’m comfortable declaring ‘release’ or putting it up on ‘hackage’, but I’ll be getting the memalloc repo and the botan-low-refactor branch up soon so everyone can clone, use a cabal.project.local for the local repo, and build it themselves.

Vlix:

And another question: do you think a higher level botan package would even be needed if botan-low will get higher level concept types and convenience functions?

Actually, yes! I was wondering myself if I would need to rename botan-low to botan if I’m consolidating / moving all the high-level stuff down to it, but it turns out that it still makes sense to have a high-level botan, because it is an optimal place for per-algorithm data types and cryptographic typeclasses.

This lets botan-low continue to get away with using a simple single eg HashType data type of which eg SHA3 is a constructor, while botan will have a Hash(Algorithm) class, of which eg, SHA3 is a data type that is an instance of Hash(Algorithm).

The cryptographic typeclasses themselves will probably be in a separate cryptographic library explicitly for cryptographic abstractions, of which botan will implement instances - similar to how I pulled out the memory abstractions in memalloc