Re: [elixir-core:5998] Re: Access behaviour for lists and tuples?

[Filip Haglund]

Access for Keywords are already O(n), just like access on lists would be. 
Tuples would probably be O(1).

On Monday, June 27, 2016 at 5:27:32 PM UTC+2, Louis Pop wrote:
>
> Hey 
>
> I think adding the Access protocol to lists would imply that list 
> indexing is efficient. We should be careful to steer new users away 
> from techniques that are inefficient or not idiomatic. 
>
> Cheers, 
> Louis 
>
> On 27 June 2016 at 16:22, Filip Haglund  
> wrote: 
> > Would it hurt to add it? 
> > 
> > On Sunday, June 26, 2016 at 6:16:19 PM UTC+2, Filip Haglund wrote: 
> >> 
> >> Why aren't lists and tuples implementing `Access`? 
> >> 
> >> {:a, :b, :c}[1] == :b 
> >> 
> >> 
> > -- 
> > 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-co...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/elixir-lang-core/3042a07d-90c9-4c82-a3a4-579579d44a1a%40googlegroups.com.
>  
>
> > 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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/4a2311f4-f4ad-4a38-aa6f-3eeb2f4dd063%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5996] Potential risk of fetching dependencies from Git

[Eric Meadows-Jönsson]

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 
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 " 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.
>



-- 
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 

[elixir-core:5996] Potential risk of fetching dependencies from Git

[Bram Verburg]

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 " 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.

Re: [elixir-core:5994] Re: Access behaviour for lists and tuples?

[Louis Pop]

Hey

I think adding the Access protocol to lists would imply that list
indexing is efficient. We should be careful to steer new users away
from techniques that are inefficient or not idiomatic.

Cheers,
Louis

On 27 June 2016 at 16:22, Filip Haglund  wrote:
> Would it hurt to add it?
>
> On Sunday, June 26, 2016 at 6:16:19 PM UTC+2, Filip Haglund wrote:
>>
>> Why aren't lists and tuples implementing `Access`?
>>
>> {:a, :b, :c}[1] == :b
>>
>>
> --
> 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/3042a07d-90c9-4c82-a3a4-579579d44a1a%40googlegroups.com.
> 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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAM-pwt6u%3DwQpMJGMfX80JyfxjkEbbzQKPRzKi8w3%2BBWe%2BDAaUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:5994] Re: Access behaviour for lists and tuples?

[Filip Haglund]

Would it hurt to add it?

On Sunday, June 26, 2016 at 6:16:19 PM UTC+2, Filip Haglund wrote:
>
> Why aren't lists and tuples implementing `Access`? 
>
> {:a, :b, :c}[1] == :b
>
>
>

-- 
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/3042a07d-90c9-4c82-a3a4-579579d44a1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.