Entry four of #46 is answered, and this issue writes the answer down where a
decision lives. The answer, decided 2026-08-24: this board publishes
downloadable release artefacts, they are signed, and the release notes say they
exist for checking this board and are not part of what the organisation ships to
users.
The reason is the independent-verification argument. Somebody who has to build
the tool from the repository they are checking is in a weaker position than
somebody who downloads it, and most people who might want to check this board's
claims have no toolchain. Publishing source only would have cost exactly that.
The tension with the scope this board opened with is real and the record has to
carry it rather than resolve it by silence. That scope excludes anything a user
is asked to install, and the answer here is that the operator is somebody
checking this repository rather than somebody using a media server. The release
notes sentence is what holds the distinction, and its known weakness is that it
depends on people reading it. Both go in the record.
The second question entry four raises is answered in the same direction: the
artefacts are signed, not published with a bare checksum. A checksum
published next to the file it checksums proves the download arrived intact and
nothing about who built it. The keys are the ones operations#1609 sets up for
the working accounts, which is what makes this one key-custody story rather than
two: entry seven requires signed commits from the same keys, and answering the
two together avoids one custody story being written twice with different
answers. The record says where the keys come from, and it does not restate the
custody and rotation story that belongs to that issue.
The costs the record has to name, because a published artefact brings all of
them: signing, checksums, a bill of materials, a vulnerability surface, and an
expectation of continuity. #37 generates the notices and the bill of materials,
#41 builds the release workflow, #43 smokes the published artefact and #45 cuts
the first release, so this record is the decision those four are written
against.
What section three has to list: publishing source only, and publishing without
signatures. Section four says what each would have cost, and entry four of #46
sets both out.
Done when docs/decisions/0021-what-this-board-publishes.md exists on the
default branch, carries the four sections record 0000 fixes, says artefacts are
published and signed, names where the signing keys come from, carries the
release-notes sentence and says plainly that it depends on being read, names the
five costs above, and lists in sections three and four both rejected options with
what each would have cost.
Entry four of #46 is answered, and this issue writes the answer down where a
decision lives. The answer, decided 2026-08-24: this board publishes
downloadable release artefacts, they are signed, and the release notes say they
exist for checking this board and are not part of what the organisation ships to
users.
The reason is the independent-verification argument. Somebody who has to build
the tool from the repository they are checking is in a weaker position than
somebody who downloads it, and most people who might want to check this board's
claims have no toolchain. Publishing source only would have cost exactly that.
The tension with the scope this board opened with is real and the record has to
carry it rather than resolve it by silence. That scope excludes anything a user
is asked to install, and the answer here is that the operator is somebody
checking this repository rather than somebody using a media server. The release
notes sentence is what holds the distinction, and its known weakness is that it
depends on people reading it. Both go in the record.
The second question entry four raises is answered in the same direction: the
artefacts are signed, not published with a bare checksum. A checksum
published next to the file it checksums proves the download arrived intact and
nothing about who built it. The keys are the ones operations#1609 sets up for
the working accounts, which is what makes this one key-custody story rather than
two: entry seven requires signed commits from the same keys, and answering the
two together avoids one custody story being written twice with different
answers. The record says where the keys come from, and it does not restate the
custody and rotation story that belongs to that issue.
The costs the record has to name, because a published artefact brings all of
them: signing, checksums, a bill of materials, a vulnerability surface, and an
expectation of continuity. #37 generates the notices and the bill of materials,
#41 builds the release workflow, #43 smokes the published artefact and #45 cuts
the first release, so this record is the decision those four are written
against.
What section three has to list: publishing source only, and publishing without
signatures. Section four says what each would have cost, and entry four of #46
sets both out.
Done when
docs/decisions/0021-what-this-board-publishes.mdexists on thedefault branch, carries the four sections record
0000fixes, says artefacts arepublished and signed, names where the signing keys come from, carries the
release-notes sentence and says plainly that it depends on being read, names the
five costs above, and lists in sections three and four both rejected options with
what each would have cost.