Site copy in six languages says verify-gguf 're-checks the SHA-256 + size manifest stamped at export time'. It checks no size, and nothing reads the export-stamped record (CR-A18-009) #86

Wave 0 · theme D0-2: GGUF integrity chain: the .sha256 sidecar · highest severity High · 1 finding(s) · effort small

Summary

This adds new evidence to the already-reported item 'forgelm export never writes the .sha256 sidecar'. features.gov.gguf.body says verify-gguf re-checks a 'SHA-256 + size manifest stamped at export time': EN translations.js:1042 (inside Object.assign(T.en) from :945), TR :1147, DE :4477, FR :4523, ES :4569 and ZH :4615. i18n.js:96-101 replaces the static features.html:433 text, which describes the sidecar, with that string at runtime. What the code does: - Export does stamp {sha256, size_bytes} into model_integrity.json['exported_artifacts'] (export.py:219-226). - verify_gguf never opens model_integrity.json and checks no size. It only reads .sha256 (_gguf.py:103-151). - rg finds no consumer of exported_artifacts anywhere in forgelm/. The export-time record is write-only, and the cross-check the site advertises does not exist. - Even if it existed, it would be unkeyed (see the first finding).

Primary finding

CR-A18-009 — Site copy in six languages says verify-gguf 're-checks the SHA-256 + size manifest stamped at export time'. It checks no size, and nothing reads the export-stamped record

severity High · reachability default · intent contract-violation · confidence confirmed · independently confirmed · not reproduced (code trace) · already tracked: KNOWN-OPEN CLI-03 — docs/roadmap/phase-16-trust-surface-hardening.md:426-429,434-436

What happens. This adds new evidence to the already-reported item 'forgelm export never writes the .sha256 sidecar'. features.gov.gguf.body says verify-gguf re-checks a 'SHA-256 + size manifest stamped at export time': EN translations.js:1042 (inside Object.assign(T.en) from :945), TR :1147, DE :4477, FR :4523, ES :4569 and ZH :4615. i18n.js:96-101 replaces the static features.html:433 text, which describes the sidecar, with that string at runtime. What the code does: - Export does stamp {sha256, size_bytes} into model_integrity.json['exported_artifacts'] (export.py:219-226). - verify_gguf never opens model_integrity.json and checks no size. It only reads .sha256 (_gguf.py:103-151). - rg finds no consumer of exported_artifacts anywhere in forgelm/. The export-time record is write-only, and the cross-check the site advertises does not exist. - Even if it existed, it would be unkeyed (see the first finding).

Where.

• site/js/translations.js:1042
• site/js/translations.js:1147
• site/js/translations.js:4477
• site/js/translations.js:4523
• site/js/translations.js:4569
• site/js/translations.js:4615
• site/features.html:433 is not itself wrong: its static text correctly describes the sidecar. It is overwritten at runtime by data-i18n-html in site/js/i18n.js (~l…
• forgelm/export.py:207-228
• forgelm/verify/_gguf.py:103-151
• site/js/i18n.js:96-101

Evidence.

• rg -n exported_artifacts forgelm/ -> only export.py:226 (the writer). rg 'model_integrity|integrity.json|secret|hmac' over verify/_gguf.py and cli/subcommands/_verify_gguf.py -> no hit.

Recommended fix. Reword features.gov.gguf.body in all six languages to match features.html:433 (magic, metadata, optional sidecar, unkeyed). Alternatively, make verify-gguf look up the GGUF in the source model's exported_artifacts and compare sha256 and size, keeping in mind that this record is unkeyed too.

Acceptance criteria

• A regression test reproduces the failure scenario and asserts the corrected behaviour.
• Documentation listed above is corrected in English and in its Turkish mirror in the same PR.
• Every finding in this issue is resolved or explicitly closed with a reason.
• The release note names the contract this fix restores.

_{Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.}