Skip to content

fix: the documents say what this tool does about signing and about locking - #67

Merged
donislawdev merged 1 commit into
mainfrom
security/what-the-docs-claim
Sep 6, 2026
Merged

fix: the documents say what this tool does about signing and about locking#67
donislawdev merged 1 commit into
mainfrom
security/what-the-docs-claim

Conversation

@donislawdev

Copy link
Copy Markdown
Owner

Findings S3 and S6 of the outside security review. Both are about a document read by somebody deciding whether to trust something.

SECURITY.md was wrong about signing

It said:

The released binaries are not signed. Signing is not set up, the release notes say so, and your operating system will warn you.

Every part of that had stopped being true. release.yml writes release notes saying the Windows binaries are signed and the macOS ones are signed and notarised by Apple. internal/legal/codesign.go pins the certificate by the SHA-256 of its DER bytes. There is a whole guard family around the wording of those notes, and nothing was watching this one document.

The effect is not cosmetic. SECURITY.md is what a cautious person reads before deciding whether to trust a download. Telling them the signature they can see is not one the project makes is the exact reasoning that leads somebody to ignore a mismatch, or to skip a check they have been told there is nothing to do.

It now names which platforms carry a signature and which do not, and points at the provenance attestation beside the checksums. The guard reads those claims out of the release notes rather than from a list repeated in the test, so the two cannot drift apart again - and it fails rather than passes if it finds no sentence about signing to compare against.

Re-measured while there: repository secrets, zero, on 2026-09-06.

The locking setting never said what locking does not give

encryption described which readers open which scheme, and stopped there.

This is not a defect in the design, and the review that raised it said so. The salt comes from the run seed rather than from crypto/rand on purpose - a random one would give two runs of one recipe different bytes, which untouchable rule 3 forbids - and the password is written into the manifest because a locked fixture nobody can open checks nothing. Both are right for a tool that produces fixtures.

What was missing is the sentence where somebody meets it. aes-256 carries a meaning everywhere else it is written, and a person choosing it here gets an archive with no confidentiality at all: same recipe, same seed, same password gives the same key on any machine, and the password is written down beside the file.

The declaration carries the sentence, so tfg formats zip prints it and the window shows it beside the field. README.md says it too. The guard asks the declaration rather than the README, because the README is a third copy.

Guards

Two, both with mutations, both caught.

🤖 Generated with Claude Code

…cking

Two findings of the outside security review, both about a document being
read by somebody deciding whether to trust something.

SECURITY.md said the released binaries are not signed and that signing is
not set up. Every part of that had stopped being true: the release
workflow writes notes saying the Windows binaries are signed and the macOS
ones are signed and notarised by Apple, and internal/legal/codesign.go
pins the certificate by the SHA-256 of its DER bytes. There is a guard
family around the wording of those notes and nothing was watching this
document.

The effect is not cosmetic. SECURITY.md is what a cautious person reads
before deciding whether to trust a download, and telling them the
signature they can see is not ours is the reasoning that leads somebody to
ignore a mismatch. It now names which platforms are signed, and the guard
reads that from the release notes rather than from a list repeated here.

Re-measured while there: repository secrets, zero, on 2026-09-06.

The encryption setting described which readers open which scheme and
never said that a locked archive from this tool offers no confidentiality.
That is not a defect in the design and the review said so - the salt comes
from the run seed rather than from crypto/rand because a random one would
give two runs of one recipe different bytes, which untouchable rule 3
forbids, and the password is in the manifest because a fixture nobody can
open checks nothing. What was missing is the sentence where somebody meets
it: aes-256 means something else everywhere else it is written.

The declaration carries it, so both surfaces show it, and README says it
too. Two guards, two mutations, both caught.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@donislawdev
donislawdev merged commit 5688037 into main Sep 6, 2026
18 checks passed
@donislawdev
donislawdev deleted the security/what-the-docs-claim branch September 6, 2026 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant