The archiving of the Gorilla Web Toolkit: A tale of two software security risks

Update: On July 17, the Gorilla Web Toolkit team announced a new group of Core Maintainers have joined to support the project and will be updating the project to support the latest Go version, implementing new GitHub features and updating documentation.

‍

Anyone that’s written an HTTP-based Go application in the past decade has probably reached for the Gorilla Web Toolkit at least once. The toolkit includes gorilla/mux and gorilla/websocket. mux is one of the most popular projects in the Go ecosystem, used in over 90,000 repositories, including staple projects like Cilium, Istio, and Open Policy Agent while websocket is a standards-compliant and widely used websocket library that can be found in projects like Kubernetes.

‍

But on December 9, 2022, the Gorilla maintainers made the difficult decision to put their projects into “archive mode,” prompting tens of thousands of Go developers to figure out next steps for their own projects’ HTTP needs. For those unfamiliar, archive mode allows for the project to remain accessible on GitHub, but as read-only, meaning that it will not be receiving improvements and could become a future security liability.

‍

This is one of the profound challenges with securing your software supply chain in a world where reliance on open source software is so great. Do you know if your organization is relying on any of the Gorilla projects? Will your organization continue to use them? For how long? If so, how will you ensure that the Gorilla Web Toolkit isn’t pulled into new projects your teams are working on?

‍

There are two security challenges worth highlighting:

‍

• The “Trusted Maintainer” Issue: The Gorilla Web Toolkit received interest from developers to support the project, but they "raised their hands … and then were never seen again".

• The Legacy Software Issue: Organizations relying on Gorilla Web Toolkit are faced with the security risk of using unsupported software.

‍

Tough decision: continuity vs. supply chain security

What’s interesting here is: the Gorilla maintainers had no shortage of offers to help. The current project maintainers weren’t just looking for fresh blood and warm bodies. They were looking for new contributors to show up and earn trust — contributors that could grow into maintainers.

‍

This excerpt from their explanation says it all:

‍

“‘No maintainer is better than an adversarial maintainer!’ — just handing the reins of even a single software package that has north of 13k unique clones a week (mux) is just not something I’d ever be comfortable with. This has tended to play out poorly with other projects.”

‍

It would have been effortless for the current maintainers to quietly transfer ownership to any of the dozens of volunteers that didn’t meet their criteria. Dependent projects could have avoided the scramble to find a replacement web toolkit and most of us would never know the difference.

‍

However, that transfer of power could result in the project ending up in the wrong hands. For example, last year Chrome was forced to remove “The Great Suspender” plugin used by over 2 million users after reports that the browser extension had been compromised and “potentially” installed malicious code and tracking software on users' systems. This happened after the original maintainer of the open-source project sold the code to an unknown group.

‍

Instead of making the easy decision, the Gorilla maintainers made the right call, the harder call — to do what’s best for the security of the ecosystem and archive the project.

Maintainers of widely used open source projects sit in critical positions in the software supply chain, and as an industry, we need to do better to support them and help them make tough decisions like this one.

‍

The broader question

How many software projects do you use that have chosen continuity over security? Do you even know if projects like this are in your production systems? How many times have you been aware of a maintainer handoff in your software supply chain?

‍

It’s difficult, but incredibly important, for consumers of open source software to understand when they should reevaluate their trust in the software in their supply chain. Not doing so opens the door for a potentially disastrous supply chain attack against your software.

‍

But stepping back, it’s unfortunate that open source maintainers have to face this tough decision in the first place. This latest scenario demonstrates that too many engineering teams continue to expect OSS to just happen — with prompt response to bug reports, and security hardened.

‍

We can do more as an industry to shape the course of open source software. Companies need to be providing their teams with work-time to contribute back to projects they rely on. While money was not cited as a concern here we should be financially supporting and hiring open source maintainers. We can promote the work they do, and we can highlight when the work of open source maintainers makes the world a more secure place.

‍

There is already progress on this front, OpenSSF’s Alpha Omega project is designed “to improve global OSS supply chain security by working with project maintainers to systematically look for new, as-yet-undiscovered vulnerabilities in open source code, and get them fixed.” Already the effort is helping major open source projects like Node.js with vulnerability remediation resources and emphasizing open source security standards and practices within the project.

‍

We'd be remiss if we didn't say thank you for all the work the Gorilla Web Toolkit maintainers have done up to this point.

‍

Next steps for Gorilla Web Toolkit users

We recommend you spend some time identifying which of your projects rely on these dependencies (and that they are using the latest version). The question of when software is "done" can be debated for lifetimes. Gorilla is battle tested and not an immediate concern to replace but it's best not to depend on unmaintained software for the long term.

‍

Your team should consider alternatives when starting new projects. The Go standard library is powerful but if your needs outgrow it there is Gin — a more "batteries included" web framework. It's also never too late to start using code gen via gRPC or OpenAPI.

A replacement for gorilla/websocket is not as straightforward. We are currently working to identify an alternative and will update this post with our recommendation soon.

‍

At Chainguard, we are committed to tackling software supply chain problems by providing developers and security leaders with the tools needed to build software securely proactively, not reactively. For example, Chainguard Enforce can provide customers with visibility into the use of the Gorilla Web Toolkit in their environments and develop a policy that allows you to prevent its future use. You can see our policy enforcement in action with this example for log4shell:

Don’t hesitate to reach out if you need any help or guidance as your teams begin to address this issue.