Right, and the latter are what GPG gets horribly wrong (in the ux department at least).
This Tweet was deleted by the Tweet author. Learn more
Conversation
PGP has serious flaws such as inherently depending on SHA-1 and having a ridiculous amount of legacy cruft and bloat. The whole web of trust thing is pretty much harmful nonsense, at least as designed. GPG has serious implementation issues beyond all that. I've migrated away.
2
1
10
If the tool is going to automate one thing, it should be key rotation, and yet it doesn't even have that. I'm eventually going to retire my GPG key and I won't be moving to a new one due to lack of support for automated rotation. I simply won't be using it anymore. It's awful.
1
1
6
Just going to set up my email server to automatically reject PGP encrypted emails and send a response telling people to contact me on Matrix. Matrix and signify cover nearly all my use cases for it. If I ever actually want to encrypt a file anonymously, I'll use age for that.
1
2
6
The one thing I still do with GPG is signing Git tags. The Git wrapper simply signs the object's hash and makes it more difficult to properly verify the object with a specific key. I can't actually justify why I'm still doing that instead of using signify. Maybe I'll start now.
2
1
4
Or are you saying you would sign the commit hash on your own and store it separately?
1
I could sign the commit on my own and store it in a Git note. I would rather have detached signatures than having it as part of the object anyway. That doesn't make sense to me. What happens if I rotate the key and want to sign the previously signed tags with the new key too?
3
2
5
If I considered the previous key insecure, what am I supposed to do? Delete all of the tags, create them again and force push them with a new signature? The implementation really doesn't make sense to me. Also, no way to specify the key to use for verifying, as usual with GPG.
1
2
5
You don't need to force push to recreate tags with new signatures thought? You could delete all the tags and recreate with a new key `git push --tags`.
1
That's essentially force pushing them. What I mean is that the signature can't be updated without replacing the tag objects.
Yes and I agree, but the history isn't rewritten which people typically associate force pushing with.
1
From a receiving PoV it'll be less obvious to transition to compared to a tracked branch. If a clone already knows the tag, it won't fetch it by default. You need explicit git fetch --tags (--force) to make git even consider fetching remote tags into local tags with the same name
2