Closed blandinw closed 3 years ago
hi @blandinw this is definitely an interesting one! If you have a fix I would suggest opening it up on https://github.com/erlang/rebar3/ as rebar3_hex isn't responsible for reading or writing the files. Hopefully it's something that can be fixed that doesn't require patching OTP 🤞 .
I'm not sure how that works. encrypt_write_key does not return a term that you could just pass to iolist_to_binary. THe term is possibly not safe to pass directly to a write that needs to be interpreted. An option might rather be to use io_lib:format("~w.~n", [Encrypted])
.
@ferd that seems to fix the issue 👍, the change will have to be done in rebar3 vs rebar3_hex as rebar3_hex just delegates to rebar_hex_repos:update_auth_config/2
to in rebar3.
Rebar3 is calling to rebar3_hex?!
@ferd nah...
rebar3_hex_user
calls rebar3_hex_config:update_auth_config/2
after generating keys. rebar3_hex_config:update_auth_config/2
delegates to the module rebar_hex_repos:update_auth_config/2
in rebar3
Bit confusing per the hex
in names.
EDIT:
Link to where patch needs to be made for clarity : https://github.com/erlang/rebar3/blob/bed5a1a505981bf0600d6562328739db4c9918ac/src/rebar_hex_repos.erl#L161
Using io_lib:format("~lp.~n", [Encrypted])
fixes the issue and preserves the pretty printing.
In other words, in rebar_hex_repos:update_auth_config/2
, we should use the above instead of io_lib:print
.
I can provide a PR tomorrow if nobody gets to it before then.
EDIT actually, it just turns all chars into numbers, so I'm not sure pretty printing matters too much 😊
Using
io_lib:format("~lp.~n", [Encrypted])
fixes the issue and preserves the pretty printing. In other words, inrebar_hex_repos:update_auth_config/2
, we should use the above instead ofio_lib:print
. I can provide a PR tomorrow if nobody gets to it before then.EDIT actually, it just turns all chars into numbers, so I'm not sure pretty printing matters too much 😊
Yeah, "~p.~n"
should be the way to go, just tested that against local dev instance, looks good :
$ cat ~/.config/rebar3/hex.config
#{<<"hexpm">> =>
#{read_key => <<"d68707e7588fc0f4c18aacfbbcd2828f">>,
repo_key => <<"88f5eb5b24de49ec165a14e14085cfef">>,
username => <<"jose">>,
write_key =>
{<<113,41,250,91,107,60,171,197,241,73,152,223,202,142,160,110>>,
{<<213,224,50,151,1,85,140,96,15,165,230,94,142,129,175,190,90,
101,216,105,229,123,182,240,230,150,76,5,136,88,112,145>>,
<<24,136,85,244,37,124,22,162,121,200,135,241,235,2,7,24>>}}}}.
$ rebar3 hex user whoami
hexpm : jose (jose@example.com)
rebar3 hex publish --replace
===> Verifying dependencies...
Publishing truecoat 0.42.0 to hexpm
Description: It gets installed at the factory
Dependencies:
Included files:
LICENSE
README.md
rebar.config
rebar.lock
src/truecoat.app.src
src/truecoat.erl
Licenses: Apache 2.0
Links:
Build tools: rebar3
Be aware, you are publishing to the public Hexpm repository.
Before publishing, please read Hex CoC: https://hex.pm/policies/codeofconduct
Proceed? ("Y")> y
Local Password:
===> Published truecoat 0.42.0
===> Published docs for truecoat 0.42.0
The issue is random. Also, I'm new to rebar3, so I may be missing something. If you agree that this should be fixed, I can go ahead and provide a PR.
Steps:
Here is a minimal repro, after looking at the
hex user auth
code. Run in shell, at the project root:Here is the output of
rebar3 report