Skip Navigation
Resources Blog The Hijacking of a Known GitHub ID: go-bindata

The Hijacking of a Known GitHub ID: go-bindata

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.

Screen Shot 2018-02-07 at 12.48.13 PM.png


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:

Screen Shot 2018-02-07 at 12.59.32 PM.png

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. 

Picture of Brian Fox

Written by Brian Fox

Brian Fox is a software developer, innovator and entrepreneur. He is an active contributor within the open source development community, most prominently as a member of the Apache Software Foundation and former Chair of the Apache Maven project. As the CTO and co-founder of Sonatype, he is focused on building a platform for developers and DevOps professionals to build high-quality, secure applications with open source components.