On Thu, 5 Mar 2026, Viktor Dukhovni wrote:

...

On 5 Mar 2026, at 6:21 pm, Henning Thielemann wrote:

The use_crypton flag is declared to be manual. I think this is the problem, it should be automatic.

Yes, that's one of the potential obstacles, but making automatic does not help. The solver does not see the conflict, even if `tsl` declares `conflicts: cryptonite`, and the flag is automatic.

What is `conflicts: cryptonite`? A Cabal package description field? I do not see it in Cabal-3.16 docs.

On Thu, 5 Mar 2026, Viktor Dukhovni wrote:

On Thu, Mar 05, 2026 at 08:44:25AM +0100, Henning Thielemann wrote:

...

...

Yes, that's one of the potential obstacles, but making automatic does not help. The solver does not see the conflict, even if `tsl` declares `conflicts: cryptonite`, and the flag is automatic.

What is `conflicts: cryptonite`? A Cabal package description field? I do not see it in Cabal-3.16 docs.

AI hallucination apparently. I was on a plane with spotty Wifi, and tried to make to with bad advice from Gemini. So it seems there isn't any practical way to express that `tls` **requires** the `use_crypton` flag in `mlkem` not only in its own build, but also when built as a dependency of other packages. :-(

Ok, I see why the automatic flag does not solve the problem: In terms of package dependencies there is no conflict for Cabal between `crypton` and `cryptonite` and thus it chooses both of them. So, Cabal would actually need something like a "conflicts" field in the package description.

On Thu, Mar 05, 2026 at 12:48:58PM +0100, Henning Thielemann wrote:

...

The general principle (albeit one that is not necessarily widely understood or well advertised) is that package APIs should not depend on flag assignments, for precisely the reason you outline:

I think that condition is satisfied here: The API of tls is independent from whether mlkem calls crypton or cryponite.

So in principle things should work if `tls` uses `crypton`, and `mlkem` uses `cryptonite`, as Cabal might choose as default.

Sadly, things don't turn out that way. Various functions in the MLKEM API carry type class constraints like `MonadRandom r`, ... where the MonadRandom in question is either the one from `cryptonite` or `crypton`, and so not the same API as far as the type system is concerned. In paricular, when `tls` (using `crypton`) tries to provide a `MonadRandom r`, it is the *wrong* one when `mlkem` is built with `cryptonite` and the code fails to compile. Bottom line, the two variants of `mlkem` don't end up offering the same API (distinct type signatures, that only look the same). So either forking `mlkem` or a major version bump seem to be the sensible choices. I hope Olivier can be convinced to go the version bump route. -- Viktor. 🇺🇦 Слава Україні!

It used to be, but cryptonite has been unmaintained for a couple of years now and that's somewhat bad for a security-related package. On Thu, Mar 5, 2026 at 2:55 PM Roland Lutz wrote:

On Fri, 6 Mar 2026, Viktor Dukhovni wrote:

...

Bottom line, the two variants of `mlkem` don't end up offering the same API (distinct type signatures, that only look the same).

Isn't this exactly what Backpack modules are for? If `mlkem` and `tls` imported a signature for `crypton`/`cryptonite`, depending on either of these should have `mlkem` and `tls` use the correct version of the API.

I'm not sure what to make of "somewhat experimental", though: https://cabal.readthedocs.io/en/stable/how-to-use-backpack.html

It may already have been considered, but wouldn't making `tls` compatible with `cryptonite` solve the issue, too?

_______________________________________________ Haskell-Cafe mailing list -- haskell-cafe@haskell.org To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com