As a creator, it is sometimes advantageous for me to deny some of my own work. I regularly use "fixup" commits and rebase them out of existence. I'd be mildly embarrassed to have all of them sticking around in code forever.

As a user of code published on Github, I sure as heck want there to be clear ownership and authorship of the code I use, and to be able to hold them accountable for malice. And there is lots malicious code on Github, trying to disguise itself as legit; Having a strong public persona isn't guarantee that my github code isn't malicious, but it does raise the stakes.

As a human who has seen what happens when people commit mistakes, we're very emotionally bad at dealing with mistakes. "Who broke the vase?" is a tough question to ask. "Who broke the build" can carry the same weight - Both very little, and very much, depending on when it's asked and how expensive the vase was. I'd like to think that making mistakes will be easier in a merkle-tree structured world; That as a collective, we will learn to do a better job of helping people admit their mistakes, come forward with them, and say "I made that mistake, and have learned from it". The internet has proven that false again and again.

In two important ways - People are unwilling to forgive, and people are unwilling to admit. Past minor mistakes haunt people forever all the time. Look at things like "Has Justine Landed Yet?"[1].

A malicious liar (We'll call them Eve) will deny, refute, and plain old lie in the face of whatever. There can be incredibly convincing evidence (A RSA-Key Verified Git Signature, for example) of... whatever, and it will be written off as "Harassment" by friends of Eve. Further: There's plenty of actual malice that passes itself off as not. Rapists say "She clearly wanted it, she got wet" - Criminals do that at all levels, making up excuses for why their victims deserved it.

Regardless - It is a sea change to be held accountable for your code. I do want it, but I do not believe that SSH key verification will achieve that. I think it will be a significant change when it does happen, though, and one with significant consequences.

[1]https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-t...

GitHub never deletes anything you push. Even if you rebase and force push, that old information is still accessible. Also why would you drag out such an ugly article to make a point?

Because this is a security question. Ugly questions need to be asked - Understanding how actual malice interacts with your security model is the whole point.

Say you’re writing some code that may be illegal (piracy stream, rips off another API with licensed content, etc). I would want to deny that it was me (but then, i wouldn’t connect it to my real-life identity at all).

It's that serious? Wouldn't the offended party just ask for the content/service/repo be removed?

With the digital footprint these days, that might impede employment in the future in certain industries or sectors, especially if it’s tied to your name.

>if it’s tied to your name

How can this be proved? Even with signing, anyone can impersonate anyone.

The entire point of the signature is that it can't be forged. If a commit is signed with your private keys, I can reasonably conclude you authored it.

I know this is a solved problem in certain contexts, but realistically how does a third party prove that your private keys are yours?

Because if you're signing your commits you're probably also the type of person to sign your email with the same key.

Adding a data point to your statistics: I sign commits and packages I maintain (when it applies), not my emails.

Obvious recent case is Tornado Cash.

is it not enough to sign it and burn the keys?

PGP encrypted public messages is common even on the dark web.

> As a maintainer, why would you want people to be able to deny making a given commit? or have them come in completely anonymously?

1. Because you trust code for what it is and are willing to trade attribution surety for a lesser ask of contributors

2. Because you care about certain principles of anonymity and non-repudiation and want to respect them in your own plainly legitimate project.

3. Because your project is or risks becoming illegitimate in some jurisdiction and you want to protect your contributors as best you can.

It'd be nice if we can continue to respect these reasons as valid even while allowing other maintainers to exercise different policies.

I don't see that any of those reasons are relevant, in all honesty.

1. This is not even a moderate ask; using ssh for git transactions is no more or less burdensome than https

2. As has been pointed out, there is no reason or reliable way to verify the identity of a creator's SSH key

3. Real-world example of such a project, or why this matters in the context of (2)?

> there is no ...reliable way to verify the identity of a creator's SSH key

GitHub exposes your public key via it's API. (Why? I have no idea. I call it a privacy violation) So, you need to create new github identity for every SSH identity that you wish to remain anonymous for, otherwise they just get tied together & one aspect of anonymity is lost.

All that does is associate an arbitrary SSH key with a GitHub account. There is still no reliable way to verify the identity of the GitHub account owner, or the SSH key that account holder generated.

How does that expose any more information than you do by pushing a commit with a GitHub account?