Hacker News Reader

Comment by rasengan | Hacker News Reader

We are lucky that they decided to vandalize instead of hiding something. Remember, on Github you can actually submit your commit with another’s email, and github automatically puts the identity associated with the email allowing people to spoof.

Always sign your commits!

View on HN

> We are lucky that they decided to vandalize instead of hiding something.

We do NOT know this.

>> We are lucky that they decided to vandalize instead of hiding something.

> We do NOT know this.

Well, at least we know that the attackers wanted their activities to be noticed at this point in time.

I have reasons to suspect that this is a compromised account, in which case there should be enough forensics info to figure out what the scope of the damage is.

That’s not just on github. That’s totally a feature of git itself. You can set the email address to whatever you want.

Not knowing the details around this, but if they haven't done so, Github could add something to indicate whether particular commits were signed by the PGP key Github knows to belong to the user the commit claims it was authored by. A user could have a setting to enable Github warnings where there are commits supposedly authored by user but not signed. They could also always warn where there are commits authored by a user but signed by a key the user didn't inform Github of.

Likewise, I wonder if git differentiates signatures where the keys are set as trusted in gnupg, and those that are not.

> Not knowing the details around this, but if they haven't done so, Github could add something to indicate whether particular commits were signed by the PGP key Github knows to belong to the user the commit claims it was authored by.

They do this

Github could simply reject commits with email addresses not added to your account. As you need to verify every email you add to your account this problem would be solved instantly.

and be replaced by a bunch of other problems instead. E.g. no publishing of existing repos on Github if they happen to contain a commit with a non-linked address...

One wouldn't be able to upload an existing open source repo with loads of existing contributors. That seems to really go against Github's mission of being a universal, easy-access hub for open source git repositories.

> Github could simply reject commits with email addresses not added to your account.

Sure, if GitHub wanted to completely abandon the decentralized nature of Git and be a completely centralized system. Which it would love to, I'm sure, but I don't think the user base is quite ready for them to completely shut off any repository with any commits not made by Github users, and posted to GitHub through the account of the user who made the commit, which is what you are suggesting.

This would completely break you merging others' patches into your repository outside of GitHub (with git-am(1)).

Github already shows signed commits: https://help.github.com/en/articles/signing-commits

> We are lucky that they decided to vandalize instead of hiding something.

How on earth do you know they haven't done both?!

Git commit hashes are pretty safe.

To verify old hashes, with a backup. But anyone with access can just push a new commit with an arbitrary author field. Without code signing it'd be very difficult to tell who actually pushed it. (Probably GitHub has logs you could check, but if the attacker could get on the corporate network it'd just be a NAT IP, and more sophisticated attackers can spoof or MITM)

Aren't they changing the hash algorithm specifically because they're no longer safe?

Theoretically no longer safe, but to insert a compromise commit matching another one that looks like normal code is close to impossible.

If they had an SSH key only then signing would be a defense. But if the attackers got OAuth access, stolen credentials, or a personal access token to someone with access to the org, they could do everything through the web interface which is signed by a common Github key.

I trust that GitHub key less than personal keys for exactly that reason.

Commits made via the UI aren’t signed at all. There is no “common github key” for signing commits

https://github.com/aidanh010/test/commit/ebdf858ae90ab7d3ce5...

https://imgur.com/a/fSKnL9C

Isn't commit signing a bit like NuGet package signing? Not worth it unless _everyone_ does it all the time? Any valid commit doesn't necessarily invalidate unsigned commits. It only means this commit is really done by me, but it doesn't me the other commit wasn't done by me.

Yes, but there are organizations that require all commits to be signed.

When you sign git commit, you do not sign your diff but the whole source tree as you see it. Effectively, you're vetting all prior commits on the branch.

Thus maintainers usually sign merge commits and it's their job to confirm that commits don't do anything shady and come from people they claim to come from.

But github encourages merges through the website, which means they are not signed.

> Always sign your commits!

Unfortunately PGP is fundamentally broken. Any identity (email address) can be trivially DoS'd by anyone, because the keyservers are (by design) write-only databases which anyone can add to.

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...

I think that actually means the notion of keyservers are fundamentally broken, not PGP.

I don't need a key server for me to sign or validate that something was signed by who it said it was if exchanged my keys via a secure means.

GitHub’s PGP signing feature doesn’t make use of keyservers. You have to explicitly add a PGP key to your account for GitHub to acknowledge that your commits are signed.

They still pretty visibly log the push event with the identity of the user whose credentials were used, so what you're describing is pretty easy to spot.

I wonder if it was an actual outsider attack, or just a disgruntled (ex-)employee?

... and today PGP was poisoned

Link, please?

Probably this: https://www.zdnet.com/article/openpgp-flooded-with-spam-by-u...

It has no effect on GitHub, though, which doesn’t use keyservers as part of its validation process.

PGP still works fine. It's SKS that doesn't, but you don't need SKS to use PGP.

Reply on news.ycombinator.com