Begin with what a verifier does when it loads a keyring. It resolves a path, reads bytes, parses keys, then checks a signature against one of them. Ed25519 either verifies or it does not, and what it establishes is which private-key holder signed which bytes [1]. Nothing in that step says the keyring you just parsed is the one anyone reviewed.
In the first Ranex build the keyring and the gate catalog could be read from the working tree, so an uncommitted edit was a valid input to a verdict [4]. The project's stated control was review of the committed keyring, and the code had not made that true [4]. A control that lives only in a review checklist is a comment.
The second reopening is the more instructive failure. According to the record, the trust-root check skipped itself when the evaluated commit had no such path, and the path came from a flag, so the party being gated could name a catalog or keyring the commit did not carry and have it read unchecked [5]. Every reproduced route reduced to the same early return: absence got a pass, and the code returned without comparing anything [7]. The symlink case is the one worth copying into your own tests. A committed symlink sat at a reviewed name, and resolution followed the link before Git was asked, so the reviewed name was never the thing being checked [6].
ADR-002's answer is a bytes compare rather than a path check. It refuses any trust-root path the evaluated ref does not carry, compares the bytes Git records for the path as named against the bytes that would decide the verdict, and hands the committed bytes to the loaders [8]. The second half carries more weight than the first: the loader does not reopen the mutable path afterwards, because a compare followed by a second read gives two chances for different bytes to appear [9]. The project measured the change with strace, reporting one open per trust-root file after the fix where there had been three and two [10]. Count the gaps instead of the opens. Three reads leave two intervals in which the file can change underneath you, two reads leave one, one read leaves none [1].
This design depends on the trust root being a file whose bytes Git records, and on verification running against a ref rather than a directory [8]. Where policy lives in a service and keys in a KMS, the same question has a different shape: not which bytes decided, but which policy version answered and whether the caller chose it. The part that transfers without translation is the inventory the post asks for, which is every config that declares required checks, trusted identities, allowed commands or approval rules, plus the flags and environment variables that select those files, plus any loader that checks one path and reopens it later [12].
What the evidence here is: one project's own slice log, on a slice closed and reopened twice, where the reopenings came from audits showing the tests were narrower than reality rather than from failing tests [11][15]. No exploit in the wild, and no third-party reproduction of the strace counts [15]. The narrow claim it does support is the one worth carrying: signature verification answers who produced an observation, and only the evaluated commit can answer under which rule it was admitted [1][13].
