repo show rewrites HTML at an immutable commit with Cloudflare challenge scripts

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 1mo ago ·closed by Colby Knox

Two adom-wiki repo show adom/tmf8829-depth-lab readme.html --ref f20b0b15ff7f8f9dce4029a997135f6950f22e56 reads produce different bytes at the same fixed Git commit. Both contain Cloudflare challenge script blocks (window.__CF$cv$params and /cdn-cgi/challenge-platform/scripts/precursor/main.js). Removing only those exact blocks produces identical SHA256 values. No challenge values or authentication material are included in the attached evidence.

This breaks source read/modify/push workflows: an AI may mistake transport-generated HTML for repository content, commit transient challenge scripts, or report a false concurrent-edit conflict. We caught it before publishing the encoder checkpoint. The downloaded README also contains an older challenge block; that alone does not establish whether it was already stored or added in transit.

Please provide a byte-faithful source path for HTML (for example a JSON/base64 Git blob response or an octet-stream source download excluded from HTML rewriting), and make repo show/clone use it. Verify the source blob hash and return an actionable AI hint/refusal when response content differs. Include a repeated-read test at an immutable commit and an HTML read/edit/push round trip. Route any required endpoint/edge configuration fix to wiki as appropriate.

Locally, only the recognized Cloudflare challenge script blocks were removed; authored HTML was preserved. This is a targeted workaround, not proof that arbitrary HTML response rewriting can be safely repaired by regex.

wiki-cli-html-transport-evidence.json

1 Reply

Colby Knox · 1mo ago

Shipped in adom-wiki 1.7.41, with your open question answered and one finding that makes this bigger than filed.

The answer to "already stored or added in transit": BOTH. Transit injection confirmed exactly as you reported (two reads at your immutable ref differ; the fetched content's git blob sha1 does not match the listing's hash for the file). And the byte-faithful archive copy of that readme.html, which matches the listing hash exactly, STILL contains one challenge-platform block, so a past read/modify/push cycle already committed injected scripts into your stored source once. Your caught-before-publish instinct was exactly right; a previous session's wasn't.

What 1.7.41 does, matching your asks:

Byte-faithful path: the whole-repo archive is that path today (ZIP bodies are never HTML-rewritten; proven by hash), and repo show now uses it automatically. Every read is verified against the listing's git blob hash; on mismatch the CLI recovers the file via the archive, re-verifies, warns TRANSPORT_ALTERED (naming what happened), and hands back only verified bytes. If even the recovery mismatches, it REFUSES with both hashes rather than returning altered content.
Repeated-read test: passes now. Two repo show reads at your ref return byte-identical content whose blob sha1 equals the listing hash.
The same guard covers incremental repo pull: fetched files that fail their hash check are never written to the working copy and are recovered through one archive, so the read/modify/push loop can no longer commit transit-injected scripts from either verb.

Routed to the wiki/edge side as adom/wiki#200 with the full evidence: the injection itself (the CF challenge platform rewriting /api text/html bodies, with the zone-rule / no-transform / octet-stream fix options), plus a suggested fleet sweep for committed challenge markers, since your repo will not be the only one that got poisoned before anyone was checking hashes. Cleaning the committed block out of your history is repo-owner surgery (push a cleaned readme.html); the CLI now guarantees the copy you edit is the real one.

Closing the CLI half; reopen if any verified read still disagrees across repeats on 1.7.41.