Right, and the latter are what GPG gets horribly wrong (in the ux department at least).
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
Unless you're going to reverify all those commits, I'm thinking re-signing them doesn't make sense. The best verifiability starts from storing them in incorruptible (widely distributed, offline, or immutable) ways.
1
1
They're signed so that someone can come along, clone the sources and verify that those are genuinely our releases. It's not signed for our own usage. The signed tags are pushed after we've already finished using the sources for that release since our builds are ready for release.
1
2
OK, so the idea is that you have that verifiability already and use the signatures to attest your belief that the code is sound (and matches the specified release) to its consumers? Makes sense.
1
Yes, so it would make sense for us to be rotating the key and signing them all with a new key so that it's possible for people to verify a historical archive of the sources. We don't want to attest to everything that might be in a Git repository being genuine, just specific tags.
The tags are our long-term archive of the sources. The vast majority of the repositories are downstream forks with patch sets to upstream code that are ported to each new stable release. It's regularly rebased to keep it as a clean sensible patch set that's actually maintainable.
1
1
For those downstream forks, they're based off of upstream stable tags based on stable branches. There's usually an underlying upstream stable branch that switches every few months to a new one without the past few stable tags in the history since it diverged at a different point.
1
Show replies