Skip to content

Possible issue with :cookie option of Mix Release #13694

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ronaldwind opened this issue Jun 26, 2024 · 0 comments
Closed

Possible issue with :cookie option of Mix Release #13694

ronaldwind opened this issue Jun 26, 2024 · 0 comments

Comments

@ronaldwind
Copy link

Elixir and Erlang/OTP versions

Elixir 1.16.2 (compiled with Erlang/OTP 26)

Operating system

Linux

Current behavior

The documentation of the :cookie option gives an example of how to pass your own cookie (using Base.url_encode64/1): https://github.com/elixir-lang/elixir/blob/v1.17.1/lib/mix/lib/mix/tasks/release.ex#L403-L406

      If you are setting this option manually, we recommend the cookie option
      to be a long and randomly generated string, such as:
      `Base.url_encode64(:crypto.strong_rand_bytes(40))`. We also recommend to restrict
      the characters in the cookie to the subset returned by `Base.url_encode64/1`.

Base.url_encode64 may result in a string starting with an hyphen (-). This will lead to an issue starting beam with this cookie as the system process is started with a command like beam.smp ... -setcookie [cookie]. When the cookie starts with an hyphen it's interpreted as an argument and erlang will just generate a random new cookie.

Looking at https://github.com/elixir-lang/elixir/blob/main/lib/mix/lib/mix/tasks/release.init.ex#L147 it should actually be --hidden --cookie \"$RELEASE_COOKIE\" \ for it to work with cookies starting with an hyphen.

Maybe just tweaking the docs to use Base.encode32/1 instead would be the best solution as this is what Mix Release also uses (https://github.com/elixir-lang/elixir/blob/main/lib/mix/lib/mix/release.ex#L568)?

Expected behavior

See above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant