Hi,

The other day I wrote a post on security best-practices around dependencies 
(https://blog.voltone.net/post/5). One of the issues I raised was the risk 
of unexpected code execution when pulling in dependencies from Git 
repositories: "mix deps.get" recursively installs any sub-dependencies, and 
this involves evaluating the downloaded mix.exs file.

On the one hand, the choice to embed 3rd party code into your application 
means you put (some) trust in the provider of that code. On the other hand, 
even a trusted developer can become the target of an attack that tries to 
inject malicious code into other people's applications: that's why, for 
instance, Hex protects the integrity of packages using HTTPS and checksums.

Given the risk of a Git repo being compromised, or even a developer going 
bad, downloading and immediately executing code from a repository seems 
like a bad idea. Users should have the possibility to review the downloaded 
code before deciding to trust it. Right now, running "mix deps.get" on a 
project with Git dependencies is technically a violation of my employer's 
security policies, since it could introduce malware or lead to data being 
harvested from the corporate network.

I'd love to hear your opinion (since I didn't get around to adding comments 
to my blog engine):

1. Should we be worried about this at all? When I pull in a Ruby Gem from a 
Git repo (as opposed to the RubyGems repositories) the same thing happens, 
right? And anyway, most dependencies are Hex packages nowadays...

2. Should we warn users about this in the Mix documentation? That seems a 
bit lame: to point out a security risk, but without offering any tooling to 
mitigate that risk other than letting the user manually inspect each 
repository (recursively) prior to running "mix deps.get"

3. Should we disable the automatic evaluation of "mix.exs" files fetched 
from Git (or other SCMs that don't have Hex-like dependency metadata), and 
instead let the user explicitly run "mix deps.get <git-based-dep>" to 
trigger evaluation of that dependency's "mix.exs" file to fetch 
sub-dependencies? Or ask interactively whether to go ahead, the way "mix 
phoenix.new" asks whether to fetch Mix and NPM dependencies? In both cases 
we could add an override flag "--force" to restore the current behaviour 
for users who understand and accept the risk.

Thanks,

Bram

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/395b50f9-7918-403e-a368-a14fcb966f8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to