rabbitmqctl encode command fail during chipher operation

[guoard]

Describe the bug

The rabbitmqctl encode command encounters failure under certain conditions, such as when the encoded string begins with an uppercase letter or a number(when all of string is not number).

Reproduction steps

1. docker container run --rm -it rabbitmq:3.13.1 /bin/bash
2. rabbitmqctl encode Aa a or rabbitmqctl encode 3a a

Expected behavior

Anticipating an encrypted value but encountering this error instead:

Encrypting value ...
Error:
Error during cipher operation

Additional context

No response

[michaelklishin]

Different ciphers may have different limitations as to what are the input values they can accept.

You are welcome to investigate this further:

• rabbit_pbe is the module used by the encode command
• credentials-obfuscation is the library used by rabbit_pbe

This is open source software after all.

[michaelklishin]

A few more drive-by findings:

• The default cipher is aes_128_cbc, the list of supported ciphers with my Erlang/OTP build is listed below
• --print-stacktrace does not reveal any additional information because of a catch all clause in the command itself

Here are the supported ciphers:

[chacha20,aes_256_ofb,aes_192_ofb,aes_128_ofb,
 blowfish_ofb64,blowfish_cfb64,blowfish_cbc,des_cfb,des_cbc,
 rc4,rc2_cbc,aes_192_cbc,aes_256_cbc,aes_128_cfb128,
 aes_192_cfb128,aes_256_cfb128,aes_128_cfb8,aes_192_cfb8,
 aes_256_cfb8,aes_256_ctr,aes_192_ctr,aes_128_ctr,
 des_ede3_cfb,aes_128_cbc,des_ede3_cbc,aes_cbc,aes_cfb128,
 aes_cfb8,aes_ctr]

[michaelklishin]

And under underlying function is happy with a Capitalized value:

%% RABBITMQ_ALLOW_INPUT=1 ./sbin/rabbitmq-server
%% then drop into the node shell
rabbit_pbe:encrypt_term(rabbit_pbe:default_cipher(), rabbit_pbe:default_hash(), rabbit_pbe:default_iterations(), <<"Abc">>, <<"abc">>).
%% => {encrypted,<<"VBWZt9QbiEv6FRQ+gSPdHvWUE8xy7bwLMZgg8W4GtimyO1DXz4xhef+vVKRaBztx">>}

[michaelklishin]

:error
{:unbound_var, :Abc}

is the underlying error with an input of Abc. So the exception has nothing to do with rabbit_pbe.

[michaelklishin]

Relevant parts have been in place since 2016 5e16943 and 82036e0.

[michaelklishin]

So the value is parsed as an Erlang term, which allows you to encode arbitrary values but sadly, exposing the internals of Erlang data structures used.

# <<"Abc">> is an Erlang binary
rabbitmqctl encode '<<"Binary value to encode">>' '<<"pa$$phAs3">>' --print-stacktrace

works just fine because it does not interpret Abc as an unbound local ("variable").

Perhaps the command should by default assume that the value is a binary but that may or may not be a safe thing to ship in 3.13.x.

[michaelklishin]

It's a good question whether the docs should be updated or the inputs should be treated as binaries by default.

For 3.13.x, it's very likely the former.

[michaelklishin]

Now that I've started looking at the docs, I see that the encode command examples do use '<<"Binary values">>' correctly.

[michaelklishin]

Some relevant (and minor) doc updates rabbitmq/rabbitmq-website@4a6666f.

I conclude that there isn't anything to change in CLI tools per se. Unless we want to lose the ability to encode more than one data type without additional CLI flags.