.gitignore's @checksum header validates nothing and is already wrong — a checksum that cannot fail

[bdelanghe]

---

kind: task
effort: 2
value: 40

Split out of #108, where two independent sessions hit it and both deliberately declined to "fix" it in passing.

.gitignore line 1 reads # @checksum: e902a214, and that value attests to nothing. It is a hardcoded string literal in the generator, copied into the output verbatim rather than computed from content — it appears twice in crates/xtask/src/main.rs, once in generate_full_gitignore()'s template and once in the --minimal header vec.

It is already wrong

crates/xtask/src/checksum.rs defines the real scheme: sha256 over the content with the header lines stripped, truncated to 8 hex chars. Computed that way against .gitignore as it stood before #111:

declared:  e902a214
computed:  c08f83bd     (header offset 2, i.e. what get_header_template("gitignore") implies)
           12f6369e     (offset 0)
           aed8936f     (offset 1)
           f7cdcad5     (offset 3)

No plausible offset produces the declared value. So the file has been carrying a false attestation, and nothing went red over it.

Nothing checks it

validate_file_checksum() exists and would catch this, but nothing calls it for this file. xtask gen-config --validate exits 1 with Error: No such file or directory before reaching any comparison, and no workflow validates the generated .gitignore at all.

There is also a header format mismatch that would make validation fail even if it ran: the file's header says @generated by xtask gen-config --minimal, while get_header_template("gitignore") expects @generated by xtask gen-files --file-type=gitignore. And the file has three header lines (the third being # Based on actual Git tree state) where the template describes two, so extract_content_without_header() would take the content from the wrong line regardless.

Why it is worth an issue rather than a quiet edit

This is the same shape as the bug #108 was about. A scanner that reported green having scanned nothing, and a checksum that reports integrity having verified nothing, fail identically: the artifact that is supposed to detect drift is itself the thing that has drifted, and its output is indistinguishable from the healthy case. Recomputing the literal to c08f83bd would restore the appearance of integrity while leaving it just as inert — the number would be right once and then rot again on the next edit, because nothing recomputes or compares it.

So the fix is a direction, not a value:

• Either make it real — compute the header at generation time via generate_header_with_checksum(), reconcile the format/offset mismatch above, and have something actually call validate_file_checksum() in CI (this is the option that makes the marker mean what it says);
• or drop the @checksum line from both generator sites and keep only @generated, which claims exactly as much as the system can currently back.

Either is defensible. What is not is leaving an 8-hex-digit attestation that no one computes and no one checks.

One adjacent thing, deliberately out of scope

crates/xtask/src/strict_file_validator.rs also lists Cargo.lock in a hardcoded pattern list. That is xtask's own file-audit skip list, it matches *.lock generically, and it has nothing to do with osv-scanner or with this header — noting it only so the next person greping for Cargo.lock after #108 does not re-litigate it.