This morning, the creator of go-bindata deleted their GitHub account and someone else created a new account under the same name.
When open source is at center stage for new innovations, the provenance and security of components is critical to the well-being of development practices in all industries.
As we saw with the removal of leftpad in #npmgate a few years back, even small components can have an enormous reach across an ecosystem.
When developers chose to publish their work, they are taking on an extraordinary responsibility...often unwittingly. They need to consider this when choosing how to secure their credentials and how to protect namespaces like GitHub ids because it's not just themselves they put at risk, the risk includes the entire ecosystem should they be compromised.
This distributed risk is not unlike vaccines. Getting the flu might be only a bother for you, but in reality, the life saved might be that of your grandmother who doesn't contract the virus on the holidays because you were yourself vaccinated and unaffected.
A hijack of a known GitHub ID as in this latest disclosure could lead to fake versions of popular components being published to the repository for everyone to consume. The new reality is that developers themselves are on the frontlines of modern security attacks. Their ids, if compromised or hijacked could be unwittingly injecting malware into an otherwise approved and sanctioned release of their components.
Response across the industry has been multifaceted with some users planning to use local cached versions of go-bindata, others questioning the trust of any open source components, and some attempting to track the provenance of components in GitHub:
The Central Repository has long required detached pgp signatures produced with published keys for any components pushed to the repository. This provides a permanent and audit-able secondary authentication mechanism that consumers can use to validate who created a component, and to validate the authenticity of a component itself. This is an under utilized capability of the repository as most consumers don't bother to validate, however it stands apart in the various component repositories that don’t even provide similar protections.
We will continue to track this issue at Sonatype and provide updates as they are available.