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.
Conversation
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.
1
2
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
Then there are the yearly major releases (for Chromium, every 6 weeks) where we have to port to a drastically different base OS.
The upstream tags are also signed for a similar reason. Due to lack GPG support for rotation, the keys for signing new tags essentially never change.
1
Due to how Git does it, you also have no way to publish new signatures for the older tags. The value of those signatures will decline over time. Git's signed commit / tag support is also based on signing a SHA-1 hash chaining to others which is problematic and needs replacement.
2
1
If signatures are in the merkle tree I don't think their value declines over time. Later signatures (by new key) attest that the earlier ones were made at a time when the old key was trusted. The history is like its own notary chain.
3
Tags aren't ever referenced by another tag. It's the commit the tag references that's potentially referenced by newer tags, but that's not how things end up working out for anything but our own standalone projects where we just have a long linear history with no branches/merges.
2
Yes I'm thinking of signed commits not tags. Signed tags are snake oil.
1
Signed tags are how you sign a release for a stable release with Git though. For the OS, we could stop signing anything but the tags for the manifest repository because we generate a frozen manifest referencing everything via the commit hashes. See github.com/GrapheneOS/pla.
1
That's what we link from grapheneos.org/releases#chang and our build instructions explains how to verify the signature of the manifest tag. Tags in the other repositories are still needed for development work and so Git isn't going to drop references to the commits for the releases.
