A critical vulnerability (CVE-2025-32433) exists in Erlang/OTP's SSH implementation, affecting versions prior to 26.2.1 and 25.3.2.6. This flaw allows unauthenticated remote attackers to execute arbitrary code on the server. Specifically, a specially crafted SSH message can trigger the vulnerability during the initial handshake, before authentication occurs, enabling complete system compromise. Users are urged to update their Erlang/OTP installations to the latest patched versions as soon as possible.
Erlang's defining characteristics aren't lightweight processes and message passing, but rather its error handling philosophy. The author argues that Erlang's true power comes from embracing failure as inevitable and providing mechanisms to isolate and manage it. This is achieved through the "let it crash" philosophy, where individual processes are allowed to fail without impacting the overall system, combined with supervisor hierarchies that restart failed processes and maintain system stability. The lightweight processes and message passing are merely tools that facilitate this error handling approach by providing isolation and a means for asynchronous communication between supervised components. Ultimately, Erlang's strength lies in its ability to build robust and fault-tolerant systems.
Hacker News users discussed the meaning and significance of "lightweight processes and message passing" in Erlang. Several commenters argued that the author missed the point, emphasizing that the true power of Erlang lies in its fault tolerance and the "let it crash" philosophy enabled by lightweight processes and isolation. They argued that while other languages might technically offer similar concurrency mechanisms, they lack Erlang's robust error handling and ability to build genuinely fault-tolerant systems. Some commenters pointed out that immutability and the single assignment paradigm are also crucial to Erlang's strengths. A few comments focused on the challenges of debugging Erlang systems and the potential performance overhead of message passing. Others highlighted the benefits of the actor model for concurrency and distribution. Overall, the discussion centered on the nuances of Erlang's design and whether the author adequately captured its core value proposition.
The post argues that Erlang modules primarily serve as namespaces, offering a way to organize code and avoid naming collisions, especially in large projects with multiple contributors. While modules can enforce information hiding through opaque data types, this isn't their primary purpose in Erlang, and the author contends that compile-time dependency checking and separate compilation, often cited as reasons for modules, are less relevant due to Erlang's dynamic nature and hot code loading capabilities. The author suggests that simpler projects might not benefit from modules, potentially introducing unnecessary complexity, and argues that their main value lies in preventing name clashes in complex systems.
HN users discuss the merits and drawbacks of modules, primarily in the context of Erlang. Some argue that modules, while offering namespacing and code organization, introduce unnecessary complexity, especially for smaller projects. They suggest that a simpler, record-based approach could suffice in some cases. Others highlight the crucial role of modules in managing larger codebases, facilitating separate compilation, and enabling code reuse. The idea of modules primarily as compilation units is also raised, emphasizing their importance for managing dependencies and build processes. Several commenters discuss the potential of a hybrid approach, offering lighter alternatives to full modules where appropriate, but acknowledging the value of modules for large, complex systems. The Erlang perspective, with its emphasis on lightweight processes and message passing, influences the discussion.
"Learn You Some Erlang for Great Good" is a comprehensive, beginner-friendly online tutorial for the Erlang programming language. It covers fundamental concepts like data types, functions, modules, and concurrency primitives such as processes and message passing. The guide progresses to more advanced topics including OTP (Open Telecom Platform), distributed systems, and how to build fault-tolerant applications. Using humorous illustrations and clear explanations, it aims to make learning Erlang accessible and engaging, even for those with limited programming experience. The tutorial encourages practical application by incorporating numerous examples and exercises throughout, guiding readers from basic syntax to building real-world projects.
Hacker News users discussing "Learn You Some Erlang for Great Good!" generally praised the book as a fun and effective way to learn Erlang. Several commenters highlighted its humorous and engaging style as a key strength, making it more accessible than drier technical manuals. Some noted the book's age and questioned whether all the information is still completely up-to-date, particularly regarding newer tooling and OTP practices. Despite this, the overall sentiment was positive, with many recommending it as an excellent starting point for anyone interested in exploring Erlang. A few users mentioned other Erlang resources, like the "Elixir in Action" book, suggesting potential alternatives or supplementary materials for continued learning. There was some discussion around the practicality of Erlang in modern development, with some arguing its niche status while others defended its power and suitability for specific tasks.
The blog post "Gleam, Coming from Erlang" explores the author's experience transitioning from Erlang to Gleam, a newer language built on the Erlang Virtual Machine (BEAM). It highlights Gleam's similarities to Erlang, such as its functional nature, immutability, and the benefits of the BEAM ecosystem like concurrency and fault tolerance. However, the author emphasizes key differences, primarily Gleam's static typing, more approachable syntax inspired by Rust and Elm, and its focus on clearer error messages. While acknowledging some current limitations in tooling and library availability compared to Erlang's mature ecosystem, the post ultimately presents Gleam as a promising alternative for building robust, concurrent applications, particularly for developers coming from other statically-typed languages who might find Erlang's syntax challenging.
Hacker News commenters generally expressed interest in Gleam, praising its friendly syntax and the benefits it inherits from the Erlang ecosystem, like the BEAM VM. Some saw it as a potentially strong competitor to Elixir, appreciating its stricter type system and simpler tooling. A few users familiar with Erlang questioned the necessity of Gleam, suggesting that learning Erlang directly might be more worthwhile. Performance comparisons with Elixir and other BEAM languages were also a topic of discussion, with some expressing hope for benchmarks. A recurring sentiment was curiosity about Gleam's potential to attract a larger community and gain wider adoption. Several commenters also appreciated the author's candid comparison between Gleam and Erlang, finding the article helpful for understanding Gleam's niche.
This blog post demonstrates how to build an agent-less system monitoring tool using Elixir and Broadway. It leverages SSH to remotely execute commands on target machines, collecting metrics like CPU usage, memory consumption, and disk space. Broadway manages the concurrent execution of these commands across multiple hosts, providing scalability and fault tolerance. The collected data is then processed and displayed, offering a centralized overview of system performance. The author highlights the benefits of this approach, including simplified deployment (no agent installation required) and the inherent robustness of Elixir and its ecosystem. This method offers a lightweight yet powerful solution for monitoring server infrastructure.
Hacker News users discussed the practicality and benefits of the agentless approach to system monitoring described in the linked blog post. Several commenters appreciated the simplicity and reduced overhead of not needing to install agents on monitored machines. Some raised concerns about potential security implications of running commands remotely via SSH and the potential performance bottlenecks of doing so. Others questioned the scalability of this method, particularly for large numbers of monitored systems. The discussion also touched on alternative approaches like using message queues and the potential benefits of Elixir's concurrency features for this type of monitoring system. A compelling comment suggested exploring the use of OSquery for efficient data gathering, which prompted further discussion on its pros and cons. Finally, some commenters expressed interest in the author's open-sourcing of their project.
Summary of Comments ( 11 )
https://news.ycombinator.com/item?id=43716526
Hacker News users discuss the severity and impact of the Erlang/OTP SSH vulnerability. Some highlight the potential for widespread exploitation given Erlang's usage in telecom infrastructure and distributed systems. Several commenters question the assigned CVSS score of 9.8, finding it surprisingly high for a vulnerability that requires non-default configuration (specifically enabling password authentication). The discussion also touches on the practical implications of the vulnerability, acknowledging that while serious, exploitation might be limited by the need for open SSH ports and enabled password logins. Others express concern about the potential for nested exploitation, as vulnerable Erlang systems might host other exploitable services. Finally, some users note the responsible disclosure and patching process.
The Hacker News post titled "Unauthenticated Remote Code Execution in Erlang/OTP SSH" (https://news.ycombinator.com/item?id=43716526) has several comments discussing the vulnerability (CVE-2025-32433).
Several commenters highlight the severity of the vulnerability, being an unauthenticated remote code execution flaw. One user points out the particularly dangerous combination of this being a pre-auth vulnerability and Erlang's frequent use in distributed systems, increasing the potential attack surface. They mention that distributed Erlang systems often run with minimal firewalling, making them easier targets.
Another commenter notes that exploitation is straightforward, quoting the NIST advisory that "Successful exploitation of this vulnerability requires only sending a crafted SSH message." This emphasizes the low barrier to entry for potential attackers.
Discussion also revolves around the practical impact. One user questions how many publicly exposed Erlang SSH servers exist, suggesting that while serious, the impact might be limited depending on the prevalence of such deployments. This prompts another commenter to mention that while direct SSH access to Erlang nodes might be less common, many systems likely use distributed Erlang for backend communication, which could be vulnerable.
A commenter with experience in securing Erlang systems suggests that the vulnerability reinforces the importance of employing robust network security measures, like firewalls and VPNs, even within internal networks. They highlight that assuming internal networks are safe is a dangerous misconception.
There's some discussion of the technical details. One user dives deeper into the mechanism of the vulnerability, explaining that it arises from the way the
ssh_packet_set_size/1function handles size limits before authentication, allowing malicious actors to bypass checks and execute arbitrary code.Finally, several commenters express concern about the vulnerability's potential to affect critical infrastructure and industrial control systems, given Erlang's presence in those sectors. One user speculates about the potential for this vulnerability to be exploited in targeted attacks.