Over the last year I’ve been trying to understand why GPG isn’t popular. Based on the features I think it’s a pretty valid thing. This article changed my mind.
Turns out GPG is too old ¯_(ツ)_/¯
I like signing my commits, it feels good to know that my identity is actually attached to my code. So I put in some work to reconfigure git to use a different signing tool, I didn’t think it would be such a big deal, turns out git fully intergrates GPG. I’m confused. Why does git need to be hardcoded to use GPG specifically?
What rule says we can’t have git configs like:
[sigining]
defaultMethod=minisign
[signing.minisign]
always=true
signCommand=minisign -S -s {secret-key-file} -x {sig-file-name} -m {target-file}
verifyCommand=minisign -V -P {public-key-file} -m {target-file}
Where the verifyCommand exits 0 if the signature is good and 1 if not.
I’m open to hearing cons. These are some I can think of:
- User’s have to configure git with each signing and verifying program
- Upstream security conserns from signing programs
- Signing programs changing their interfaces
I was all set to poopoo this whole suggestion, and I read your linked article, and now I’m convinced too.
So it’s difficult. Implement whatever-it-is in code is actually by far the easiest part. The hard part is the social aspect of getting everyone to do it. reddit wasn’t the best-functioning link aggregator, ActivityPub is far from the best-designed federation protocol, but they’re what everyone uses, so they win. gpg isn’t the best, but it wins, but unlike with reddit-until-a-year-ago or ActivityPub, this is a case where that’s not an acceptable outcome.
The only other input that I have is that it might be worthwhile to piggyback on existing key distribution infrastructure, like SSL certificates or people’s Signal addresses. I feel like that would increase the chance of adoption. But yes, I 100% agree with this message.