Cloak with changeset issue - (UndefinedFunctionError) function Cloak.EncryptedBinaryField.equal?/2 is undefined or private

Questions / Help
, ,
1

Hi All,

I am using Cloak 0.6.2 version. It was working all good. I upgraded the Elixir version to Elixir 1.13.0, Phoenix - 1.5.9 and phoenix_pubsub : 2.0.
After upgrading, I am getting the following error

  • (exit) an exception was raised:
    ** (UndefinedFunctionError) function Cloak.EncryptedBinaryField.equal?/2 is undefined or private
    (cloak 0.6.2) Cloak.EncryptedBinaryField.equal?(nil, “Basement Flat, 2 Barons Court Road”)
    (ecto 3.7.2) lib/ecto/changeset.ex:576: Ecto.Changeset.cast_field/8

I am passing the changeset in this way
struct

|> cast(
  upcase(params, [:current_address_postcode]),
  ~w[
         current_address_street current_address_locality current_address_county
         current_address_postcode current_address_udprn
       ]a
)

It was working all good previously, now it is throwing error.
Any help to fix this, would be highly appreciated.

Thanks,
Santosh T

1 Like
2

That version of Cloak is too outdated to work with the current version of Ecto - the semantics of Ecto.Type changed to require that equals? function in Add use Ecto.Type · elixir-ecto/ecto@c040b7c · GitHub

This issue suggests you’ll want to upgrade to at least Cloak 1.1.0:

3 Likes
3

Thanks for the reply. I can update the version, but should we have to migrate the old existing encrypted data as well? Will it have a huge impact? Bit concerned about the Production data.

4

I don’t think you need any data migration. An encrypted value has all the details of the cipher that was used for encryption.

2 Likes
5

I have upgraded to cloak_ecto, it is failing to load the previous data.
** (ArgumentError) cannot load <<65, 69, 83, 1, 225, 62, 249, 49, 101, 202, 45, 28, 221, 3, 238, 254, 112, 32, 115, 255, 128, 10, 119, 251, 104, 191, 116, 53, 199, 229, 23, 108, 129, 178>> as type MyApp.Encrypted.Binary for field :phone_number in %MyApp.Profile{meta: #Ecto.Schema.Metadata<:loaded, “profiles”>,
Data migration is also not possible.

6

What is the previous and the current version? Can you share your Cloak config (skipping the encryption key, obviously)?

1 Like
7

Previously it was Cloak 0.6.2. I upgraded to cloak_ecto 1.0
previously
config :cloak, Cloak.AES.CTR,

tag: “AES”,

default: true,

keys: [

%{tag: <<1>>, key: :base64.decode(<cloak_key_1>), default: true}

]

After update

config :m

y_future_now, MyFutureNow.Vault,

   ciphers: [

     default: {

       Cloak.AES.CTR,

       tag: "AES",

      key: Base.decode64!(cloak_key_1),

       # In AES.GCM, it is important to specify 12-byte IV length for

       # interoperability with other encryption software. See this GitHub

       # issue for more details:

       # https://github.com/danielberkompas/cloak/issues/93

       #

       # In Cloak 2.0, this will be the default iv length for AES.GCM.

        iv_length: 12

#     }

#   ]

I will try with key: :base64.decode(cloak_key_1) for now in upgraded

8

Can you also please check the previous and current version of cloak? You should be able to see it in the mix.lock file.

Just to make sure: previously were you using cloak directly or via cloak_ecto?

9

I was using cloak directly. Higher versions of cloak advises to use cloak_ecto
https://hexdocs.pm/cloak/0-9-x_to_1-0-x.html#content

10

Sorry for giving you a confusing advice. Since you’re updating from a pretty old version of Cloak, I think you should follow the upgrade guide and perform each minor version upgrade step by step, that is upgrade 0.6 to 0.7, 0.7 to. 0.8, etc. until you migrate to the latest one.

https://hexdocs.pm/cloak/0-6-x_to_0-7-x.html

As you can see in the guide, this indeed will require a data migration.

1 Like
11

Like @stefanchrobot suggests, you’ll need to upgrade cloak incrementally to catch up. You’ll also need to do this before changing your Ecto etc version, as vintage cloaks are not compatible with current Ecto.

1 Like
12

@stefanchrobot @al2o3cr I did the same thing of incrementing it step by step.
It did not work then as well.

However there was a data migration when we upgrade it from 0.6 to 0.7, which I did not perform.
As I did not have much time, I would look into this later.

Thanks for the valuable suggestions.