The honest bundle fails from a default Windows clone

[GiulioDER]

Not a verifier defect. A distribution one, and it lands on exactly the person this project is aimed at: the stranger who clones and replays.

Reproduction

On a clean machine with the Git for Windows installer defaults:

git clone https://github.com/egnaro9/vac-protocol.git
cd vac-protocol
python -m vac.verify fixtures/valid     # exit 1

Twenty reasons, all of this shape:

FAIL sha256-mismatch: evidence/bundle.json: manifest 64931fe8d466c2cf..., file a2433da20fdc0bfb...
FAIL sha256-mismatch: evidence/RESULTS.md: manifest d2beb88d2ef58ee6..., file 6598a891710e9c4e...

core.autocrlf is on by default in that installer, this repository carries no .gitattributes, so checkout rewrites every text artifact to CRLF and every sha256 in the manifest stops matching its file.

The bundle is honest, the manifest is honest, and the verifier is right to refuse what it was handed: the bytes really did change between your commit and my disk. Your CI is ubuntu only, so nothing upstream can see it. I hit it as the very first thing that happened when I re-cloned to work on #2, and spent a few minutes assuming I had broken something.

It is the same class as the encoding finding in #2, one layer out. There the same bytes produced opposite verdicts depending on the host codec. Here the same commit produces different bytes depending on the host's git config.

Two parts, because a fresh clone and an existing one need different things

.gitattributes with * -text turns the conversion off for every future clone. Verified end to end: cloning this branch with core.autocrlf=true yields LF artifacts and python -m vac.verify fixtures/valid exits 0, where the same clone of main exits 1.

tests/test_checkout_integrity.py is the named reason for the clones that already happened. A developer whose checkout is already converted currently gets twenty hash mismatches and no cause. This gives one failure that says what happened and the two commands that repair it:

git config core.autocrlf false
git rm --cached -r . && git reset --hard

It also pins the attribute itself, so dropping it later fails loudly rather than silently, on the same principle as the rest of your suite: a gate that cannot name why it fired cannot be audited.

Scope

The test file is new and the attribute file is new, so this touches nothing else and is independent of #2 and #3. It can land in any order, including first.

ruff clean. The three new tests pass here; the .gitattributes one fails against main, which is the point.