‘I am done with open source’: Developer of Rust Actix web framework quits, appoints new maintainer

The maintainer of the Actix web framework, written in Rust, has quit the project after complaining of a toxic web community – although over 100 Actix users have since signed a letter of support for him.

Actix Web was developed by Nikolay Kim, who is also a senior software engineer at Microsoft, though the Actix project is not an official Microsoft project. Actix Web is based on Actix, a framework for Rust based on the Actor model, also developed by Kim.

The web framework is important to the Rust community partly because it addresses a common use case (development web applications) and partly because of its outstanding performance. For some tests, Acitx tops the Techempower benchmarks.

The project is open source and while it is popular, there has been some unhappiness among users about its use of “unsafe” code. In Rust, there is the concept of safe and unsafe. Safe code is protected from common bugs (and more importantly, security vulnerabilities) arising from issues like variables which point to uninitialized memory, or variables which are used after the memory allocated to them has been freed, or attempting to write data to a variable which exceeds the memory allocated. Code in Rust is safe by default, but the language also supports unsafe code, which can be useful for interoperability or to improve performance.

Actix is top of the Techempower benchmarks on some tests

Actix is top of the Techempower benchmarks on some tests

There is extensive use of unsafe code in Actix, leading to debate about what should be fixed. Kim was not always receptive to proposed changes. Most recently, developer Sergey Davidoff posted about code which “violates memory safety by handing out multiple mutable references to the same data, which can lead to, eg, a use-after-free vulnerability.”

Davidoff also stated that: “I have reported the issue to the maintainers, but they have refused to investigate it,” referring to a bug report which Kim deleted.

Debate on this matter on the Reddit Rust forum became heated and personal, the key issue being not so much the existence of real or potential vulnerabilities, but Kim’s habit of ignoring or deleting some reports. Kim decided to quit. On January 17th, he posted an “Actix project postmortem”, defending his position and complaining about the community response.

“Be[ing] a maintainer of large open source project is not a fun task. You[‘re] alway[s] face[d] with rude[ness] and hate, everyone knows better how to build software, nobody wants to do homework and read docs and think a bit and very few provide any help. … You could notice after each unsafe shitstorm, i started to spend less and less time with the community. … Nowadays supporting actix project is not fun, and be[ing] part of rust community is not fun as well. I am done with open source.”

Kim said that he did not ignore or delete issues arbitrarily, but only because he felt he had a better or more creative solution than the one proposed – while also acknowledging that the “removing issue was a stupid idea.” He also threatened to “make [Actix] repos private and then delete them.”

Over on the official Actix forum, he said he was “highly sceptical about fork viability” perhaps because, at least according to him, “no one showed any sign of project architecture understanding.”

So long, and good luck

Since then, matters have improved. The Github repository was restored and Kim said:

I realized, a lot of people depend on actix. And it would be unfair to just delete repos. I promote @JohnTitor to project leader. He did very good job helping me for the last year. I hope new community of developers emerge. And good luck!

In addition, Kim has started winning support from many community members, as evidenced by a letter with over 100 signatories thanking him and stating: “We are extremely disappointed at the level of abuse directed towards you.”

The episode demonstrates that expert developers are often not expert in managing the human relations aspect of projects that can become significant. It also shows how some contributors and users do not practice best behaviour in online interactions, forgetting the extent of the work done by volunteers and for which, it’s worth noting, they have paid nothing.

Positive recent developments may mean that Actix development continues, that bugs and security vulnerabilities are fixed, and that its community gets a better handle on how to proceed constructively. ®

Source: ‘I am done with open source’: Developer of Rust Actix web framework quits, appoints new maintainer • The Register

Netgear leaves admin interface’s TLS cert and private key router firmware

Netgear left in its router firmware key ingredients needed to intercept and tamper with secure connections to its equipment’s web-based admin interfaces.

Specifically, valid, signed TLS certificates with private keys were embedded in the software, which was available to download for free by anyone, and also shipped with Netgear devices. This data can be used to create HTTPS certs that browsers trust, and can be used in miscreant-in-the-middle attacks to eavesdrop on and alter encrypted connections to the routers’ built-in web-based control panel.

In other words, the data can be used to potentially hijack people’s routers. It’s partly an embarrassing leak, and partly indicative of manufacturers trading off security, user friendliness, cost, and effort.

Security mavens Nick Starke and Tom Pohl found the materials on January 14, and publicly disclosed their findings five days later, over the weekend.

The blunder is a result in Netgear’s approach to security and user convenience. When configuring their kit, owners of Netgear equipment are expected to visit https://routerlogin.net or https://routerlogin.com. The network’s router tries to ensure those domain names resolve to the device’s IP address on the local network. So, rather than have people enter 192.168.1.1 or similar, they can just use that memorable domain name.

To establish an HTTPS connection, and avoid complaints from browsers about using insecure HTTP and untrusted certs, the router has to produce a valid HTTPS cert for routerlogin.net or routerlogin.com that is trusted by browsers. To cryptographically prove the cert is legit when a connection is established, the router needs to use the certificate’s private key. This key is stored unsecured in the firmware, allowing anyone to extract and abuse it.

Netgear doesn’t want to provide an HTTP-only admin interface, to avoid warnings from browsers of insecure connections and to thwart network eavesdroppers, we presume. But if it uses HTTPS, the built-in web server needs to prove its cert is legit, and thus needs its private key. So either Netgear switches to using per-device private-public keys, or stores the private key in a secure HSM in the router, or just uses HTTP, or it has to come up with some other solution. You can follow that debate here.

Source: Leave your admin interface’s TLS cert and private key in your router firmware in 2020? Just Netgear things • The Register