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

[bile@REDACTED]

I understand that completely. It's just that the FAQ, which is likely
in response to my patches, takes a rather simple view of things. There
are several things that are security related in Erlang and aren't very
well developed so this claim that security should be all or nothing
seems rather artificial and unfortunate. There are several simple,
noninvasive changes which would provide some amount of sandboxing
without affecting existing behavior and there has been nothing but
resistance. Security is always measured in degrees and relative to
other aspects of the system. If Erlang is to gain ground as a
distributed platform it would seem to me that security should be
addressed. Otherwise its distributedness should take a backseat to it's
other features as most firms I've ever dealt with simply couldn't allow
the level of openness it creates.

On Mon, 22 Mar 2010 23:28:59 +0100
Ulf Wiger <ulf.wiger@REDACTED> wrote:

> Musumeci, Antonio S wrote:
> > 
> >> "Almost secure" is not any better than "definitely not secure". You
> >> > still cannot allow untrusted nodes to connect. (To reach the
> >> level > of complete security is very hard for a protocol that was
> >> not designed for that in the beginning.)
> > 
> > If this is true why support cookies at all? Why complicate the code
> > with basic authentication when if you don't want two nodes possibly
> > connecting to one another an individual just shouldn't start them in
> > networking mode. Why have the allowed list? Or protections for ETS
> > tables? Or keep around the "connected" process port info.
> 
> One reason is that you can protect against different systems
> /accidentally/ connecting to each other. One example where that can
> be very handy is when doing "redundancy upgrades" of a system;
> while the two halves of a system are running mutually incompatible
> versions of the software, or e.g. different versions of the database
> schema, you really don't want them to connect. In that case, you
> can ensure that they don't by changing the cookie on one side.
> For this scenario, cookie-based authentication is perfectly adequate,
> since the nodes involved are known to be benign.
> 
> There are many good reasons to maintain a basic level of security,
> even if it doesn't protect against malicious attacks.
> 
> BR,
> Ulf W