Thank you! 🎉

With elixir v1.12 on OTP v24.0.1 I have the following issue:

iex(2)> :erlang.system_info(:otp_release)
'24'
iex(3)> jwk = JOSE.JWK.from(%{"k" => "STlqtIOhWJjoVnYjUjxFLZ6oN1oB70QARGSTWQ_5XgM", "kty" => "oct"})                   %JOSE.JWK{
  fields: %{},
  keys: :undefined,
  kty: {:jose_jwk_kty_oct,
   <<73, 57, 106, 180, 131, 161, 88, 152, 232, 86, 118, 35, 82, 60, 69, 45, 158,
     168, 55, 90, 1, 239, 68, 0, 68, 100, 147, 89, 15, 249, 94, 3>>}
}
iex(4)> JOSE.JWE.block_decrypt(jwk, "eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..jBt5tTa1Q0N3uFPEkf30MQ.Ei49MvTLLje7bsZ5EZCZMA.gMWOAmhZSq9ksHCZm6VSoA")
** (UndefinedFunctionError) function :crypto.block_decrypt/4 is undefined or private, use crypto:crypto_one_time/5, crypto:crypto_one_time_aead/6,7 or crypto:crypto_(dyn_iv)?_init + crypto:crypto_(dyn_iv)?_update + crypto:crypto_final instead
    (crypto 5.0.1) :crypto.block_decrypt(:aes_cbc, <<158, 168, 55, 90, 1, 239, 68, 0, 68, 100, 147, 89, 15, 249, 94, 3>>, <<140, 27, 121, 181, 54, 181, 67, 67, 119, 184, 83, 196, 145, 253, 244, 49>>, <<18, 46, 61, 50, 244, 203, 46, 55, 187, 110, 198, 121, 17, 144, 153, 48>>)
    (jose 1.11.1) src/jwe/jose_jwe_enc_aes.erl:167: :jose_jwe_enc_aes.block_decrypt/4
    (jose 1.11.1) src/jwe/jose_jwe.erl:198: :jose_jwe.block_decrypt/2
    (jose 1.11.1) lib/jose/jwe.ex:470: JOSE.JWE.block_decrypt/2
iex(4)>

I deleted deps/ and _build, fetched everything new, tried erlang-jose v1.11.1 and master. Is there something wrong with my setup?

https://github.com/alappe/jose_otp24 shows the issue:

$ elixir -v
Erlang/OTP 23 [erts-11.1.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

Elixir 1.11.2 (compiled with Erlang/OTP 21)
$ mix test                                                                                                                                                                                          13:43
==> jose
Compiling 106 files (.erl)
Compiling 8 files (.ex)
Generated jose app
==> jason
Compiling 8 files (.ex)
Generated jason app
==> jose_otp24
Compiling 1 file (.ex)
Generated jose_otp24 app
..

Finished in 0.04 seconds
1 doctest, 1 test, 0 failures

Randomized with seed 689982
$ 

$ asdf install
elixir 1.12.0 is already installed
erlang 24.0.1 is already installed
nodejs 14.17.0 is already installed

$ elixir -v
Erlang/OTP 24 [erts-12.0.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]

Elixir 1.12.0 (compiled with Erlang/OTP 22)
$ mix test
==> jose
Compiling 106 files (.erl)
Compiling 8 files (.ex)
Generated jose app
==> jason
Compiling 8 files (.ex)
Generated jason app
==> jose_otp24
Compiling 1 file (.ex)
Generated jose_otp24 app


  1) test block_decrypt (JoseOtp24Test)
     test/jose_otp24_test.exs:5
     ** (UndefinedFunctionError) function :crypto.block_decrypt/4 is undefined or private, use crypto:crypto_one_time/5, crypto:crypto_one_time_aead/6,7 or crypto:crypto_(dyn_iv)?_init + crypto:crypto_(dyn_iv)?_update + crypto:crypto_final instead
     code: JOSE.JWE.block_decrypt(
     stacktrace:
       (crypto 5.0.1) :crypto.block_decrypt(:aes_cbc, <<158, 168, 55, 90, 1, 239, 68, 0, 68, 100, 147, 89, 15, 249, 94, 3>>, <<140, 27, 121, 181, 54, 181, 67, 67, 119, 184, 83, 196, 145, 253, 244, 49>>, <<18, 46, 61, 50, 244, 203, 46, 55, 187, 110, 198, 121, 17, 144, 153, 48>>)
       (jose 1.11.1) src/jwe/jose_jwe_enc_aes.erl:167: :jose_jwe_enc_aes.block_decrypt/4
       (jose 1.11.1) src/jwe/jose_jwe.erl:198: :jose_jwe.block_decrypt/2
       (jose 1.11.1) lib/jose/jwe.ex:470: JOSE.JWE.block_decrypt/2
       test/jose_otp24_test.exs:9: (test)

.

Finished in 0.04 seconds (0.00s async, 0.04s sync)
1 doctest, 1 test, 1 failure

Randomized with seed 783367
$

Probably unrelated, but I cannot compile the project to run the tests, mix test fails with

…
 C      libsodium_api.c
In file included from /project/deps/jose/deps/libsodium/c_src/libsodium_api.c:4:
In file included from /project/deps/jose/deps/libsodium/c_src/libsodium_api.h:7:
/project/deps/jose/deps/libsodium/c_src/libsodium_drv_common.h:9:10: fatal error: 'erl_interface.h' file not found
#include <erl_interface.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.
make: *** [/project/deps/jose/deps/libsodium/c_src/libsodium_api.o] Error 1
===> Hook for compile failed!

** (Mix) Could not compile dependency :libsodium, "/Users/nd/.asdf/installs/elixir/1.12.0/.mix/rebar3 bare compile --paths /project/deps/jose/_build/test/lib/*/ebin" command failed. You can recompile this dependency with "mix deps.compile libsodium", update it with "mix deps.update libsodium" or clean it with "mix deps.clean libsodium"

The block_decrypt API was deprecated in Erlang 23 and removed in 24. This provides Erlang 24 compatibility.

Thank you! 💜

#118 is now ready to go

The remaining failures stem from jose_public_key:der_decode(AlicePrivateDER). behaving differently based on the erlang version, for the same value of AlicePrivateDER (<<48,46,2,1,0,48,5,6,3,43,101,112,4,34,4,32,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>).

The failures in fact match the added support for in Erlang 24. It appears to me that erlang-jose provided it's own implementation of these algorithms. My suspicion currently is that built in decoding now short circuits a fallback.

I've made some progress with #118 (which is still a draft), dropping the number of failures from 37 to 4. I hope to have the remaining 4 solved soon enough.

The block_decrypt API was deprecated in Erlang 23 and removed in 24. This provides Erlang 24 compatibility.

The easiest option for Erlang 22 users would be to use an older tag/branch.

Thank you for accepting this (fairly ugly) change which most users would not need. Our team is still determined to get Erlang 24 support over the finish line 👍

We produce eight or so package types, two Docker images (community and commercial), and there are projects that package RabbitMQ in ways we do not control. Most of package types are produced on Erlang 23. Docker images can afford to use 24. Packaging for Debian or Fedora uses the Erlang version currently provided by a specific release (and usually lags by 9-12 months, which is roughly one major release).

I wish we could support only one version and always develop and deploy on it. But it would never be possible for data services that users can packages, distribute and/or install in a wide variety of ways.

When this module is compiled on Erlang 23 but runs on 24, ECPrivateKey pattern matching fails due to that record having a different set of fields as of Erlang 24.

This PR assumes that to detect EC key mode it should be sufficient to only check one value. I could not think of a reason for private and public key to use different types in a single record.

Closes #113.

Attempting to start erlang-jose on OTP-24.0 raises a case clause error at src/jose_server.erl:189: :jose_server.check_ec_key_mode/2.

** (Mix) Could not start application jose: :jose_app.start(:normal, []) returned an error: shutdown: failed to start child: :jose_server
** (EXIT) an exception was raised:
    ** (CaseClauseError) no case clause matching: {:ECPrivateKey, 1, <<104, 152, 88, 12, 19, 82, 251, 156, 171, 31, 222, 207, 0, 76, 115, 88, 210, 229, 36, 106, 137, 192, 81, 153, 154, 254, 226, 38, 247, 70, 226, 157>>, {:namedCurve, {1, 2, 840, 10045, 3, 1, 7}}, <<4, 46, 75, 29, 46, 150, 77, 222, 40, 220, 159, 244, 193, 125, 18, 190, 254, 216, 38, 191, 11, 52, 115, 159, 213, 230, 77, 27, 131, 94, 17, 46, 21, 186, 71, 62, 36, 225, 0, 90, 21, 186, 235, 132, 152, ...>>, :asn1_NOVALUE}
  (jose 1.11.1) src/jose_server.erl:189: :jose_server.check_ec_key_mode/2
  (stdlib 3.15) lists.erl:1267: :lists.foldl/3
  (jose 1.11.1) src/jose_server.erl:153: :jose_server.support_check/0
  (jose 1.11.1) src/jose_server.erl:93: :jose_server.init/1
  (stdlib 3.15) gen_server.erl:423: :gen_server.init_it/2
  (stdlib 3.15) gen_server.erl:390: :gen_server.init_it/6
  (stdlib 3.15) proc_lib.erl:226: :proc_lib.init_p_do_apply/3

I think it worked fine on OTP-24.0-rc3. Perhaps fallout from the EDDSA work? https://github.com/erlang/otp/pull/4756

RabbitMQ supports N-1 latest Erlang release series. Some binary artifacts compile on Erlang 24 but we cannot build all of them on 24 as they obviously won't run on 23. So yes, this is an unfortunate reality for projects that distribute binary releases and cannot go all in on 24.

I assume then you provide a single binary release for all OTP versions you support? In my experience this is not advisable because of issues with records and other incompatibilities, but I also understand if you do not wish to add the extra maintenance of multiple releases.

Thank you for the PR!

We may be able to drop OTP 22, but ideally I think we should try to support more than just two versions, one of which was newly released.

I can't help you move this PR in particular forward because I am not a maintainer of this repo and do not have commit access.

Do you need to run code compiled with OTP 23 on OTP 24?

RabbitMQ supports N-1 latest Erlang release series. Some binary artifacts compile on Erlang 24 but we cannot build all of them on 24 as they obviously won't run on 23. So yes, this is an unfortunate reality for projects that distribute binary releases and cannot go all in on 24.

Maybe it depends on a binary release but mix test compiles this project from source and that fails.

Anyhow, team RabbitMQ would really like to avoid forking this library. What can we do to get things Erlang 24-ready across the board? The community is moving to 24 in large numbers, support of 22 or lower versions no longer seems to be important in comparison.

it is because this project cannot be built from source on Erlang 23+.

erlang-jose CI is passing on OTP 23.

Is this blocking getting erlang-jose to run OTP 24? It fails even when you run the tests on docker?

it is because this project cannot be built from source on Erlang 23+.

Thank you!

The captures the common test logs from failed runs as a workflow artifact, for convenience in inspecting failures

The captures the common test logs from failed runs as a workflow artifact, for convenience in inspecting failures