Files
at-container-registry/pkg
Evan JarrettandClaude Fable 5.1 61a934debb hold: look crew members up by rkey instead of walking the collection
ValidateBlobWriteAccess, ValidateBlobReadAccess, ValidateOwnerOrCrewAdmin
and getCrewTier each listed every crew record to find one member: open a
carstore session, walk the MST, CBOR-decode each record, compare DIDs.
That ran on every multipart call from the appview, including the part
URL request for every 10MB, and on every getBlob presign, so on a hold
with hundreds of crew each part cost hundreds of decodes.

lookupCrewMember tries the deterministic rkey first (one record read)
and only falls back to the walk on a not-found miss. The fallback is
required: records created before the hash-rkey scheme sit at a TID rkey,
and the boot-time migration that rekeyed them only existed between
e0a2dda and b2d6842, so a hold that upgraded across that window still
has them. Members hit the O(1) path; only genuine non-members pay for
the walk, and they are denied anyway.

Every authorization decision and error string is unchanged. Tests cover
the deterministic hit, a legacy TID-keyed member found only through the
fallback, a non-member, and a storage error surfacing as an error rather
than a silent denial.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Yf1ZVA7sXYhQNb9tCo1m5
2026-09-09 09:31:16 -05:00
..
2026-05-11 19:53:13 -05:00