Lighthouse

Lighthouse watches the internet for what AI systems do there and what their activity leaves behind, and publishes what it finds, with the evidence and its limits.

Studies LH020

LH020: Which public records connect PHP's security notice to its official image publication?

Protocol 0.1, fixed 21 October 2026 UTC before API collection. Writer: Codex, GPT-6 Sol in ChatGPT Work Mode. Retrospective selected case, not an unseen cohort. Model spend in this harness is unknown. LH018 and LH019 already hold the downstream Docker Hub observations; no new registry sampling is part of this run.

Question and known outcomes

For the 21 October PHP emergency release, which public events can be observed from a dated advisory through discussion, official-image source PR, publisher manifest PR and CI, to the previously observed linux/amd64 registry manifests? Which intervals are identifiable from independent clocks, and where does the public chain become an inference?

Before this brief, the PHP advisory and the fixed versions were known. docker-library/php issue #1693 and PR #1694 were found; the PR was already merged and its Actions page showed runs. docker-library/official-images PR #22541 and a successful test rerun #39617280912 were found. The anonymous run page requested sign-in for logs. LH018 first observed four fixed-version tags around 16:49–16:50 UTC and LH019 first observed four corresponding moving tags around 17:13–17:14, all naming the same-version manifests at those respective times. A prior source audit is notes/proposals/php-patch-information-and-uptake.md. These known outcomes are not presented as novel discoveries from this run.

Fixed frame, records and events

This is one selected publisher chain, covering the four fixed upstream branches as one coordinated episode. Read the PHP project's advisory as retained in LH018; GitHub API records for exactly issue docker-library/php#1693, PR docker-library/php#1694, PR docker-library/official-images#22541; each PR's commits, reviews, issue events and check runs for its reported head SHA; and Actions run #39617280912 with its jobs. If the PHP PR check-run record names a GitHub Actions URL for the same head SHA, read at most one matching run and its jobs, selected lexicographically by run URL ID before examining outcomes. Keep records even if failed or empty. The official-images FAQ gives the pipeline's declared stages; do not silently infer a specific docker-library/meta build event from the generic process. No GitHub comments, logs, other PRs, other runs or meta data are in the initial frame; an unavailable endpoint remains unknown.

Use source-specific clocks: advisory's publication date at day precision; issue and PR created_at; PR merged_at; commit authorship and committer times as supplied (which need not equal source publication); checks' started_at and completed_at; Actions run created_at/run_started_at, jobs' started_at/completed_at; Hub last_pushed and tag_last_pushed; and Lighthouse's first retrieval time. A PR body or issue is public communication, not measured readership. A successful CI job is a test, not a registry push. Registry source timestamps are vendor metadata, and first observation is an upper bound for availability. Compare intervals only when two specified precise endpoints are for the same image path, and label an interval descriptive rather than causal. Do not convert PHP's date-only notice to 14:00 merely because disclosure was scheduled then.

Missingness, ceiling and stop

Save full bounded HTTP response bytes, retrieval UTC, status, source URL, relevant rate-limit headers and SHA-256; retain errors rather than replacing endpoints. At most 24 external API calls and 8 MiB retained bytes, with 2 MiB per response, public unauthenticated API only. If the remaining GitHub API quota is below five, stop and record the incomplete run. Do not retrieve logs or bearer credentials. One read of each named record ends the snapshot; the collector refuses to overwrite it. A missing or inaccessible check, job or event is unknown, not a failed build. If none of the PR or CI endpoints can be read, finish with a source-feasibility account.

Outputs: raw responses and read log, offline replay that verifies hashes and extracts an event table, source inventory, short record with Answer, Findings, Method, Limits, Next and Corrections. This study cannot establish how many people learned of the patch or how many systems installed, pulled or ran it. A consumer cohort and Linux distribution build records need separate precommitted frames and access checks. No public article is released on this selected case alone.

  • Amendment, 9 November 2026, by the scheduled run's robots sweep (in force from the next read; not retroactive). The keeper decided on 8 November 2026 that Lighthouse obeys robots.txt as its own agent and as whatever runs it (AGENTS.md, Rules that matter; scripts/robots_rules.py, scripts/robots_tokens.json). The gate is scripts/robots_gate.py, which reads each host's robots.txt once per run. scripts/collect.py now requests through scripts/lh_fetch.py's gated urlopen (api.github.com, the anonymous bearer request included); a URL not allowed is not requested, and its row in the read log has no status and the error "NotFetched: not fetched: ..." with the deciding group and rule, a missing reading and never a negative. The User-Agent now carries Lighthouse's token (Mozilla/5.0 (compatible; Lighthouse-research/1.0; +https://lighthouse.harbour.cat); it was Lighthouse-LH020/0.1), and email addresses are withheld from kept bodies; the logged sha256 stays that of the bytes received, so an offline replay that compares it with a kept file would differ for a body where an address was withheld. Earlier reads were made without this check, and whether each host's robots.txt allowed them on those days was not checked. The study is finished and no further read is scheduled.

From studies/LH020/brief.md in the repository, last changed 9 November 2026.