One of my concerns by adding a flag is that we may end-up like EU's Cookie policy where nobody actually read the warning, they will just end-up passing the flag. So at this point I would prefer the flag to be opt-in so people enable it explicitly when they want to be double sure no execution happens on deps.get, for example, during deployments.
*José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Thu, Jun 30, 2016 at 1:10 PM, Eric Meadows-Jönsson < [email protected]> wrote: > A PR for a flag would be appreciated. > > On Tue, Jun 28, 2016 at 9:33 AM, Bram Verburg <[email protected]> > wrote: > >> Hi Eric, >> >> Thanks for your feedback. It's definitely a UX versus security trade-off. >> >> Personally I dislike those tools that tell you to install by copying >> "curl http://example.net/install.sh | sh" into the terminal (HomeBrew, >> I'm looking at you), and in many ways this is very similar. Except that in >> the curl example it should be obvious what is being done, whereas people >> might not realise what's going on during "mix deps.get". Especially for >> beginners I'd rather err on the side of caution: show a message explaining >> why the sub-dependencies were not installed and point to the docs for more >> info. >> >> On the other hand, it seems no one is particularly concerned about Ruby >> .gemspec files doing the same thing (someone please correct me if I'm >> wrong, it's been a while since I've used Ruby). But then again, Ruby has >> always preferred the path of least resistance for the developer. In other >> areas Elixir tries to improve over Ruby by looking beyond instant developer >> gratification, with the "explicit is better than implicit" approach. I >> think the same could be applied here. But in the end that's up to the core >> team, perhaps based on community consensus. >> >> Anyway, I could start with a PR that adds a flag, and we can continue the >> discussion on what should be the default in the PR. >> >> Thanks, >> >> Bram >> >> >> On Tuesday, 28 June 2016 00:38:34 UTC+3, Eric Meadows-Jönsson wrote: >>> >>> 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 >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fhexpm%2Fhex%2Fissues%2F243&sa=D&sntz=1&usg=AFQjCNG_zuEa8qZ_GFOFT6fGrZQhR-tHlw> >>> 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/441342a6-d242-4987-b0ed-6b5d8405db35%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/441342a6-d242-4987-b0ed-6b5d8405db35%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_eapiWKhhei84GYN86v38gKk%3DWnMVm9y90tVzj7ivg2VBh6w%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAM_eapiWKhhei84GYN86v38gKk%3DWnMVm9y90tVzj7ivg2VBh6w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGnRm4%2BiB3cH6qVH2NSDU%2BEFZup24QmbUO6Xq8CeLN8ZF6iNsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
