The current developer (not the original author) of crypton and tls states that "I am not a cryptography expert, so I cannot write code that is both correct and performant." This begs the question: Does anyone understand and has anyone reviewed the LLM generated code that they are pouring into these libraries?

The point of cryptonite was to package up industry standard C implementations of crypto functions in haskell. This is no longer that, and as such, does not seem like a trustworthly package to use.

The point of the tls library is well, to be secure. It seems doubtful that the haskell tls library is better than standard tls libraries like openssl at this point in time.

I have lost confidence in the maintenance of these, and would like git-annex to migrate away from depending on them. --Joey

This is separate, though obviously not entirely disconnected from no LLM code.

Here is a plan:

  • Switch git-annex to botan for hash functions. There is already a build flag, but it would be easier if botan bundled the C library in the haskell package. Which they have considered doing.
    The botan-default branch makes the switch, but is blocked on needing a way to install botan on windows. cross compiling with MinGW may be needed, unless a prebuilt release can be found.
  • botan lacks skein and blake2, so would need to get those hashes another way
  • Switch from http-client-tls to http-client-openssl.
  • Switch from warp-tls to warp-s2n-tls? Alternatively, warp-tls is only used by the webapp and p2phttp; the webapp is mostly used on localhost and p2phttp is often used behind a server (eg forgejo) that can handle the https if it only supported http.
  • aws depends on http-client-tls, but only uses it in its test suite; the library uses the Manager that the user passes in. So it would be possible to depend on aws w/o getting http-client-tls as a dependency, except it has a gratuitous dependency on it in the Library stanza of the cabal file. Easily fixed.
  • Avoid DAV depending on http-client-tls, by passing a Manager to mkDAVContext. (The context can be updated after the fact to use a http-client-tls manager, but it still uses http-client-tls first to make one.)