5 ms·

The security facepalm is the fact that you're pulling source code without signature verification. It's not github's responsibility to manage usernames. The blam

The security facepalm is the fact that you're pulling source code without signature verification. It's not github's responsibility to manage usernames. The blame and responsibility is on Go and whoever thought it's a good idea to pull in code this way. There are so many scenarios were you can end up cloning malicious code when you're simply relying on cloning alone. What if someone hacked the author's github account and committed malicious code? And why do you trust that the author has no plans in the future to inject malicious code?

mehrdadn 9y ago
> The security facepalm is the fact that you're pulling source code without signature verification. > And why do you trust that the author has no plans in the future to inject malicious code? Signature verification is used to protect against malicious authors now?
ashelmire 9y ago
Did you just say it's not github's responsibility to manage usernames on their own site? You're aware that attacks on similar names (not even exact ones) are a very common form of security attack, right? What signature verification would one have when accessing a public repo? If I tell somebody there's a really great tool at fakename/faketool, they are screwed.
- paxy 9y ago
  Github has the right to "manage usernames" however they see fit. The problem is that a third party is making assumptions about these usernames and basing their entire security mechanism on it, even though that assumption is incorrect, and now they're blaming Github for it.
- dumbneurologist 9y ago
  Not quite: his/her point is that it's on the user to validate the author as opposed to the location. If you care about security, you should pull from a repo, then check a against a signature. Your https connection confirms you got something from github, but you have the ability to prove the thing you got from github was from the same individual.
- craftyguy 9y ago
  > What signature verification would one have when accessing a public repo? You can gpg sign your git commits. This is not a new feature...
  - Zamicol 9y ago
    No, don't do that. Git's gpg signing function signs the commit hash, which is SHA1. Until git uses something other than SHA1, this is insecure. https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/ https://arstechnica.com/information-technology/2017/02/at-de... You can gpg sign code, but do not sign a SHA1 hash.
    - craftyguy 9y ago
      So the alternative is... do nothing? I understand the "omg sha1" frenzy, but 1) you still need an incredible amount of compute power to generate a collision (you read your linked article, right?) and 2) even if you make something that collides, it still has to compile into the project. Perhaps nation states can do this today. If that's your concern then, well, you've already lost because they've likely found other ways to compromise you with much less effort. For everyone else, sha1 for commits is still not _that_ bad.
      - Zamicol 9y ago
        >"incredible amount of compute power to generate a collision" That article sets the "best case", not the worse, and that article is "old". The GPU/ASIC industry is bananas, and we have no idea what other breaks there are. MD5 is a great example of how quickly these things become dangerous. SHA1 was a terrible choice when git was made, it's a horrific one now. SHA1 cannot be used for anything security sensitive. That domain is always larger than what we may first suspect. >the alternative is... do nothing? No, the alternative is to use gpg with a secure hash over and above anything git provides. This is a bad choice because there is no standardized git infrastructure built around anything secure. This fragments the industry (like Go building their own, again) where git could instead continue to unify, making an interface that has a lot of eyeballs, visibility, and a secure, universal implementation. Instead, fragmentation remains the solution. Git could have easily taken care of this by simply listening to people back in ~2005 saying, "gee, maybe we shouldn't use a hash that's already on its deathbed". https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html https://www.schneier.com/blog/archives/2005/02/cryptanalysis... It would be nice just have used SHA-256. I hope Snowden didn't show us nothing.

mehrdadn 9y ago

> The security facepalm is the fact that you're pulling source code without signature verification. > And why do you trust that the author has no plans in the future to inject malicious code? Signature verification is used to protect against malicious authors now?

ashelmire 9y ago

Did you just say it's not github's responsibility to manage usernames on their own site? You're aware that attacks on similar names (not even exact ones) are a very common form of security attack, right? What signature verification would one have when accessing a public repo? If I tell somebody there's a really great tool at fakename/faketool, they are screwed.

paxy 9y ago
Github has the right to "manage usernames" however they see fit. The problem is that a third party is making assumptions about these usernames and basing their entire security mechanism on it, even though that assumption is incorrect, and now they're blaming Github for it.
dumbneurologist 9y ago
Not quite: his/her point is that it's on the user to validate the author as opposed to the location. If you care about security, you should pull from a repo, then check a against a signature. Your https connection confirms you got something from github, but you have the ability to prove the thing you got from github was from the same individual.
craftyguy 9y ago
> What signature verification would one have when accessing a public repo? You can gpg sign your git commits. This is not a new feature...
- Zamicol 9y ago
  No, don't do that. Git's gpg signing function signs the commit hash, which is SHA1. Until git uses something other than SHA1, this is insecure. https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/ https://arstechnica.com/information-technology/2017/02/at-de... You can gpg sign code, but do not sign a SHA1 hash.
  - craftyguy 9y ago
    So the alternative is... do nothing? I understand the "omg sha1" frenzy, but 1) you still need an incredible amount of compute power to generate a collision (you read your linked article, right?) and 2) even if you make something that collides, it still has to compile into the project. Perhaps nation states can do this today. If that's your concern then, well, you've already lost because they've likely found other ways to compromise you with much less effort. For everyone else, sha1 for commits is still not _that_ bad.
    - Zamicol 9y ago
      >"incredible amount of compute power to generate a collision" That article sets the "best case", not the worse, and that article is "old". The GPU/ASIC industry is bananas, and we have no idea what other breaks there are. MD5 is a great example of how quickly these things become dangerous. SHA1 was a terrible choice when git was made, it's a horrific one now. SHA1 cannot be used for anything security sensitive. That domain is always larger than what we may first suspect. >the alternative is... do nothing? No, the alternative is to use gpg with a secure hash over and above anything git provides. This is a bad choice because there is no standardized git infrastructure built around anything secure. This fragments the industry (like Go building their own, again) where git could instead continue to unify, making an interface that has a lot of eyeballs, visibility, and a secure, universal implementation. Instead, fragmentation remains the solution. Git could have easily taken care of this by simply listening to people back in ~2005 saying, "gee, maybe we shouldn't use a hash that's already on its deathbed". https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html https://www.schneier.com/blog/archives/2005/02/cryptanalysis... It would be nice just have used SHA-256. I hope Snowden didn't show us nothing.