potatosalad/erlang-jose

mix deps.compile jose error since 1.10 release

Closed this issue · 13 comments

ed-vazquez commented

mix.deps get and compile failing for version 1.10
Issue did not occur using 1.8

Compiling 105 files (.erl)
src/jwk/jose_jwk_pem.erl:82: undefined macro 'id-aes256-CBC'
src/jwk/jose_jwk_pem.erl:20: function to_binary/3 undefined
src/jwk/jose_jwk_der.erl:58: undefined macro 'id-aes256-CBC'
src/jwk/jose_jwk_der.erl:18: function to_binary/3 undefined

I am unsure if related to external factors.

using
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]
Elixir 1.9.0 (compiled with Erlang/OTP 22)

pedrorossato commented

I`m with the same error here. Waiting for help.

  • 👍4
mazz commented

Getting the same issue. I have an umbrella app and in the "root" mix.exs I put:
{:jose, "~> 1.9", override: true}
which seemed to get me up-and-running.
** UPDATE **
Sorry, I misspoke. The above does not help.

However, after running mix deps.get I manually edited the mix.lock file from:

"jose": {:hex, :jose, "1.10.0", "4167c5f6d06ffaebffd15cdb8da61a108445ef5e85ab8f5a7ad926fdf3ada154", [:mix, :rebar3], [{:base64url, "~> 0.0.1", [hex: :base64url, repo: "hexpm", optional: false]}], "hexpm"},

to:

"jose": {:hex, :jose, "1.9.0", "4167c5f6d06ffaebffd15cdb8da61a108445ef5e85ab8f5a7ad926fdf3ada154", [:mix, :rebar3], [{:base64url, "~> 0.0.1", [hex: :base64url, repo: "hexpm", optional: false]}], "hexpm"},

FrancisMurilloDigix commented

@mazz Have you tried just {:jose, "~> 1.9.0", override: true}, the ~> will look for the next minor version available instead of just the build/patch number by adding the extra .0? Have the same problem and the fix above works for now.

markupguy commented

Getting the same with a fresh Phoenix install. I added Guardian which has the jose dependancy. Unfortunately none of the above fixes have worked for me thus far.

Edit: Looks like hand editing the mix.lock to 1.9.0 does the trick as per @mazz

ed-vazquez commented
  • ❤️1
victorolinasc commented

Passing {:jose, "~> 1.9.0", override: true} or {:jose, "== 1.9.0"} and running:

mix deps.unlock jose
mix deps.get jose
mix deps.compile jose

Works :)

mazz commented

@FrancisMurilloDigix

Will try the .0 thanks

@mazz Have you tried just {:jose, "~> 1.9.0", override: true}, the ~> will look for the next minor version available instead of just the build/patch number by adding the extra .0? Have the same problem and the fix above works for now.

tonight-halfmoon commented

it requires: elixir 1.9.4 and Erlang to be as younger as/than 22.1

  • 👍1
potatosalad commented

Really odd, I haven't been able to reproduce this behavior locally with either of the following setups:

  1. Erlang/OTP 22.1.8, Elixir 1.9.0
  2. Erlang/OTP 22.2.1, Elixir 1.9.4

This sounds like it's a minimum OTP version number problem where OTP 22.1 might be the new minimum requirement in order to support the new cryptographic operations (specifically, the switch from default PEM encryption from DES3 to AES-256-CBC).

erts-10.4.4 would mean OTP-22.0.{5,6,7}, so I'll do some more tests with that version and report back.

potatosalad commented

It looks as though there was a moderate change between crypto-4.5 and crypto-4.6 as well as public_key-1.6 and public-key-1.7 (see the version table) which corresponds with OTP-22.0 and OTP-22.1.

I'll see if I can get a compatibility fix put together for a version 1.10.1 release.

potatosalad commented

To make things even more confusing, OTP-21.3.8.11 works fine.

So, somewhere between OTP-21 and OTP-22, some of the public key macros appear to have been messed up.

mazz commented

From memory, I am using otp 22.0.7/elixir 1.9.1 if that helps. I installed elixir 1.10-rc0 and plan to upgrade to latest otp.

It looks as though there was a moderate change between crypto-4.5 and crypto-4.6 as well as public_key-1.6 and public-key-1.7 (see the version table) which corresponds with OTP-22.0 and OTP-22.1.

I'll see if I can get a compatibility fix put together for a version 1.10.1 release.

potatosalad commented

The compilation error should no longer occur as of jose version 1.10.1.

There are some slight differences between the way PEM and DER formats will be generated between OTP 20, 21, and 22, but hopefully the compatibility layer I added will help smooth things over during the transition.

Thanks to everyone who reported this!

  • 👍3