This Week in Programming: Should Trust Have a Home in Open Source Security?
The fallout continues between University of Minnesota researchers and the Linux kernel developers after the researchers described how they had intentionally submitted some commits to the Linux kernel that would introduce vulnerabilities, in a paper titled “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits,” detailing how they had intentionally submitted some commits to the Linux kernel that would introduce vulnerabilities.
When the Linux maintainers found out about this, they quickly banned the entire university from Linux development, before the Linux Foundation sent the university a list of demands, to which it would seem the university quickly acceded, pulling its paper from an IEEE conference to which it was accepted and agreeing to provide “all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment.”
Linux kernel developers do not like being experimented on, we have enough real work to do: https://t.co/vWvtxjt7A5
— Greg K-H (@gregkh) April 21, 2021
Now, you might find yourself thinking, as do I, that, uninformed of the ethical requirements of security research, and not perfectly in the know of how these sorts of things work, that it illuminates something nonetheless. Various commenters in numerous threads point out that the ability to submit a bug of this sort was already a known threat and that proving it could be done achieved little.
In a recap of the month’s events, Linux Weekly News creator Jonathan Corbett offers some lessons learned, among them that “kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands. They are, as a result, forced to rely on the trustworthiness of the developers who submit patches to them. The kernel development process is, arguably, barely sustainable when that trust is well placed; it will not hold together if incoming patches cannot, in general, be trusted.”
While all fault should be placed where it properly lies, is it also victim-blaming to suggest that perhaps the current method of ensuring security in an operating system that runs critical systems across the globe might need some beefing up? The argument that this experiment didn’t play by the rules of, well, ethical experimentation may be a valid one, but ethics have little to do with real-world security. It seems like at the moment the game being played is one where we rely on everyone to play fair, which seems an odd approach to security.
The researchers’ alleged finding was that it’s very easy for unethical people to sneak malicious commits into the Kernel.
The Devs’ counterargument is that the researchers are absolutely right, but they weren’t ethical in pointing this out.
I think the “point” is both things.
— Matthew Green (@matthew_d_green) April 29, 2021
As Corbett further writes, “the speed of the kernel process is one of its best attributes, and we all depend on it to get features as quickly as possible. But that pace may be incompatible with serious patch review and low numbers of bugs overall. For a while, we might see things slow down a little bit as maintainers feel the need to more closely scrutinize changes, especially those coming from new developers. But if we cannot institutionalize a more careful process, we will continue to see a lot of bugs and it will not really matter whether they were inserted intentionally or not.”
the most cursed promoted tweet pic.twitter.com/0vUtbtAzfv
— Ian Coldwater 📦💥 (@IanColdwater) April 29, 2021
This Week in Programming
- Facebook Gets Rusty, Too: Last week, we looked at how Microsoft is getting Rusty, and this week, Facebook is touting its Rusty-ness too with a telling of history of Rust at Facebook as the company announces that it is officially joining the nonprofit Rust Foundation. In the post, the company relates how Rust made in-roads, starting in 2016 with a rewrite project called Mononoke. “Developing Mononoke in C++ was the obvious choice at first,” they write. “At the time, Facebook’s back-end codebase was very C++ heavy, meaning Mononoke would have been implemented in C++ by default. But the Source Control team needed to consider the reliability needs of the source control back end. When corruption or downtime can potentially bring services to a halt, reliability is a top priority. That’s why the team chose to go with Rust over C++.” The success of Mononoke brought Rust to other teams and projects, and now the company says the number of Rust developers there has grown dramatically, leading to the launch of a Rust team in its Programming Languages organization, which will focus on supporting internal users from a language and toolchain perspective, contributing to Rust itself, providing interoperability of Rust with C++ at Facebook, and working with the Rust Foundation.
“Recursion is the parallel parking of programming.”
— Scott Hanselman (@shanselman) April 29, 2021
- Microsoft Ups Its Python Support: Of course, while we’re all Rust this and Rust that, Microsoft also doesn’t want us to forget Python, which remains one of the most popular languages out there, as the company furthers its support for the Python community with a bumped-up sponsorship of the Python Software Foundation to the new top Visionary level. Lest you think the Internet is made up of only shiny new toys, Microsoft lays out its support of Python over recent years, including the numerous projects it has developed with the language, and the numerous employees it counts among core CPython developers and contributors and maintainers of key open-source projects in the Python ecosystem, including pandas, Dask, Jupyter, nteract, scikit-learn and Apache Arrow.
- Azure Intros Web PubSub for Real-Time Apps with WebSockets: Microsoft has previewed its Azure Web PubSub, which gives developers the ability to build real-time web applications using WebSockets. The service will be fully managed, globally available, and provide native WebSocket support, meaning it will support a variety of languages through WebSocket APIs. It will also offer native integration with Azure Functions, allowing developers to build serverless applications in C#, JavaScript, Python, and Java using WebSockets. David Fowler, now-Microsoft employee and one-time creator of the real-time ASP.NET SignalR library, offered a quick Twitter thread on the differences between the two offerings, noting that Web PubSub allows you to bring your own WebSocket library, which “lowers the barrier of entry for using the service, you just need an HTTP client and a WebSocket client to get going.” The feature is in preview for now, but you can get started by visiting the Azure Web PubSub service page, checking out the preview documentation, perusing the code samples, or hitting up the quickstart guide.
I SQL what you did there. https://t.co/xnJCOUR8oK
— DM of Engineering (@dmofengineering) April 7, 2021
- Dependabot Goes GitHub-Native: GitHub said this week that it would be shutting down the Goodbye Dependabot Preview in favor of the GitHub-native version of the dependency update tool, with an end-of-life date of August 3, 2021. Currently, the Dependabot preview and Dependabot.com itself will no longer accept new customers, and with the move some features will also be departing, including PHP environment variable registries, auto-merge, and live updates, although the company says it hopes to bring updates back in the near future. For you Dependabot preview users, all you will need to do is merge the “Upgrade to GitHub-native Dependabot” pull request in your repository by August 3.
I DID IT I LET A SIDE PROJECT DOMAIN EXPIRE
— Rob Sutter (@rts_rob) April 29, 2021
