[pietroglyph]

> impersonating Nat Friedman using a bug in GitHub's application.

This is not a bug, it's a part of how Git fundamentally works. If you want to mitigate it you have to sign your commits. GitHub could only attribute commits in the UI if they're signed, but I suspect that this is considered too much friction to enable.

[redrobein]

> how Git fundamentally works Honestly, given this, they should clearly label unsigned commits by default.

[jfrunyon]

They... do? Do you see the Verified note anywhere? It's not their fault if people don't understand how the tool they're using works at an extremely basic level...

[hvdijk]

They don't. The comment was on labelling. There is nothing in the presentation of unsigned commits to indicate that they are unsigned. The presentation is indistinguishable from that of a hypothetical GitHub that never shows commit signatures, you need to have seen a signed commit on GitHub at some point to know that the absence of that Verified note is significant.

[jfrunyon]

Correct. Which is also how git works. And there is a very good, very simple, reason for why both work this way: very few users sign their commits, even fewer want to/care about signing their commits, and even fewer verify those signatures.

[kelnos]

So few people sign their commits that the default is to assume commits are from where they say they are, even if they're not verified.

[jfrunyon]

Please let me know when you figure out what GitHub could reasonably do to make enough people sign their commits to change that default.

[jason_zig]

That's absolutely their fault from a product perspective.

[jfrunyon]

How do you figure? I don't consider "making the product which users want" to be a bad thing.

[scintill76]

That’s the opposite, labeling signed commits.