Yes: when the top-level project is managed by Mix then all Hex packages are fetched by Mix/Hex, even (transitive) dependencies that use Rebar3 as the build tool.

Mix has never verified the server’s certificate, since it does not have a CA trust store (unlike e.g. Hex and Rebar3). Instead of relying on a secure channel, it verifies the artifacts it downloads against a registry of checksums. This registry has a signature that can be verified using the public key(s) that are built into the tool, and that can be managed using mix local.public_keys.

We have updated the rebar versions for those on Elixir v1.11.4+. As we said, Elixir is safe regardless as we don’t use rebar to download packages, but providing the latest rebar is a good call anyway.

Yep. 3.7 had specific substitution attacks in limited scenarios, but those could have worked regardless iirc. API credential leakage is the trickiest and most likely issue to encounter here for sure. Generally those are at least not very frequent, on a narrow user base, and require per-device asymmetric keys with local passwords to use and aren’t very obvious to break from just the network, although user auth session (once per device) would be a likely best candidate there to then register other keys.

All of these are pretty narrow and require convoluted approaches by someone very dedicated. By comparison, what I consider to be more realistic threats of build tools are all made easier by having people just write a dependency that runs arbitrary code (as macros or configuration scripts) to exfiltrate or modify local data, and convincing people to install it.

Local passwords on publication helps protect against this becoming a worm (you require user input to do it), but there are interesting high-yield approaches then, such as lifting SSH keys (which give you potential access to git repositories and may not be password-protected) or just scanning project-parent directories that contain source code and having the ability to make changes there.

For a comparison, I’m handling all of these TLS issues very seriously, but as far as threat modelling goes, this is closing the 2nd floor window when the front door is off its hinges already, on purpose.

I’ll reach out to the Elixir core team…

Is it correct that we can safely run Elixir projects (with mix) with rebar3 3.14.4? I get certificate warnings when running mix local.rebar:

$ mix local.rebar

10:14:23.298 [warn]  Description: 'Authenticity is not established by certificate path validation'
     Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'


10:14:23.518 [warn]  Description: 'Authenticity is not established by certificate path validation'
     Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'

.asdf/installs/elixir/1.12.0-otp-24/.mix/rebar already exists, overwrite? [Yn] 

10:14:24.772 [warn]  Description: 'Authenticity is not established by certificate path validation'
     Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'

* creating .asdf/installs/elixir/1.12.0-otp-24/.mix/rebar

10:14:24.887 [warn]  Description: 'Authenticity is not established by certificate path validation'
     Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'


10:14:24.959 [warn]  Description: 'Authenticity is not established by certificate path validation'
     Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'

.asdf/installs/elixir/1.12.0-otp-24/.mix/rebar3 already exists, overwrite? [Yn] 

10:14:25.356 [warn]  Description: 'Authenticity is not established by certificate path validation'
     Reason: 'Option {verify, verify_peer} and cacertfile/cacerts is missing'

* creating .asdf/installs/elixir/1.12.0-otp-24/.mix/rebar3