3 ms·
> 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 f
by swatcoder 4y ago
> 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.
- ndhlms 4y agoI 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)?
- cmroanirgo 4y ago> 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.
- ndhlms 4y agoAll 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?