Repository navigation
Description
Problem
PR #4449's sibling PR #4432 (issue #3187, Phase 2 of design #3231) bounds home_declared world_id in SignedArtifact::parsed() (max 64 bytes, no whitespace-only, no control/format characters) and refuses duplicate endpoints. Local history is covered: replay of an existing log uses a lenient path (parsed_for_replay), so a world whose log already holds an over-bound declaration still reopens (pinned by the PR's a_legacy_home_declaration_still_replays test).
The peer-pull path is not covered (CodeRabbit Major on PR #4432, verified 2026-11-02): Directory::receive_artifact (pkgs/id/src/directory.rs:1380) calls the strict artifact.parsed()?, and the refusal ends the page in apply_page / the pull in pull_within. A peer whose signed chain contains a pre-upgrade declaration with an over-bound world_id therefore cannot be pulled past that entry — later artifacts from that account never apply. The declaration is signed and cannot be rewritten.
What is needed
A design decision, under design #3231's one-receipt-contract (the #3232 Phase 3 audit may be the right venue):
- Choose a trusted cutoff that marks pre-upgrade chain state for the receive path (candidates: per-account chain position/seq at upgrade time, a protocol/version marker, an explicit allowlist of known legacy artifact hashes) and name its authoritative source.
- Peer provenance alone is not a validation boundary, and the local replay path (
parsed_for_replay) must not simply be reused for pulled artifacts. - The strict bound keeps applying to genuinely new receipts either way.
Until that cutoff exists, PR #4432's strict-receipt behavior is the conservative default and its merge is held on this question (queue task 5758 parked with this issue as the resume condition).
Links
- PR fix(id/artifact): bound home_declared world_id and refuse duplicate endpoints (#3187) #4432 (held) · issue id(artifact): home_declared world_id gets only an is_empty check in parsed() — a 100 KB, whitespace-only, control- or bidi-bearing world_id is accepted and stored, and the same endpoint can be listed twice with different worlds #3187 · design issue Design: a signed artifact is validated as strictly as it is built — one receipt contract for pkgs/id artifacts #3231 · audit issue Phase 3 (audit) of #3231 — field-by-field receipt-validation audit for pkgs/id artifacts + contract statement #3232 · queue task 5758
Acceptance criteria
- A peer pull over a journal containing pre-upgrade home_declared entries completes (entries are migrated, skipped with a recorded reason, or surfaced as a typed error — not a halt of the whole pull).
- Regression coverage exercises a pre-upgrade home_declared entry through the pull path.
- Behavior for genuinely corrupt entries remains a hard error (the id(artifact): home_declared world_id gets only an is_empty check in parsed() — a 100 KB, whitespace-only, control- or bidi-bearing world_id is accepted and stored, and the same endpoint can be listed twice with different worlds #3187 strictness is not silently dropped).
Activity
dezren39 commentedon Nov 2, 2026
Intake review
Related: Follow-up of code issue #3187 (strict receive) per the title; sibling code issue #4457 is the Phase 3b follow-up of #3456 in the same area. No merged PR addressing the home_declared pull halt was found at this pass.
Notes: Labels at filing: kind/bug, priority/low, app/id. This pass adds status/needs-triage, effort/m, the acceptance section, meta/enriched. Priority stays low per the filer (upgrade-path edge, not a live-data halt).
Risks: Loosening receive strictness carelessly reopens the #3187 hole; the fix must distinguish pre-upgrade entries from corrupt ones by version/shape, not by ignoring errors.
Suggested approach: Reproduce with a pre-upgrade journal fixture, add the versioned migration/skip path in the pull, and pin both behaviors (old entry tolerated, corrupt entry rejected) in tests.
— fleet monitor intake enrichment, 2026-11-02.
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off (task 8402, re-handoff)
99 remaining items
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
agent-note:v1
event: picked_up
task: 9660 (repo-health-code-pilot, repo-worker-code; lane c8b9355e-319a-4640-8096-7ad19480d151)
state: claimed; freshly verified #4459 OPEN, no hard-stop labels, and no implementing PR; proceeding with the trusted-cutoff fix. The prior checkpoint names branch queue/9660-4459-trusted-cutoff and /home/user/git/fleet/9660, but that worktree is absent locally and will be reconstructed only after checking for preserved work.
dezren39 commentedon Nov 6, 2026
agent-note:v1
event: done
task: 9660 (repo-health-code-pilot, repo-worker-code; lane c8b9355e-319a-4640-8096-7ad19480d151)
state: PR opened as #6407; both targeted Rust regression tests pass. Fresh GitHub verification found PR OPEN with checks queued; task completed with outcome pr_opened, not merged.