Perhaps build systems should not rely on URLs pointing to the same thing to do a build? I don’t see Github as being at fault here, it was not designed to provide deterministic build dependencies.
Right, GitHub isn’t a dependency management system. Meanwhile, Git provides very few guarantees regarding preserving history in a repository. If you are going to build a dependency management system on top of GitHub, at the very least use commit hashes or tags explicitly to pin the artifacts you’re pulling. It won’t solve the problem of them being deleted, but at least you’ll know that something changed from under you. Also, you really should have a local mirror of artifacts that you control for any serious development.
I think the Go build system issue is a secondary concern.
This same problem would impact existing git checkouts just as much, no?
If a user and a repository disappear, and someone had a working checkout from said repository of master:HEAD, they could “silently” recreate the account and reconstruct the repository with the master branch from their checkout… then do whatever they want with the code moving forward. A user doing a git pull to fetch the latest master, may never notice anything changed.
I sign my git commits with my GPG key, if you trust my GPG key and verify it before using the code you pulled - that would save you from using code from a party you do not trust.
I think the trend of tools pulling code directly from Github at build time is the problem. Vendor your build dependencies, verify signatures etc. This specific issue should not be blamed directly on Github alone.
Doesn’t that assume that the GitHub repository owner is also the (only) committer? It’s unlikely that I will be in a position to trust (except blindly) the GPG key of every committer to a reasonably large project.
If I successfully path-squat a well-known GitHub URL, I can put the original Git repo there, complete with GPG-signed commits by the original authors, but it only takes a single additional commit (which I could also GPG-sign, of course) by the attacker (me) to introduce a backdoor. Does anyone really check that there are no new committers every time they pull changes?
Tags can be GPG signed. This proves all that all commits before the tag is what the person signed. That way you only need to check the people assigned to signing the tagged releases.
Someone had my GitHub username or I registered my account a long time ago and didn’t add an email address/lost my password. The account was dormant (no repos). I emailed GitHub and asked to take the username and they gave it to me with no questions asked. I’m quite grateful for this.
As for the article: by this same logic it seems to me that you should also argue that domain names should be forever too…
In FreeBSD we heavily use GitHub in the ports tree. We have SHA256 on our distfiles so if someone acquired a previously active account and tried to serve malicious code from the repo it would fail. Several times I have caught projects changing their git tags via the ports tree throwing checksum errors.
affects any package manager that runs on tags. Simply tag malicious changes beyond the current release and it would be deployed to many users likely with little actual review.
We checksum the sources we use for packages at commit time for this reason. Actually GitHub tags frequently do change and have been a pain, sometimes unintentionally. Which is also why we have a distfile mirror, which avoids the original issue.
Perhaps build systems should not rely on URLs pointing to the same thing to do a build? I don’t see Github as being at fault here, it was not designed to provide deterministic build dependencies.
Right, GitHub isn’t a dependency management system. Meanwhile, Git provides very few guarantees regarding preserving history in a repository. If you are going to build a dependency management system on top of GitHub, at the very least use commit hashes or tags explicitly to pin the artifacts you’re pulling. It won’t solve the problem of them being deleted, but at least you’ll know that something changed from under you. Also, you really should have a local mirror of artifacts that you control for any serious development.
I think the Go build system issue is a secondary concern.
This same problem would impact existing git checkouts just as much, no? If a user and a repository disappear, and someone had a working checkout from said repository of master:HEAD, they could “silently” recreate the account and reconstruct the repository with the master branch from their checkout… then do whatever they want with the code moving forward. A user doing a git pull to fetch the latest master, may never notice anything changed.
This seems like a non-imaginary problem to me.
I sign my git commits with my GPG key, if you trust my GPG key and verify it before using the code you pulled - that would save you from using code from a party you do not trust.
I think the trend of tools pulling code directly from Github at build time is the problem. Vendor your build dependencies, verify signatures etc. This specific issue should not be blamed directly on Github alone.
Doesn’t that assume that the GitHub repository owner is also the (only) committer? It’s unlikely that I will be in a position to trust (except blindly) the GPG key of every committer to a reasonably large project.
If I successfully path-squat a well-known GitHub URL, I can put the original Git repo there, complete with GPG-signed commits by the original authors, but it only takes a single additional commit (which I could also GPG-sign, of course) by the attacker (me) to introduce a backdoor. Does anyone really check that there are no new committers every time they pull changes?
Tags can be GPG signed. This proves all that all commits before the tag is what the person signed. That way you only need to check the people assigned to signing the tagged releases.
[Comment removed by author]
Seriously, if only GitHub would get their act together and switch to https, this whole issue wouldn’t have happened!
I must have written this post drunk.
Someone had my GitHub username or I registered my account a long time ago and didn’t add an email address/lost my password. The account was dormant (no repos). I emailed GitHub and asked to take the username and they gave it to me with no questions asked. I’m quite grateful for this.
As for the article: by this same logic it seems to me that you should also argue that domain names should be forever too…
In FreeBSD we heavily use GitHub in the ports tree. We have SHA256 on our distfiles so if someone acquired a previously active account and tried to serve malicious code from the repo it would fail. Several times I have caught projects changing their git tags via the ports tree throwing checksum errors.
Worth noting we have a set of criteria around account inactivity/there must be no repositories with content/etc. around doing this.
people seem unaware of the
deptool for go which locks dependencies.We checksum the sources we use for packages at commit time for this reason. Actually GitHub tags frequently do change and have been a pain, sometimes unintentionally. Which is also why we have a distfile mirror, which avoids the original issue.