There is perhaps no better source to understand and learn the Erlang language than the book “Programming Erlang” by Joe Armstrong (“Programing Erlang, Second Edition”, The Pragmatic Bookshelf, 2013). This is detailed, authoritative exposition of the language covering all aspects of it, from the design principles to the procedures to build an application.
Regrettably this book shares with most Erlang-focused literature, an extremely light touch on Security principles and requirements. I know: Erlang was *not designed for Security* and there are various ways in which you can protect an Erlang environment by using other technologies, languages and systems. That is granted, but note that I am not doing this research just to “bash” Erlang or to promote a different “language.” Definitely not: in fact, by highlighting the glaring lack of Security capabilities in Erlang I want to show that Erlang is not different to the great majority of programming languages in that it systemically ignores Security principles. And it is also not different in the sense that it exhibits an overwhelming performance-centred focus, while ignoring the organisational and interactional context of any application.
This is particularly salient given the fact that Armstrong –the originator and leader of the Erlang “world-view” if my references are correct—actually believes that the language “models how we think and interact.” Armstrong writes:
“If we want to write programs that behave as other object behave in the real world then these programs will have a concurrent structure. This is why we should program in a concurrent programming language. And yet most often we program real-world applications in sequential programming languages. This is unnecessarily difficult. Use a language that was designed for writing concurrent applications and concurrent development becomes a lot easier.
“Erlang programs model how we think and interact. We don’t have shared memory. I have my memory. You have yours. We have two brains, one each. They are not joined. To change your memory I send you a message: I talk, or I wave my arms. You listen, you see, and your memory changes: however, without asking you a question or observing your response, I do not know that you have received my messages.
“This is how it is with Erlang processes. Erlang processes have no shared memory. Each process has its own memory. To change the memory of some other process, you must send it a message and hope that it receives and understands the message.”
While this is a straightforward presentation of the Erlang approach, it only amounts to a series of assumptions and crude simplifications. For example it is evident that human beings in their interaction *do* have shared memories and memory-supporting materials, tools, etc. around them. So the comparison between the Erlang process and human individuals is a rather poor one. The Erlang model could be justified in many ways, but definitely not by assuming that this is how humans think and interact.
Armstrong’s inadequate comparison may clarify what to expect from Erlang, but it also shows the ideology that sits behind its design: the false assumption that the whole world (including human beings) is a mass of “objects2 that “interact” by message passing. While Erlang has become famous by the reduction of all interactions to “processes,” in reality it is no different to the recent software development tools that reduce everything to “objects.”
It may be acceptable to try and simplify the representation of the world for the sake of engineering, but is is absurd to pretend that the representation is the world. What “works” quantitatively, syntactically and even semantically in the representation does not say anything about the context of the representation itself, i.e. its pragmatic angle and ultimate motivation (or final cause).
Erlang then is not different to the object-orientated world and it is futile to “oppose” it to all the other object orientated tools as if it had brought about a philosophical breakthrough. It has not done so!
Erlang is somewhat different to many other object-oriented languages because of its emphasis on concurrency, performance and resistance to failure. This emphasis if of such intensity that it reaches some comical levels when we read it from a wider IT perspective. An example of this the following text which shows of lack of insight in Armstrong’s book.
On Chapter 11, page 179, when discussing Real World Concurrency, Armstrong writes:
“Erlang processes don’t share memory, so there is no need to lock the memory while it is being used. Where there are locks, there are keys that can get lost. What happens when you lose your keys? You panic and don’t know what to do. That’s what happens in software systems when you lose your keys and your locks go wrong. Distributed software systems with locks and keys always go wrong. Erlang has no locks and no keys.”
I know, I know: Armstrong is speaking only about memory locking and the difference between the threaded and process concurrency models and *not* about Security. Definitely not, otherwise he or his editor would not have left those funny but unfortunate words in the text. That is what a call a lack of insight: Armstrong is evidently not writing for a Security-focused audience.
Does he ever write for or about Security in his book? A little. Let’s see what he writes on pages 222 and 223 (The Cookie Protection System).
“Access to a single node or set of nodes is secured by a cookie system. Each node has a dingle cookie, and this cookie must be the same as the cookies of any nodes to which the node talks. To ensure this, all nodes in a distributed Erlang system must have been started with the same magic cookie or have their cookie changes to the same value by evaluating erlang:set_cookie.
“The set of connected nodes having the same cookie defines an Erlang cluster. […]
“Important: The cookie protection system was designed for building distributed systems that run on a local area network where the LAN itself was protected from the Internet by a firewall. Distributed Erlang applications running across the Internet should first set up secure connections between hosts and then use the cookie protection system.”
And then he describes three methods to set the cookie:
a) creating a local cookie on the file system and protecting it with OS file permissions
b) using a command line option to set the cookie of the node
c) using a built-in function (BIF) to set the cookie on the local node
To finally add:
“If your environment is insecure, then method 1 or 3 is better than method 2 since on a Unix system anybody can discover your cookie using the ps command . Method 2 is useful only for testing.”
Which again confirms our perception that Erlang is completely dependent on OS security capabilities for its own Security, and not only or primarily for inter-node communication.
Armstrong closes this weak discussion of Security on the Erlang platform by saying:
“In case you are wondering, cookies are never sent across the network in the clear. Cookies are used only for the initial authentication of a session. Distributed Erlang sessions are not encrypted but can be set up to run over encrypted channels.”
So, in essence we have here the same superficial advice found in most Erlang-related literature: “roll your own” and/or use SSL for “security.” But this advice comes from a limited perspective which sees Security as something linked to “network connections” and to “encryption” only. And the real issues of application security are glossed over in complete silence.