mix deps.compile jose error since 1.10 release

[ed-vazquez]

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]

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

[mazz]

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]

@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]

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]

Hi Ruan, I had the same issue because of guardian. The workaround was to lock the jose version by putting {:jose, "1.8.0"} as the first dependency in mix.ex. then clean and repull your deps. Ed

…

On Mon, Jan 6, 2020 at 2:21 AM Ruan Zeelie ***@***.***> wrote: 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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#82?email_source=notifications&email_token=AALVZVQBDEAIO4CQ3QF4HGTQ4LLXJA5CNFSM4KCXDC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEULOI#issuecomment-571033017>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALVZVVDG66KSLZA4SWVK53Q4LLXJANCNFSM4KCXDC2Q> .

[victorolinasc]

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]

@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]

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

[potatosalad]

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]

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]

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]

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]

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!