The hardest question this tool faces is the fair one: the report is generated by the person it flatters, from a repository only they can see. attest signs it, which proves it was not altered after signing. It does not prove the repository is what they say it is.
The missing piece is a second person. A colleague who worked in the same repository can attest to something no self-issued report can: that this repository existed, that this person worked in it, and that the fingerprint they are signing matches the one they see from their own clone.
What to build. A flow where a second party produces a counter-signature over the report's fingerprint and hash, from their own copy of the repository, without either party sending code anywhere.
Done when
- The counter-signer's step is short enough that a busy colleague will actually do it. If it takes more than one command and a paste, it will not be used.
- The counter-signature covers the fingerprint and the hash, so it means "I see the same repository and the same report", not "I like this person".
verify reports counter-signatures and who made them, and states plainly what a counter-signature does and does not prove.- A report with none is not treated as suspect. Most will have none and that is normal.
- The threat model is written down: what this stops, and what two colluding people can still do. If it cannot stop collusion, say so in the README rather than letting a reader assume it can.
Out of scope. Any identity service, key registry, hosted verifier or web of trust. Whatever proves who signed is the same thing that already proves it for git commits, and if that is not enough, say so honestly rather than building an identity system.
This is the feature that would change what the tool is. Right now it makes a claim checkable for internal consistency. This would make it checkable against another human being, which is what "proof" normally means.
Taking this on: comment and it is yours. Nothing here needs permission first, and a partial answer beats a perfect one that never lands.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat.
The hardest question this tool faces is the fair one: the report is generated by the person it flatters, from a repository only they can see.
attestsigns it, which proves it was not altered after signing. It does not prove the repository is what they say it is.The missing piece is a second person. A colleague who worked in the same repository can attest to something no self-issued report can: that this repository existed, that this person worked in it, and that the fingerprint they are signing matches the one they see from their own clone.
What to build. A flow where a second party produces a counter-signature over the report's fingerprint and hash, from their own copy of the repository, without either party sending code anywhere.
Done when
verifyreports counter-signatures and who made them, and states plainly what a counter-signature does and does not prove.Out of scope. Any identity service, key registry, hosted verifier or web of trust. Whatever proves who signed is the same thing that already proves it for git commits, and if that is not enough, say so honestly rather than building an identity system.
This is the feature that would change what the tool is. Right now it makes a claim checkable for internal consistency. This would make it checkable against another human being, which is what "proof" normally means.
Taking this on: comment and it is yours. Nothing here needs permission first, and a partial answer beats a perfect one that never lands.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat.