towards a release

[hannesm]

Below is a draft plan of "what we should do before an initial release". Let us please discuss if there are items missing from the list, or whether some of the items should be skipped for a release.

The set of changes we should aim for an initial release are in my opinion:

• decide on the main module name (being it Mirage_crypto or just Crypto)? It'll be Mirage_crypto.
• finish renaming of the library (best case: have nocrypto and mirage-crypto coinstallable / colinkable (requires distinct C symbols as well)
• port to dune (there's earlier work, https://github.com/mirleft/ocaml-nocrypto/tree/dune is a fine start imho) see compilation fixes #4
• get freestanding + xen support back (see https://github.com/dinosaure/ocaml-nocrypto/commits/dune and https://github.com/hannesm/ocaml-nocrypto/commits/awa-future) -- for now not using variants (i.e. stay compatible with mirage 3.7) see compilation fixes #4
• revert the "remove sexp" commit a58c653 (if desired we can remove the sexp conversions at a later stage, but e.g. TLS uses them) see compilation fixes #4
• address the various security things, see security issues from nocrypto repository #3
• setup maintainership and code review guidelines for this repository (approval is required for PRs, maintainers have write permission now, CI for linux & macOS & FreeBSD are in place)
• spread into multiple packages -- the main motivation is to separate the stuff depending on the pretty big zarith / libgmp (asymmetric crypto) to allow Fortuna (the PRNG) being used by all MirageOS unikernels (see https://github.com/hannesm/ocaml-nocrypto/commits/split for an initial attempt) -- this can as well be a good preparation for reducing the overlap between crypto and digestif -- see also https://github.com/mirleft/ocaml-nocrypto/commits/breakage
• ensure mirage-crypto-* works for reverse dependencies of nocrypto

at some later point, we should:

• write microbenchmarks and run with released versions (and openssl) as baseline, to evaluate potential performance regression before a release
• discuss the underlying storage data structure (atm Cstruct.t, digestif uses String/Bytes/Bigarray)
• de-duplicate the hash implementations between crypto and digestif
• define (or revise) a DH interface (so fiat and x25519 and this FFDHE can share the same module type) -- imho these libraries should be integrated into this repository as well
• define an AEAD interface (so CCM/GCM/potentially poly1305/Chacha20 can share it)
• remove the compile-time CPU feature detection (using cpuid), instead defer to runtime CPU detection (without performance regression, i.e. only do it once, not on every call to AES)

[dinosaure]

revert the "remove sexp" commit a58c653 (if desired we can remove the sexp conversions at a later stage, but e.g. TLS uses them)

I'm not in favor to completely revert remove sexp where ocaml-tls uses few sexp converters (this what I did on my side to keep the compatibility with tls.0.10.5)

Then, it seems to be a good plan 👍.

[hannesm]

I'm not in favor to completely revert remove sexp

as discussed earlier, I'm all for an all-or-nothing approach. I've to look through revdeps what else uses the sexp serialisers. in the end, I think most cryptographic material can be expressed in PKCS* / pem, and there's no need for sexp-serialisers. But a "partial revert" is IMHO more churn than necessary.

in order to stage the changes through, it would be nice if others could join the discussion (about s-expressions, but also about the list of tasks above). to get the ball rolling, would it be possible to enable the ocaml-ci for this repository? and is anyone against bumping the lower ocaml bound to 4.05.0 (which is the one in debian-stable, and FreeBSD) -- I'd as well be ok with using anything more recent as lower bound (please express your view on this as comment). thanks.

[talex5]

would it be possible to enable the ocaml-ci for this repository?

Not easily, because it's private and so the CI can't access it (git clone) fails.

[avsm]

I'll open source it to facilitate the CI. Regarding the above, I'm in favour of all of them, but I suggest that we first do:

• module change (Crypto sounds fine)
• coinstallability with Nocrypto
• port to dune
• freestanding + xen
• revert sexp removal (fully)
• setup maintainership and code review guidelines for this repository

If we can release this first and a TLS release which ports to dune, then it will be much easier to perform the rest of the work for TLS 1.3 and digestif integration and fortuna separation asynchronously on top of those releases. Right now we are interlocked on a simultaneous code and build system change.

[hannesm]

@avsm ok, that sounds fine with me. I'll work on the PR (and test locally) addressing these changes this week.

[avsm]

repository is now open so ocaml-ci should be activatable on this.

[talex5]

ocaml-ci is now enabled (doesn't work on master due to the old-style opam file name, but it's building on the more branch).

[hannesm]

If we can release this first and a TLS release which ports to dune, then it will be much easier to perform the rest of the work for TLS 1.3 and digestif integration and fortuna separation asynchronously on top of those releases.

This does not match the plan I have in mind. I want to avoid yet another rebase of the TLS 1.3 branch (did that recently, it is painful). So my plan ahead is to get this package into a nice shape, then get TLS 1.3 branch merged (after further reviews and testing), and then finally use mirage-crypto in TLS and port TLS to dune. Once we're there, we can release TLS (with 1.3, mirage-crypto, and dune). :)