Sverker Eriksson

@xadhoom said > Looking into https://github.com/erlang/otp/blob/OTP-26.2.5.4/lib/crypto/c_src/algorithms.c#L236 > > Is ok that ther're a couple of return in a `enif_mutex_lock`'ed routine without a corresponding unlock before? Not an expert in otp...

This bug exists only in OTP-26.2.5.4. It's a race. It can only happen the first time `crypto:supports()` or `crypto:supports(curves)` is called and get called by two (or more) Erlang processes...

Fix #8979 queued up for next OTP 26.2.5.* patch release.

> Also usage of Ed448 curve is approved for digital signatures by FIPS 140-3 (unlike 140-2) but OTP still says `"Unsupported algorithm in FIPS mode"` I did a quick commit...

I would prefer if the authority of what algorithms that OpenSSL supports would be OpenSSL (FIPS or not). Such that OTP `crypto` could query OpenSSL and present the result upwards...

There are a bunch of failing test cases in [qlc_SUITE](https://erlang.github.io/prs/7042/ct_logs/[email protected]_15.44.32/make_test_dir.stdlib_test.logs/run.2023-04-03_15.45.27/suite.log.html) They seem to be triggered by this PR, but I haven't investigated further.

I don't think I will get time to really scrutinize the implementation, but the amount of test cases looks reassuring. It would be nice if you could write something in...

Reading your [post at erlang forums](https://erlangforums.com/t/ets-queries-with-keys-which-look-like-meta-variables/2946) maybe you also realized this cannot be optimized correctly: ``` 1> ets:fun2ms(fun({K,V}) when V =:= '$1' -> K end). [{{'$1',{const,'$1'}},[],['$1']}] ``` I also discovered...