ci: exclude x.com and twitter.com from the docs link check - #612
Conversation
x.com answers the lychee bot with 403 Forbidden intermittently, so the Link Check job failed on PRs that never touched docs/introduction.md (#611 hit it on https://x.com/class_lambda while the same job was green on main days earlier). The links are valid in a browser; this is the same anti-bot behavior the job already tolerates for eprint.iacr.org, so it gets the same exclusion, plus twitter.com, which redirects there. Both patterns are anchored to the URL origin so a host that merely ends in "x.com" is still checked.
🤖 Kimi Code ReviewI'll review this PR diff focusing on the areas you specified. This is a small CI workflow change, but I'll examine it thoroughly. File:
|
| Priority | Issue | Location |
|---|---|---|
| Medium | Missing trailing regex anchor allows subdomain spoofing | Lines 88-89 |
| Low | Comment overstates anchoring precision | Lines 81-85 |
The change is functionally acceptable for a documentation link-checker (attack surface is low), but the regex precision doesn't match the comment's claims. Given this is CI infrastructure for a consensus client, defense-in-depth matters even in peripheral tooling.
Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt
🤖 Codex Code Review
Other than that, this looks fine. The PR only changes CI link-check exclusions, so I don’t see consensus-layer, memory-safety, or runtime performance risk in the actual client code path. Automated review by OpenAI Codex · gpt-5.4 · custom prompt |
🤖 Claude Code ReviewReview: PR 612 — Exclude x.com and twitter.com from docs link checkThis is a small, well-scoped CI-only change ( Correctness bug: regex isn't anchored to the host boundaryBoth patterns anchor the start (
That's the exact class of false-positive the PR description says it wants to avoid ("hosts merely ending in x.com are still checked") — the same problem exists symmetrically for hosts that start with the string plus extra characters. Any doc link to such a domain would silently stop being checked instead of being validated, undermining the PR's own "Correctness / Behavior Guarantees" claim that "every other external link in Suggested fix — require a path separator or end-of-string right after the domain: Everything else looks fine
Automated review by Claude (Anthropic) · sonnet · custom prompt |
Co-authored-by: Tomás Grüner <47506558+MegaRedHand@users.noreply.github.com>
Co-authored-by: Tomás Grüner <47506558+MegaRedHand@users.noreply.github.com>
Brings in #611 (real-crypto block-build benchmark) and #612 (docs link check). #611 was written against leanSig, so it needed porting onto the internalized leanVM XMSS this branch tracks: - `ValidatorSecretKey::generate_from_seed` now derives through `xmss::xmss_key_gen_from_seed`, which takes a 32-byte seed and a slot window and returns `Result`, instead of `LeanSignatureScheme::key_gen` over an `StdRng`. Git merged main's infallible `to_bytes` next to this branch's postcard one, which would not have compiled; the postcard form is the one the key files use, so it stays. - The benchmark key cache keys on `ETHLAMBDA_LEANVM_REV`. There is no `ETHLAMBDA_LEANSIG_REV` here: the build script emits only the leanVM revision now that leanVM owns the whole signature stack. - docs/benchmarking.md keeps this branch's single-revision header description and main's note that real-mode roots are reproducible per seed. The four fixture-driven spec suites still fail on `ValidatorPubkey length != 32`, as they did before this merge: the published leanSpec fixtures are still on the 52-byte scheme.
Brings in #612 and #611. #611 lands the real-crypto block-building benchmark on the same files this branch rewrites for leanVM's unified aggregate API, so most of the work was semantic rather than textual: - `seal_block`: #611 extracted the proposer-sealing path out of `BlockChainServer::propose_block` into `block_builder::seal_block`, which this branch had rewritten in place. Took the extraction and ported the rewrite into it, so the merge inputs carry a `SignerSet` claim per proof instead of a bare pubkey list. The claim is rebuilt from `block.body.attestations[i]`, matching what `on_block` rederives at verify time, and the length guard against the body stays. - `ValidatorSecretKey`: #611 added a leanSig-backed `generate_from_seed` and `to_bytes` that git merged in alongside this branch's leanVM ones, giving two of each. Dropped #611's, since leanVM now owns the scheme, and moved the benchmark key set onto the leanVM signatures: a 32-byte seed and an inclusive epoch range, with the pubkey read back off the secret. - `init_leanvm` is new on this branch and the benchmark never called it, so `ethlambda benchmark` would have panicked on its first proof. Real-crypto runs now initialize the prover the way the node does, without the arena. - Key cache entries and the report header key off the leanVM revision; `ETHLAMBDA_LEANSIG_REV` no longer exists. The forkchoice, STF and signature spec tests still fail on `ValidatorPubkey length != 32`: the published leanSpec fixtures predate the 52 -> 32 byte pubkey change. That is unchanged from this branch before the merge, and needs a fixture release rather than a code fix.
2 participants
🗒️ Description / Motivation
x.com answers the lychee link checker with 403 Forbidden intermittently, so the Link Check job failed on #611 for
https://x.com/class_lambdaindocs/introduction.md, a file that PR never touched, while the same job was green on main days earlier. The link is valid in a browser; this is the same anti-bot behavior the job already tolerates foreprint.iacr.org.What Changed
.github/workflows/pr-main_mdbook.yml: two lychee--excludepatterns for x.com and twitter.com (which redirects to x.com), anchored to the URL origin so hosts merely ending in "x.com" are still checked. The comment next to the existing exclusion explains why.Correctness / Behavior Guarantees
Only the project's two social links stop being checked; every other external link in
docs/is still validated. Internal links are unaffected (they are checked by mdbook-linkcheck2 in the build step).Tests Added / Run
Patterns checked against every URL in
docs/: they matchhttps://x.com/class_lambdaandhttps://twitter.com/ethlambda_leanonly;https://linux.com/xand GitHub links are not matched. Workflow YAML validated. The Link Check job runs on this PR itself since the workflow file is in its path filter.Related Issues / PRs
✅ Verification Checklist
No Rust changes;
make fmt/make lint/make testnot applicable.