[erlang-patches] What's cooking in erlang/otp (2010-03-22)

[Musumeci, Antonio S]

No they haven't. Not if you want to actually utilize the advertised features of the platform. Providing a means to communicate outside the VM and then serialize terms is hardly "all the instruments" needed to secure a platform. The former is standard fair in languages and the latter can be done independently.

1) Having to recreate the transport every time for every developer is wasteful. Why shouldn't there be a pluggable security model for the transport layer between nodes that would allow standard libraries to be shared? Knowing that the node you are talking with is actually who you believe it is surely useful and would need to be a first step in any further security developments around message passing.
2) It becomes impossible to utilize the distributed functionality built into the platform. From visualization tools to all the node based libraries. It turns the platform into a husk of what it was IMO. The language is nice as is the concurrency but it also advertises itself as a distributed platform. Well most distributed platforms I've worked with provide more than secret keys to a completely open platform.
3) I'm simply not talking about RPC in some specific case but general sandboxing of the platform. Not leaving holes open that aren't desired. Not allowing any ol' process to communicate with a port. Not allowing anyone to just rpc or spawn os:cmd("rm -rf /"). Some features and additions perfectly fit the NIF, Port, Cnode models. Others don't.

-----Original Message-----
From: Max Lapshin [mailto:max.lapshin@REDACTED] 
Sent: Tuesday, March 23, 2010 8:06 AM
To: Dennis Novikov
Cc: Musumeci, Antonio S (IT); Ulf Wiger; erlang patches
Subject: Re: [erlang-patches] What's cooking in erlang/otp (2010-03-22)

On Tue, Mar 23, 2010 at 3:03 PM, Dennis Novikov <dennis.novikov@REDACTED> wrote:
>
> Only if you have to stick with R12. R13 has 
> erlang:binary_to_term(Binary, [safe]) exactly for that purpose.
>

So, there are no problems. I don't understand how is it possible for OTP team to design All Possible Cases of Security =) They've gave us all instruments for it.

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.