Enumerable for function(2)

AFAIK Streams are just 2-ary functions, that is why Enumerable is implemented for them.

Nope

iex(1)> 1..10 |> Stream.map(&(1+&1)) |> Map.get(:__struct__)
Stream

This is the whole point: when structs are present in the language, such thing is unnecessary.

Yes:

iex(1)> Stream.unfold(5, fn 
...(1)> 0 -> nil
...(1)> n -> {n, n - 1}
...(1)> end) |> is_function(2)
true

Well that’s because this function in fact returns function(2) but not Stream:
https://github.com/elixir-lang/elixir/blob/v1.10.2/lib/elixir/lib/stream.ex#L1524-L1527

As a proof:

iex(4)> Stream.map(1..5, &(&1+1)) |> is_function(2)
false

Although it answers the question why defimpl for function(2) can’t be simply removed from the enum.ex module, the reason why this solution is still used is still a mystery to me.

This is considered a vulnerability?

IMO “the vulnerability” here is deserializing untrusted data from ETF - the Enumerable protocol running 2-arity functions is only a way to escalate the impact of that vulnerability from a simple DoS (like you’d get with a giant / unbounded Range) into RCE.

And even if there would be no defimpl for 2-ary functions, the problem would still be there, as nothing prevents user from encoding %Stream{enum: malicious_fun} to ETF.

Not at all: notice those quotes

@al2o3cr @hauleth It’s not about the possibility of running external (possibly malicious) code on you node without knowing it. I do acknowledge that there’re ways to do so as long as there’s a way to convert lambda to ETF.

What I’m asking is that there’s code that’s no longer needed with Streams present in stdlib.

I originally wanted to create an issue with this, but maybe I am missing something here.

I think it’s a mistake to think of a Stream as a single kind of datastructure. What exists is an Enumerable protocol, and then Enum functions to consume those Enumerables eagerly, and Stream functions to consume those Enumerables lazily. Absolutely anything that implements the Enumerable protocol is Enumerable. The standard library, mostly for I think easier pattern matching and IO.inspect purposes, has created some Stream named structs to represent certain constructs that have been built in a way that is amenable to streaming. That doesn’t mean that that fits every scenario however.

It’s also worth keeping in mind Elixir compatibility guarantees. At best you could deprecate the use of 2 arity functions as enumerables, but you can’t eliminate it without breaking people’s code that relies on this.

Now that’s the interesting part.

I’ve failed to find any documentation for this behaviour. That is, to use function(2) as a first argument to function calls from Enum and Stream modules.

And IF it is not documented: what compatibility guarantees are we talking about?

It is just a rule of thumb that you should never rely on any undocumented behaviour or implementation-specific details. And I consider it to be the case here.