First of I'd like you to thank you Bram for looking into potential security issues and starting discussions about what you find. We need more people doing that.
Also, your discussions with the core team and your blog post made me find this issue https://github.com/hexpm/hex/issues/243 in the Hex client where the checksums will not give full protection for locked dependencies. This is a difficult subject, because as it usually is with security you have to weigh the safety concerns against usability concerns. You can give give users all the tools for verifying all the dependencies they use but if it is not practical to do so in their normal workflow they will simply not use the tools we provide them. First we have to consider the number of users that would verify dependencies fetched from git repositories to protect themselves against compromised git repositories. My bet is that it is a small number (because of the time you have to invest in verifying the code), so I don't think we should change any defaults because that would impair the workflow for the majority of developers. But I do think we should add an option that only fetches one level of dependencies without evaluating their mix.exs for the developers that do care about this. Unfortunately, until we have some way of signing of code and a (practical) way of verifying the signatures I don't think we can have a great solution for this issue. And even then signing keys can be compromised, so in the end the only way to fully protect yourself is to fetch dependencies in a sandbox, manually vet all the code and lock them to your lockfile. On Mon, Jun 27, 2016 at 8:35 PM, Bram Verburg <[email protected]> wrote: > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/395b50f9-7918-403e-a368-a14fcb966f8f%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/395b50f9-7918-403e-a368-a14fcb966f8f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Eric Meadows-Jönsson -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM_eaphKxmj-UT-vO%2BmWNv8A5ZcLgJzA99NJ6KmP%3DP-nxACqZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
