Why Open Source Project Maintainers Are Reluctant to Use Digital Signatures, Two-Factor Authentication
We all agree that open source development methods help create better code. Eric S. Raymond showed us why in his seminal essay, “The Cathedral and the Bazaar,” which explained how the methodology of openness worked in GCC, the Linux kernel, and his own Fetchmail project. But, that’s a general rule. Open source can still be abused by unscrupulous developers. So, why don’t we make sure when a programmer attempts to merge code into a program that they’re really who they say they are, by using two-factor authentication (2FA) or a digital signature? Good question.
You might not think this is a real problem. Alas, it is. For example, in 2019 a malicious version of the popular RubyGems bootstrap-sass package was published in its official repository. Before it was discovered and eliminated it had been downloaded a mind-boggling 28-million times.
That wasn’t an isolated case. The CursedGrabber malware was successfully published to the JavaScript npm open source software code repository in January 2021.
Clearly, there’s a need to make sure developers can be traced back to a real-world identity. But, in the Linux Foundation’s 2020 FOSS Contributor Survey, when developers were asked if the open source projects they worked on required the use of 2FA such as with the GitHub organizational setting “Require two-factor authentication,” the answers were disappointingly low. Not quite half, 47.55%, didn’t use it all. Only 32.11% reported that some of their projects do, while just over a fifth, 20.34%, reported all their projects require 2FA.
“The main reason for low adoption of a secondary authentication factor is that turning on any multi-factor authentication (MFA) is an extra step, as it is rarely on by default for any software package.”
Mark Loveless, GitLab senior security researcher.
Why not? Most respondents said not including 2FA was a lack of decision rather than a decision. Many were either unaware it was an option or that because it is not the default behavior, it was not considered, or was considered too restrictive to require. “It wasn’t a decision, it was the default.”
Some of the detailed answers to the survey showed that security was not job number one to many developers. They didn’t see any “need for [2FA on] low-risk projects.” Other projects, with a handful of contributors, said they didn’t see the need at all. And, as in the case with so many security failure rationalizations, many thought 2FA was too difficult to use. One even said, “Adding extra hoops through which to jump would be detrimental to the project generally. Our goal is to make the contribution process as easy as possible.”
As for digital signatures, in which released versions come with cryptographically signed git tags (“git tag -s”) or release packages, so that users can verify who released it even if the distributing repo might be subverted, they’re not used anywhere near as often as they should be either. 41.53% don’t use them at all while 35.97% use them some of the time. A mere 22.5% use them all the time.
Why not? Good old inertia and “we’ve never used them” came up a lot. Others, of course, don’t see a need for digital signatures. One explained, “Trust is placed in the subsystem maintainers who review, sign-off, and forward changes, and in the public review system, rather than trusting individual contributors.” Nice, but it still wouldn’t stop a hacked maintainer account from wreaking havoc. Indeed, at least one programmer sees no need for it at all “because the friction that [it] would cause for contributions is never worth the security benefits of having it.”
If it were easier to implement, e.g., “an easy process that I can use, understand, and insist upon for contributors to supply them over channels like GitHub,” some would be more inclined to use it.
Help is coming with both methods. Patrick Toomey, GitHub‘s director of product security engineering, noted that “Open source maintainers for well-established projects (more than 100 contributors) are three to four times more likely to make use of 2FA than the average user.” That comes as no surprise because “larger and more popular projects appreciate their position and responsibility in the open source software supply chain. In addition, these projects often become GitHub organizations, with the ability to manage access to their repositories using teams and set security policies, including a requirement to enable 2FA.”
2FA, Toomey continued, is also becoming easier to use. “For example, GitHub is an early adopter of the emerging WebAuthn standard. Our initial support makes use of a subset of that standard to enable incredibly strong 2FA with physical security keys.” Better still, “all the major platforms have recently added the ability to use devices users already have (e.g. Face ID, Touch ID, Windows Hello, etc). This removes the need for any physical security key or third-party 2FA application. Over time we are optimistic that this will further increase 2FA adoption since WebAuthn provides the rare opportunity to allow users to authenticate both more securely and more easily.”
Even so, Mark Loveless, GitLab senior security researcher, noted “The main reason for low adoption of a secondary authentication factor is that turning on any multifactor authentication (MFA) is an extra step, as it is rarely on by default for any software package. This is mainly because most software vendors want system administrators to be able to customize freshly-installed software to meet specific needs. Additionally, most of the maintainers of open source projects are coding experts and not security-seasoned system administrators. So turning on MFA is not always top of mind.”
That said, Loveless said, “Most software, including GitLab’s, does make it pretty easy to implement MFA. I don’t think it is a matter of convincing the maintainer of an open source project of the security measures with MFA, it is a matter of simply reminding them that it should be done.”
Of course in an ideal world, Loveless shared, “The whole second-factor scenario existed because the primary factor — the password itself — has proven over and over again to be insecure. If I could wave a magic wand, we would not be using passwords at all and would use two factors such as a biometric like a fingerprint and FIDO U2F key stored on a USB-based security key.”
As for digital signatures Matt Sicker, Apache Software Foundation member and CloudBees’ senior security engineer, remarked, “Applications commonly used for signing software typically have confusing UIs and require learning basic cryptography concepts in order to properly use them. Without some sort of code signing policy in place for a larger open source project, many developers are simply unaware of the benefits of signing their software.”
On the other hand, multifactor authentication, Sicker continued, seems to be more commonly supported than code signing, but this is also an area where improved UX and education would likely improve the situation. When you also consider that open source software tends to be more decentralized, the common methods for physical distribution of signing keys is itself a hard problem in the cryptographic sense.” That’s where the W3C WebAuthn specification can, hopefully, help.
Alex Karasulu, also an ASF Member and CEO/Chief Technology Officer at OptDyn knows 2FA and digital signatures well. He created the first mobile One-Time Password (OTP) 2FA Apache Triple sec for digital signatures and code signing. Karasulu thinks “the code-signing process in the open source community could be greatly improved with more consistently applied 2FA procedures.”
“The problem isn’t that open source developers are lazy or reluctant,” Karasulu said, “It is that a standard mechanism for 2FA specifically around code signing does not exist. Some techniques exist to achieve this: git revisions can be signed and the process loosely protected with mandated 2FA accounts at GitHub, or GPG code signing keys can be stored on devices requiring a second OTP based factor to digitally sign anything including code and release checksums. There are many ways to skin this cat — but there is no standard making the process consistent. It’s essentially discretionary.”
Until it is standardized, Karasulu fears, “There may be no way today for open source organizations to mandate how committers manage access to their code/release signing keys. At the ASF, we use a Web of Trust model with multiple signers and a required release signing process mandated and monitored by the Apache Security team. That’s a lot more secure than using a single code signing certificate assigned by a CA to a single entity.”
Put it all together and what we have are built-in security problems, which still need to be solved. Some of the pieces are there, but until there’s more agreement on both the need and means to easily enable 2FA and digital signature security, both will continue to be weak spots in the open source software supply chain.
