Pitfall SRI Minify Unquoted Attributes

Pitfall: check_sri_versions Undercounts After a hugo --minify Build

Tracked in #1252.

Symptom

check_sri_versions's data.files_with_sri_attributes count drops sharply (observed live on www.arleo.eu: 276 → 2) after the site is rebuilt via a raw hugo --minify CLI invocation, then recovers (2 → 276) after the next build_site MCP tool call rebuilds the same content.

data.findings / data.status are not affected — they stay accurate and "clean" throughout. Do not treat this as a security or integrity problem; it is a cosmetic undercount in a descriptive stat only.

Root cause

• build_site (internal/tools/admin/build.go) invokes hugo with --noBuildLock --cacheDir <dir> --cleanDestinationDir --destination <dir> — no --minify. Its HTML keeps quoted attributes (href="https://..."), exactly as authored in the theme templates.
• A raw hugo --minify CLI build (used by this deployment's external check-sri-versions.sh / deploy.sh on hugo-vm, not by this repo) enables tdewolff/minify's HTML minifier, which strips quotes from attribute values that don't need them by default. href=https://... (no quotes) is valid HTML5, not malformed markup.
• internal/tools/admin/sri.go's sriURLRe regex hardcodes quotes: (?:src|href)="(https?://[^"]+)". Against an unquoted tag it matches nothing, so that file's <script>/<link> pairs are silently dropped from the files_with_sri_attributes count — but the security-relevant findings path (data/sri.yaml lookup) is a completely separate code path and stays correct regardless.

Why this took so long to notice

This deployment's hugo --minify cron/deploy path had been failing on a separate, unrelated permission bug every single run for weeks — public/ is owned by the mcp-hugo-server-go systemd service account once build_site has ever run, and the cron job ran as jm, so its hugo --cleanDestinationDir call could never write there (chtimes ... operation not permitted). Minified/unquoted HTML never actually reached production until that permission bug was fixed (2026-08-22, see Live-Deployment-Runbook) — fixing it immediately exposed this second, previously-dormant regex bug.

Fix

internal/tools/admin/sri.go's sriURLRe needs to accept unquoted HTML5 attribute values, not just "..."/'...'. See #1252 for the suggested regex and a fixture-based regression test. Not yet fixed as of 2026-08-22 — this page exists so a future run of check_sri_versions with a low files_with_sri_attributes count isn't mistaken for a real regression before checking data.findings first.

Related

• AgentReady Pitfalls — same general class of "two different build paths produce two different outputs" pitfall, different surface.
• Live-Deployment-Runbook — the hugo-vm cron/deploy permission fix that exposed this.