Entry seven of #46 is answered, and this issue writes the answer down where a
decision lives. The answer, decided 2026-08-24: a commit on the default branch
has to carry a verified signature, effective as the account keys from
operations#1609 land.
The reason is that two claims are otherwise collapsed. That an account pushed a
commit and that a key signed it are different statements, and only the second
survives somebody else holding the account. Not requiring one costs nothing to
operate and rests authorship on the account, which is one credential and one
recovery route away from being somebody else's.
The costs are real, they arrive later than the decision does, and the record has
to name all of them because each one lands on somebody who did not take the
decision. A key has to be held somewhere and rotated eventually. An unsigned
commit anywhere in a branch's history refuses the merge rather than refusing the
commit, so the repair is rebuilding the branch rather than adding one more commit
to it, and it lands at the end of the work rather than at the start. Edits made
through the web interface and anything an automation authors are signed by the
platform's key or not at all, which decides what those routes can still be used
for.
The effective date is the part a reader will get wrong. A history already
carrying unsigned commits does not become signed afterwards, so this covers what
comes after the day it is set whatever was intended by setting it. The record
says that plainly rather than leaving a reader to believe the branch is signed
end to end.
This meets entry four, and that is why the two were answered together. Signing a
release artefact and signing a commit both need a key that is held somewhere and
rotated eventually, and the keys are the ones operations#1609 sets up for the
working accounts. One key-custody story, written once. This record names where
the keys come from and does not restate the custody and rotation story that
belongs to that issue.
Neither this board nor the board the parity work targets requires a signature
today, so parity settles nothing here and the ruleset walk in #55 points at this
entry rather than deciding it. The setting itself is a repository setting rather
than a change to this tree, so this record is the decision and #26 and #55 are
where the ruleset is walked. Read the current state rather than trusting this
paragraph:
gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
What section three has to list: not requiring a signature at all, and requiring
one from the first release onward. Section four says what each would have cost,
and entry seven of #46 sets both out.
Done when docs/decisions/0023-signed-commits-on-the-default-branch.md exists on
the default branch, carries the four sections record 0000 fixes, says a verified
signature is required and names operations#1609 as where the keys come from,
states the effective condition and that earlier history does not become signed,
names the rebuild-the-branch repair and what it does to the web interface and to
automation, and lists in sections three and four both rejected options with what
each would have cost.
Entry seven of #46 is answered, and this issue writes the answer down where a
decision lives. The answer, decided 2026-08-24: a commit on the default branch
has to carry a verified signature, effective as the account keys from
operations#1609 land.
The reason is that two claims are otherwise collapsed. That an account pushed a
commit and that a key signed it are different statements, and only the second
survives somebody else holding the account. Not requiring one costs nothing to
operate and rests authorship on the account, which is one credential and one
recovery route away from being somebody else's.
The costs are real, they arrive later than the decision does, and the record has
to name all of them because each one lands on somebody who did not take the
decision. A key has to be held somewhere and rotated eventually. An unsigned
commit anywhere in a branch's history refuses the merge rather than refusing the
commit, so the repair is rebuilding the branch rather than adding one more commit
to it, and it lands at the end of the work rather than at the start. Edits made
through the web interface and anything an automation authors are signed by the
platform's key or not at all, which decides what those routes can still be used
for.
The effective date is the part a reader will get wrong. A history already
carrying unsigned commits does not become signed afterwards, so this covers what
comes after the day it is set whatever was intended by setting it. The record
says that plainly rather than leaving a reader to believe the branch is signed
end to end.
This meets entry four, and that is why the two were answered together. Signing a
release artefact and signing a commit both need a key that is held somewhere and
rotated eventually, and the keys are the ones operations#1609 sets up for the
working accounts. One key-custody story, written once. This record names where
the keys come from and does not restate the custody and rotation story that
belongs to that issue.
Neither this board nor the board the parity work targets requires a signature
today, so parity settles nothing here and the ruleset walk in #55 points at this
entry rather than deciding it. The setting itself is a repository setting rather
than a change to this tree, so this record is the decision and #26 and #55 are
where the ruleset is walked. Read the current state rather than trusting this
paragraph:
What section three has to list: not requiring a signature at all, and requiring
one from the first release onward. Section four says what each would have cost,
and entry seven of #46 sets both out.
Done when
docs/decisions/0023-signed-commits-on-the-default-branch.mdexists onthe default branch, carries the four sections record
0000fixes, says a verifiedsignature is required and names operations#1609 as where the keys come from,
states the effective condition and that earlier history does not become signed,
names the rebuild-the-branch repair and what it does to the web interface and to
automation, and lists in sections three and four both rejected options with what
each would have cost.