Bound tenant capability issuance by protected challenge time - #378
Conversation
Prepare the durable Phase A design for Delivery #377. Preserve the accepted database observation and signing boundaries; implementation remains pending the named draft PR decision approval.
|
Phase A design review is complete for Three separate AI specialists reviewed the complete Phase A and its owning source:
Reviewed PR-description SHA-256: The design retains database signing-observation time, adds the original protected challenge deadline to the existing minimum, and passes original creation time to the existing validator before KMS. The pure immutable-value factory takes over the current inline row decoder; UOW remains limited to mechanical same-transaction observation. Existing transaction cleanup, principal/key/binder authority and module budgets remain intact. No required design correction was found. The lead ran the mandatory package contract checker: PASS, 0 failures, including architecture constraints. Diff whitespace check passed. These are cheap design checks using Python 3.12.13 on Darwin, not implementation or locked baseline evidence. Specialists did not rerun these checks. Implementation, executable negative cases, actual module sizes and real issuer-to-native-binder composition remain pending. External KMS/observer services in that composition must be identified as simulated. The genuine expired-challenge test must retain fresh valid signing authority/receipt so another refusal cannot mask the challenge-window assertion. Earlier PR #376 results remain historical. This is AI Phase A design review only: no human semantic approval, implementation content clearance, baseline admission, final acceptance or merge authority is supplied. No expensive workflow has been requested for this design-only head. The other audit findings remain separate work. Next: present decision |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Phase A review
Verdict: no demonstrated design Blockers. Ready for the semantic-approval decision—not implementation acceptance or merge.
Reviewed head: 83d8c24a94554b8a1300adf012ce699496fe6f5c
Base: bb3fe718f16721165fcd1ac9cb634cf8fb2815c7
Decision: OFARM2-TENANT-CAPABILITY-DEADLINE-001, version 1.
The live head was rechecked before posting. This remains a draft with one changed file: the 143-line proposed docs/rfcs/OFARM_Tenant_Capability_Deadline_RFC_v0_1.md. The issuer fix and its tests have not been implemented at this head.
Blockers: 0. New Follow-ups: 0. No required design correction identified.
Why the design holds up
1. It fixes the actual defect without changing the time contract.
The current issuer calculates expiry from signing-observation time and key issuance end, then calls the validator without the original challenge creation time. ADR 0003 independently requires expiry to remain within the protected challenge's lifetime. Those paths disagree whenever signing observation happens later and key expiry does not happen to mask the error.
The proposed calculation resolves that disagreement:
issued_at = not_before = S
expires_at = min(
C + TENANT_CHALLENGE_MAX_AGE_MICROSECONDS,
S + TENANT_CAPABILITY_MAX_TTL_MICROSECONDS,
key_issuance_end,
)
Here, C remains the protected challenge creation time and S remains the database signing-authority observation. This preserves the existing limits rather than introducing a guessed safety margin, a replacement clock or a new signed field.
Sources at the reviewed head: issuer, ADR 0003 Time contract.
2. The transport design matches the accepted database interface.
The new observation must occur in a separate statement, on the same checked-out transaction, after challenge creation. The accepted observation contract explicitly requires this ordering; combining creation and observation into one expression would not preserve its visibility guarantee.
The database implementation already performs strict selection of the current backend/full-transaction CHALLENGE row and returns its original UUID and integer timestamp. A pure factory that checks the two returned UUIDs and constructs one immutable value is an appropriate consumer. There is no reason to add another database lookup, a cached deadline or a general adapter framework.
Sources: accepted observation RFC, V11 implementation.
3. Validation remains in the correct place.
The existing validator already owns the signed-time bounds, strict nonempty interval, maximum lifetime, future skew and protected challenge-time checks. Passing original C into that validator before signing serialization or KMS is sufficient; copying those predicates into a second validator would create unnecessary divergence risk.
The explicit rejection of None and booleans is important. None would otherwise disable the validator's optional challenge-time branch, while booleans must not be accepted as timestamp integers. The design also correctly requires rejection of an invalid C even when another expiry bound wins the minimum. Those cases are explicitly included in the proposed verification plan.
Source: validate_tenant_capability.
4. It preserves transaction and final-admission authority.
The existing UOW distinguishes capability refusal from binding refusal, rolls back or discards failed transactions, and discards non-idle connections before pool return. The proposed observation can fit into _bind without changing those ownership rules.
The RFC avoids an important overclaim: successful pre-sign validation does not guarantee successful later binding. Subsequent latency, clock movement, retirement or revocation can still cause the unchanged binder to refuse. Likewise, cancellation after KMS dispatch cannot prove that no remote signature occurred. These limitations are stated correctly.
Sources: UOW, proposed deadline RFC.
What still needs to be proved during implementation
These are existing acceptance requirements, not new Blockers against the design:
- Unmasked end-to-end evidence. A positive real delay must succeed through the actual issuer, signing reader, receipt verifier, signer, UOW and provisioned native binder. The genuine expired-challenge case must retain valid key authority and a fresh receipt so an unrelated refusal cannot masquerade as proof of the deadline fix. External KMS/observer simulations must remain labelled.
- Exact boundary and transport tests. Prove each winning expiry bound, equality refusal, the existing backward-skew boundary, malformed timestamps, masked out-of-range
C, UUID mismatch and immutable transport. Check the decoded signed payload—not merely that a helper was called. - Failure cleanup and complete replacement. Observation execute/fetch failures and pre-yield cancellation must expose no UOW and leave no contaminated reusable connection. Remove the superseded two-field construction and inline decoder rather than retaining defaults or compatibility paths. Actual module sizes and readability remain implementation-review questions.
Authority and verification limits
This is an implementation/conformance correction with a proposed implementation RFC, not a baseline-law amendment. No active baseline files, frozen capability contract, database authority, profile semantics or production-readiness claims need to change.
I performed a source/design review; I did not execute repository tests or package checks. The PR reports successful cheap design checks, but neither those results nor PR #376's historical evidence demonstrate that K-01 is fixed. That requires the implemented slice and its own evidence.
Proceed to the named semantic-approval decision. Do not close K-01 or treat this review as implementation clearance. This COMMENT is AI Phase A design review only: it supplies no human semantic approval, baseline admission, final acceptance, merge authorization or deployment authority.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Review — PR #378, "Bound tenant capability issuance by protected challenge time"
Head reviewed: 83d8c24a94554b8a1300adf012ce699496fe6f5c (draft, Phase A).
Base: bb3fe718f16721165fcd1ac9cb634cf8fb2815c7, confirmed an ancestor of the head and
identical to origin/main at review time.
Diff: one file, docs/rfcs/OFARM_Tenant_Capability_Deadline_RFC_v0_1.md, +143 / -0.
RFC: 143 lines, 8,098 bytes, sha256:c28f81237ccf75b7e1ad08630afe037ce4edef46c4e414094c41e0cd0f77867c.
This is the first review on the PR — GET /repos/samovers/OFARM2/pulls/378/reviews returns
count 0, and there is no pr-378-*.md on disk. One issue comment by samovers exists.
samovers authored the PR, so any review I post is a self-review: GitHub will only accept
COMMENT, and it does not satisfy the "independent design reviews" gate in the PR's
§ Verification and current status. That gate still needs a reviewer who is not this account.
Everything below was extracted from an anonymous clone of the PR head and measured, not read.
Checks ran on CPython 3.12.13 built from the v3.12.13 tag with the repository-pinned
Ruff 0.15.5 from requirements-review-tools.lock, so the real conformance gates executed
rather than refusing with UNSUPPORTED_PYTHON_VERSION. SQL ran on a live PostgreSQL 16.13.
Verdict
1 Blocker, 2 Should fix, 0 Preferences.
The design is right. K-01 reproduces exactly as the RFC describes, and the proposed formula
fixes it exactly as the RFC claims — I ran both against the real predicate and the real
validator and the boundaries land where the RFC says they land. The UOW containment claim is
also true, line for line.
The Blocker is arithmetic the RFC did not do. § Containment and simplicity argues fit against
the 520-line UOW module budget and the 180-line issuer module budget. Neither is the binding
constraint. The group budget is, and the change does not fit it.
Blocker
B-1 — The change exceeds the "capability signing" group budget, which the RFC never names
conformance/rewrite_architecture_check.py enforces GROUP_BUDGETS as well as
MODULE_BUDGETS. Measured at base bb3fe71:
GROUP capability signing: 991/1000 headroom 9
221 kernel/signing_receipt.py (module budget 250)
212 kernel/signing_authority.py (module budget 250)
89 kernel/google_kms_signer.py (module budget 120)
155 kernel/tenant_capability_issuer.py (module budget 180)
314 kernel/key_control.py (module budget 350)
GROUP tenant transaction: 932/940 headroom 8
412 kernel/tenant_command_runtime_bundle_selector.py (module budget 420)
520 kernel/tenant_uow.py (module budget 520)
The issuer's module budget is 180, so § Containment's "keep the issuer within its existing
180-line budget" reads as 25 lines of room. It is not. With the group at 991/1000, the
effective ceiling on kernel/tenant_capability_issuer.py is 164 lines — nine more than
today — and none of the other four group members is inside this Delivery's declared boundary.
EXC-006 sizes the issuer at "177 lines, subject to actual implementation review". I wrote
that shape and measured it. The patch does exactly what §§ One immutable challenge value and
Deadline calculation prescribe and nothing else: import the second existing named limit; add
the third required field; add the pure two-row factory that takes over the creator-row decode
and the exact-UUID join; add the C + TENANT_CHALLENGE_MAX_AGE_MICROSECONDS term to the
existing min(); add the exact-type guard before arithmetic; pass original C to
validate_tenant_capability. It lands at 176 lines — one under the RFC's own estimate:
$ wc -l kernel/tenant_capability_issuer.py kernel/tenant_uow.py
176 kernel/tenant_capability_issuer.py
520 kernel/tenant_uow.py
$ /tmp/venv13/bin/python -m ruff check kernel/tenant_capability_issuer.py kernel/tenant_uow.py
All checks passed!
Then the real gate:
$ /tmp/venv13/bin/python conformance/rewrite_architecture_check.py # patched
FAIL capability signing: 1012 production lines exceeds group budget 1000
$ /tmp/venv13/bin/python conformance/rewrite_architecture_check.py # base bb3fe71, control
rewrite architecture constraints: PASS
Base passes; the RFC's own minimal change fails, by 12 lines. On the RFC's stated 177 it fails
by 13. This is not sensitivity to how tightly I wrote the patch — the gap between 9 lines of
available headroom and the ~21 lines the design needs is not closable by formatting. The
smallest faithful factory alone is 16 lines.
There is no offset inside the declared boundary:
- EXC-004's removals ("the superseded two-field construction and inline UOW challenge
decoder") are both inkernel/tenant_uow.py, which is in group tenant transaction.
They pay nothing into capability signing. This is the same asymmetry that showed up on
#362: an offset offered against the wrong accounting unit. - The other four group members are not in § Expected areas, and EXC-006 forbids "budget
changes or unrelated cleanup"; EXC-002 forbids a new module. - § Expected areas and non-effects explicitly lists "module budgets" among the non-effects.
So as written the Delivery cannot land. This is a Blocker against the PR's own EXC-006, which
asserts the change fits the existing caps, and against § Expected areas and non-effects, which
promises no budget change.
Counter-argument I considered and rejected. "177 lines, subject to actual implementation
review" could be read as deferring the sizing question to Phase B. I do not think it survives:
the sentence exists to demonstrate fit, the number it offers already fails, and the remedy —
whichever it is — changes the Delivery's non-effects list, which is a Phase A decision, not an
implementation detail. Phase A needs to say now which of these it is: raise the group budget
(an admitted non-effect change), pay for the lines by shrinking another group member (an
admitted scope expansion), or place the factory somewhere outside the group (an admitted new
module, against EXC-002).
For the record, the UOW side of the same arithmetic is fine (see N-2).
Should fix
S-1 — The frozen validator fails open on challenge_created_at_unix_microseconds=None
§ Deadline calculation calls validate_tenant_capability "the single owner of integer bounds,
skew, strict nonempty interval, expiry and challenge-age checks". It is that only when C is
not None. Every challenge check sits inside if challenge_created_at_unix_microseconds is not None: at deployment/postgresql/tenant_contract.py:664. Measured against the real validator,
holding a K-01-shaped capability fixed:
== hostile C types reaching the validator ==
C=None ACCEPT <-- validator did not refuse
C=True REFUSE(challenge time must be signed int64)
C=False REFUSE(challenge time must be signed int64)
C='1788000000000000' REFUSE(challenge time must be signed int64)
C=1788000000000000.0 REFUSE(challenge time must be signed int64)
C=9223372036854775808 REFUSE(challenge time must be signed int64)
C=-9223372036854775809 REFUSE(challenge time must be signed int64)
C=9223372036854775807 REFUSE(challenge time cannot add lifetime)
Every other bad type refuses. None alone is silently ignored, and a capability minted with
C=None would be signed with exactly the K-01 window and no error. So the issuer's own
type(challenge.created_at_us) is not int guard is not defence in depth — it is the whole
barrier, and the frozen validator will not catch a regression that removes it.
INV-003 currently reads as though the validator does the refusing. It should say the opposite:
require a test that asserts the validator accepts with C=None on an otherwise valid
K-01-shaped capability, so the guard's load-bearing status is pinned by a test rather than left
to a reader of the code. Otherwise a future edit that drops the guard passes every listed
invariant. Not a Blocker: the design as specified does refuse None before signing.
S-2 — TENANT_CHALLENGE_MAX_AGE_MICROSECONDS is not in tenant_contract.__all__
§ Deadline calculation says "use the two existing named limits". They are not equally public:
deployment/postgresql/tenant_contract.py:38: TENANT_CAPABILITY_MAX_TTL_MICROSECONDS = 60_000_000
deployment/postgresql/tenant_contract.py:40: TENANT_CHALLENGE_MAX_AGE_MICROSECONDS = 60_000_000
TENANT_CAPABILITY_MAX_TTL_MICROSECONDS in __all__: True
TENANT_CHALLENGE_MAX_AGE_MICROSECONDS in __all__: False
I checked whether this is enforced. grep -rn "__all__" conformance/ finds three sites; none
of them covers deployment/postgresql/tenant_contract.py, and the patched tree's only gate
failure is the group budget, not an import rule. So this is not a Blocker.
It still needs a Phase A answer, because both available fixes touch the non-effects list.
Either add the name to __all__ — a one-line edit to a module § Expected areas does not list
and § non-effects freezes as the "shared validator" — or state in the RFC that the issuer
imports a deliberately unexported constant and why that is acceptable. Phase B should not be
left to choose.
Checked and decided were not findings
Recorded so the next reviewer does not re-spend the time.
N-1 — K-01 reproduces exactly, and the proposed formula fixes it exactly.
I loaded ofarm.valid_tenant_capability_time_window verbatim from 0001_initial.sql:5855-5882
into PostgreSQL 16.13 and drove today's formula (min(S+TTL, E)) against the RFC's
(min(C+AGE, S+TTL, E)), with C = 1788000000000000, a long-lived key, and a bind-time
observation obs = S + bind:
delay | bind | today | rfc | rfc_window_us
----------+--------+-------+-----+---------------
0 | 0 | t | t | 60000000
1 | 0 | f | t | 59999999
1000 | 0 | f | t | 59999000
1000000 | 0 | f | t | 59000000
30000000 | 0 | f | t | 30000000
59999999 | 0 | f | t | 1
59999999 | 100000 | f | f | 1
60000000 | 0 | f | f | 0
Today's issuer refuses at a one microsecond observation delay; the RFC's formula accepts
through 59,999,999 µs and refuses at exactly 60,000,000, and correctly refuses when the bind
arrives after the 1 µs window closes. The Python side agrees term for term against the real
validate_tenant_capability: today=REFUSE(expiry exceeds challenge lifetime) from delay 1
onward, rfc=ACCEPT to 59,999,999, rfc=REFUSE(times must satisfy issued-at <= not-before < expires-at) at 60,000,000. With a shorter key end E = C + 10s, both formulas accept to
9,999,999 µs and refuse at 10,000,000 — the E term wins where it should. Backward observation:
S = C − 5,000,000 accepts, S = C − 5,000,001 refuses with "issued-at predates challenge
skew", matching INV-003's stated boundary. Out-of-int64 C refuses even when another bound wins
the min(), as § Deadline calculation requires.
N-2 — "the proposed nine-line UOW block replaces nine existing lines" is exactly true.
The existing block is kernel/tenant_uow.py:427-435 (fetch, shape check, two-field
construction) — nine lines. The minimal replacement (creator fetch, observer fetch, factory
call) is nine lines. kernel/tenant_uow.py stays at 520/520 and group tenant transaction
at 932/940. The _uuid helper stays live at lines 151, 155 and 254, so moving the challenge
decode out does not orphan it. EXC-004 and the § Containment claim both hold.
N-3 — S really is a database observation, not a receipt timestamp.
§ Deadline calculation's paragraph on clock domains is accurate. observed_at_us is a column
of ofarm.observe_signing_authority() (kernel/signing_authority.py:59, 162-166), and the
receipt is verified against it (now_us=authority.observed_at_us, line 205), not used as it.
_validate also guarantees issuance_start_us <= observed_at_us < issuance_end_us, so E > S
always and the E term can never produce an empty interval on its own.
N-4 — Role posture on the new statement. This is where this series has hidden Blockers
before, so I checked the grants rather than assuming. ofarm.current_tenant_challenge() is
granted EXECUTE to ofarm_app, ofarm_worker (0011:89-90) — the identical set that holds
EXECUTE on ofarm.create_tenant_challenge() (0001:6451-6452). Any connection that can
create the challenge can read it back. No new grant, no new role, no provisioning change.
N-5 — The TenantUnitOfWork shape pin is not in the way. _tenant_uow_class_violations
pins the public surface, __init__ parameters and __slots__ of the TenantUnitOfWork
class. _bind is a method of TenantUnitOfWorkManager. The patched tree produced no
kernel/tenant_uow.py:<line>: failure.
N-6 — Test budgets are not a constraint. Issuer tests fall under
kernel/tests/*signing*.py (test_google_kms_signing.py, 195/800, the only existing test
module that mentions TenantChallenge) and kernel/tests/*tenant_uow*.py
(test_tenant_uow.py, 688/800). There is no test_tenant_capability_issuer.py yet; a new one
would match *signing*.py only if named accordingly, otherwise it falls outside TEST_GLOBS
entirely. Either way the INV-001..006 suites fit.
N-7 — The audit citation and ERRATA disposition are accurate. audits/kernel-2026-09-06/ REPORT.md:42 states K-01 in the same terms the RFC uses, including the counterexample at
1 µs / 1 ms / 1 s and the note that the existing 30-second fixture minter is why the
integrated test missed it. Its § Smallest acceptable remedy — database-authoritative deadline,
retain key-retirement and lifetime bounds, validate before signing, add a real-issuer-to-binder
test with delayed observation, do not weaken the binder or guess a shorter TTL — is what this
design does, point for point. ERRATA.md E-010 exists, is dated 2026-09-06, is classified
CONTRACT_GAP, and says "K-01 remains open until the separate issuer consumer caps expiry and
passes real-issuer-to-binder tests". Nothing is overclaimed.
N-8 — The PR body's executed checks reproduce at the head.
$ /tmp/venv13/bin/python conformance/ofarm_pkg_contract_check.py
rewrite architecture constraints: PASS
RESULT: PASS (0 failures)
$ /tmp/venv13/bin/python conformance/rewrite_architecture_check.py
rewrite architecture constraints: PASS
$ /tmp/venv13/bin/python conformance/temporal_contract_candidate_check.py
TEMPORAL CANDIDATE PASS: CONFORMANT_CLASSIFIED
$ git diff --check bb3fe71...83d8c24
(clean)
The temporal check is a bonus the PR did not claim. The linked
docs/rfcs/OFARM_Tenant_Challenge_Observation_RFC_v0_1.md resolves.
N-9 — Formatting is neutral. ruff format --diff reports "2 files would be reformatted"
for tenant_capability_issuer.py and tenant_uow.py at base as well as patched, so the
repository is not clean under stock Ruff formatting and my patch adds no delta. Not a finding
against this PR.
N-10 — Statement ordering. create_tenant_challenge() calls pg_current_xact_id(), which
assigns, so pg_current_xact_id_if_assigned() in the reader is guaranteed non-NULL in the same
transaction, and the reader's context_state = 'CHALLENGE' predicate matches the row the
creator just inserted. The RFC's insistence on a separate statement is correct: the creator's
row is not in a combined statement's snapshot, and the STABLE reader would fail closed.
What my method made easier than production
- The patch is mine, not the author's. I wrote the smallest thing I believe satisfies
§§ One immutable challenge value and Deadline calculation and measured that. It came out at
176 lines against the RFC's own 177, so B-1 is not an artifact of a bloated reproduction —
but an author could shave a line or two. They cannot shave twelve. - I never ran the issuer. No KMS, no signer, no receipt verifier, no binder, no provisioned
roles, no pool. My expiry evidence feeds chosen integers for C, S and E into the real
validator and the real predicate as pure functions. It says nothing about whether a live
create → observe → mint → bindsequence produces those integers, which is exactly what
INV-006 exists to establish and what no evidence in this PR yet covers. - The SQL fixture is deliberately bare. I loaded lines 5855-5882 of
0001_initial.sql
verbatim into an empty schema — no roles, notenant_binding_context, no
create_tenant_challenge, nobind_tenant_capability. That makes the arithmetic honest and
everything else absent. It proves nothing about reachability, snapshot behaviour, RLS, locks
or the bind path. The six-object fixture would be needed for those. - PostgreSQL 16.13, not the locked 17.10. The predicate is
IMMUTABLE STRICTpure numeric
SQL, so I do not think the version matters here, but I did not verify that it doesn't. - CPython 3.12.13 built from the
v3.12.13GitHub tag on x86_64 Linux with GCC 13.3, not
the locked baseline toolchain. It satisfies_authenticate_full_execution_profile; I checked
nothing else about equivalence. - I did not run the kernel test suite or regenerate
review_baseline_test_inventory.json
(4,194 entries at this head), so I have said nothing about test-count deltas. - I did not attempt the neutralize-and-rerun experiment, because this PR adds no checker
exception to neutralize.
What Phase A needs before it can reach zero Blockers
One decision, stated in the RFC and reflected in § Expected areas and non-effects: how the
capability-signing group budget gets paid. The three candidates each change something the
Delivery currently promises not to change, so none of them is a Phase B detail.
S-1 and S-2 are edits to this document and to INV-003; neither changes the design.
Address PR #378 review B-1 for Delivery #377 by planning removal of the issuer single-use construction helper. Preserve existing module, group and function limits, nonce evaluation order, authority boundaries and version-1 semantic scope. Clarify existing None-refusal evidence and named constant imports. Implementation remains pending semantic approval.
|
Addressed B-1 in the proposed design at The aggregate-budget finding was valid: the earlier 177-line issuer estimate would produce 1013 capability-signing group lines against the existing 1000 limit. The corrected RFC and Phase A name the module, aggregate and function caps and withdraw that fit claim. The proposed remedy stays in the issuer: remove the single-use Static candidate-text measurements are issuer 161/180, capability-signing group 997/1000, UOW 520/520, tenant-transaction group 932/940, and mint 75/80. Payload construction AST is identical between candidate shapes. These are feasibility projections, not an executed implementation or a full conformance result. No budget, other signing-group member or trust boundary changes. The optional suggestions are clarified: the existing direct None-input test must assert CapabilityMintError and zero KMS calls; the existing challenge-age constant is imported explicitly without editing tenant_contract or all. Two separate AI specialists performed focused review of B-1 and affected invariants only:
Both bind this exact corrected head, RFC SHA-256 Mandatory package checker: PASS, 0 failures, including architecture constraints. Diff whitespace check: PASS. These corrected-design checks ran with Python 3.12.13 on Darwin. No expensive hosted baseline was requested; no production issuer/UOW code, tests or frozen authority sources changed. Decision Next: present the refreshed complete version-1 card in the same Codex task, replacing its earlier presentation, before implementation. |
Complete Delivery #377 within signing and capability issuance. Join the accepted current-transaction observation into one immutable challenge, validate original creation time before KMS, and retain all three expiry limits. Remove the single-use payload helper to preserve existing aggregate budgets. Add real issuer-to-native-binder and failure evidence, isolate key lifecycle fixtures, and regenerate the complete 4269-test inventory. Governed routes, database and custody authorities remain unchanged.
PR #378 — coordinated exact-head content reviewZero Blockers, zero new Follow-ups, zero Preferences. This consolidates three independent AI specialist portions of one full content review, with lead validation. It is neither human approval nor baseline admission.
The approved implementation preserves original challenge creation C, sets issuance/not-before to the database signing observation S, and chooses expiry as the minimum of S plus the existing capability TTL, C plus the existing challenge age, and key issuance end. The unchanged validator receives C and S before encoding or KMS. The binder retains final admission authority. Independent review and evidence
The lead inspected all three reports and the complete production diff, verified clean local HEAD and matching remote PR/base/head, and confirmed the final PR description matches the published file. No proposed Blocker remains requiring independent reproduction. Supplemental local integration evidence comprises 26 passing live issuer/native-binder/observation cases and 40 passing existing UOW/concurrency/runtime regressions. The 26-case record was captured on the uncommitted implementation tree and hashes the listed test/support files; it is not relabeled as full-source exact-head execution. It used Darwin Python 3.12.13 with three independent Linux ARM PostgreSQL 17.10 clusters, native Ed25519, and explicitly simulated external KMS/observer services. The initial sandbox-denied connection attempt ran no tests; the authorized retry passed. One existing allowed Starlette warning occurred in the 40-case selection and full collection. An initial issuer-review command named a nonexistent file and ran zero tests; the corrected 70-case command passed. No failure, skip or collection-only outcome is counted as a baseline pass. Scope and code excellenceFinal paths:
Net production growth is six lines across two existing modules. Existing limits remain unchanged: issuer 161/180, mint 75/80, signing group 997/1000, UOW 520/520, transaction group 932/940. No production dependencies, modules, durable state or authorities added. No SQL/schema/roles, canonical copies, validator/contract, custody, runtime activation, legacy behavior, publication policy or baseline configuration changed. Separate retirement test module and shared fixture support are in-boundary evidence discoveries, not new capabilities. Semantic approval was directly verified from the refreshed complete card Remaining gates and limitsThe locked Linux x86_64 / Python 3.12.13 / PostgreSQL 17.10 three-cluster full baseline must run twice and pass comparison at this admitted implementation. Native architecture evidence, independent publication, receipt validation and later exact-head user acceptance remain pending. Local evidence establishes no external HSM/cloud operation, guaranteed later admission, deployed availability, production readiness or canonical promotion. Production governed routes remain closed. Historical audit findings outside this boundary remain separate remediation work. Next: create separate immutable admission for this unchanged reviewed head, then follow the existing hosted baseline and publication workflow. |
|
Technical baseline admission for PR #378 after the coordinated exact-head content review found zero Blockers. This triggers only the existing baseline and publication procedure; it is not semantic approval, final quality acceptance, merge authorization or deployment authority. OFARM2_BASELINE_ADMISSION |
|
All applicable technical and evidence gates passed for PR #378 at
Execution merge The automatic review job completed but posted no current-head disposition and logged five permission denials plus internal action diagnostics. It is not counted as a fourth substantive review or as human approval. Main is unprotected with no rulesets; these are repository-procedure gates, not a claim of GitHub-enforced branch protection. Original semantic approval was directly verified in the originating task; it authorizes this implementation/evidence work but not merge. The complete final exact-head packet will be presented in that task. Existing legacy/credential/principal/audit-export/temporal findings and import simplification remain separate work. The real cloud KMS/observer is simulated in tests; production governed routes remain closed. Disposable local databases were removed; unrelated resources preserved. Next: task-user final review and separate exact-head merge authorization; leave this PR open and unmerged meanwhile. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #378 — implementation review
Verdict: no demonstrated Blockers at the reviewed implementation head. Ready for final exact-head acceptance; this is not merge authorization.
Reviewed head: 08d9813d1683bf3765e0052f796a3b877764ab34
Base: bb3fe718f16721165fcd1ac9cb634cf8fb2815c7
Decision: OFARM2-TENANT-CAPABILITY-DEADLINE-001, version 1.
The live PR head and base were rechecked before posting and still match these coordinates. The PR is open and non-draft, with implementation and verification evidence—not the design-only version reviewed previously.
Blockers: 0. New Follow-ups: 0. No required code changes identified.
Implementation assessment
The deadline defect is fixed at the correct boundary. TenantCapabilityIssuer.mint() retains signing-observation time for issued-at and not-before, but now caps expiry against all three existing limits:
min(
signing observation + maximum capability lifetime,
protected challenge creation + maximum challenge age,
key issuance end,
)
It passes the original protected creation time into the existing validator before signing serialization or KMS. That matters beyond the minimum calculation: an invalid creation time still refuses even when another bound determines expiry. The exact-type guard rejects None, booleans and other non-integer timestamps before arithmetic. No replacement clock, shortened default TTL or duplicated range-policy validator was introduced.
Source: issuer at the reviewed head.
Challenge transport preserves transaction ownership. _bind() creates the challenge, observes its metadata in a separate statement on the same connection, and constructs one frozen value after checking the UUID join. The implementation does not move SQL execution into the factory or change the transaction lifecycle. Existing capability-versus-binding refusal mappings, rollback/discard handling and commit-uncertainty behavior remain intact.
Source: UOW at the reviewed head.
The tests exercise the failure modes that could otherwise hide a bad fix. The issuer tests cover positive observation delays, competing expiry bounds, equality refusals, backward skew, malformed timestamps, integer boundaries and unchanged signed times when only valid receipt timestamps vary. Observation tests check statement ordering, malformed joins, execute/fetch errors, cancellation and connection cleanup—not merely helper invocation.
Sources: issuer tests, observation/UOW tests.
The integration evidence addresses K-01 rather than substituting a fixture minter. The test composition uses the actual issuer, signing-authority reader, receipt verifier, signer, UOW and native PostgreSQL binder. It checks successful delayed issuance and binding, while separate tests exercise retirement and cancellation. The genuine expired-challenge test creates fresh signing evidence after the expiry wait and checks the challenge-time validation path, preventing a stale receipt from masking the intended refusal. External KMS and observer services remain explicitly simulated.
Sources: live signing support, live issuer/binder tests, retirement/admission test, genuine expired-challenge test.
Scope and code excellence
The earlier 177-line issuer estimate would have exceeded the aggregate signing-group budget; my previous Phase A review missed that. The implementation resolves it by deleting the single-use _capability helper and constructing the named payload directly in mint, while preserving nonce evaluation order. The resulting issuer is 161 lines, the signing group is 997/1,000, and UOW remains 520/520. No budget increase or unrelated production refactor was used.
The changed-file set stays within the consumer implementation, tests, RFC, ERRATA and generated inventory. It does not amend baseline law, migrations, the frozen signed contract, shared validators, production composition, profiles or workflow policies. This remains an implementation/conformance correction, not a new authority or readiness claim.
Sources: deadline RFC, changed files, ERRATA.
Verification checked
I inspected the hosted execution logs rather than relying solely on the PR's reported results:
| Evidence | Observed result |
|---|---|
| Full baseline run 1 | 4,269 passed, one Starlette deprecation warning |
| Full baseline run 2 | 4,269 passed, the same warning |
| Generated manifest verification | PASS in both runs |
| Prescribed two-run equivalence | PASS |
| Separate evidence publication | Completed successfully |
The baseline logs show both successful runs, manifest checks and equivalence. The publisher completed its validation, equivalence and receipt-publication steps.
Sources: baseline/conformance job, publication run, publication job.
I checked that the execution merge commit, 91f3dd1247fc42e6bd95d62d40cfbadd92d49f5b, joins the reviewed head to the stated base. This is evidence for this consumer implementation, not recycled PR #376 evidence.
Limits: I did not rerun tests locally, independently re-hash every published artifact, or rebuild the native images. The integration tests do not establish live Google Cloud KMS/HSM behavior. Later binder refusal after latency, clock movement or authority changes remains intentional; pre-sign validation does not guarantee future admission.
Recommendation: proceed to final exact-head acceptance without further implementation changes. This COMMENT is an AI implementation review. It does not supply human semantic approval, final task-user acceptance, a new baseline admission, merge authorization or deployment authority. K-01's formal closure remains subject to this PR's evidence and final acceptance; production governed routes remain closed.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Implementation review — PR #378, "Bound tenant capability issuance by protected challenge time"
Head reviewed: 08d9813d1683bf3765e0052f796a3b877764ab34.
Base: bb3fe718f16721165fcd1ac9cb634cf8fb2815c7 (still origin/main; confirmed an ancestor).
Two commits since my Phase A review at 83d8c24:
eebe865 (design correction for B-1) and 08d9813 (the implementation slice).
Diff vs base: 12 files, +1,603 / −61.
This is my third pass. My Phase A review (pullrequestreview-5130575131) raised 1 Blocker and
2 Should fix. All three are addressed. This pass verifies that empirically and reviews the
implementation on its own terms.
The headline for this pass: I executed the live evidence. The previous two reviews — mine and
the concurrent one — both reported the provisioned real-binder suites as unavailable. They are not
unavailable; they need a PostgreSQL that can be built. I built PostgreSQL 17.10 from the
REL_17_10 tag, libsodium 1.0.22 from 1.0.22-RELEASE, and this repository's own ofarm_ed25519
extension with its own Makefile, and ran the slice's live suites for real. Then I reverted the fix
and re-ran them. Details and limits in § Method below.
Verdict
0 Blockers, 1 Should fix, 0 Preferences.
The slice does what the RFC says, the budget correction is real rather than asserted, and the
tests are load-bearing under neutralization — including the expensive ones. The single Should fix
is a narrow divergence between the implemented failure mapping and the RFC's own stated mapping.
It has no security consequence; I measured that before classifying it.
Prior findings — disposition
B-1 (Blocker, group budget) — RESOLVED, and answered better than I proposed
eebe865 reproduces the arithmetic exactly, including the numbers from my review, and adds a
projection table to § Containment. It does not raise a budget, does not touch another group
member, and does not offset signing growth with UOW deletions — the three things I said would
each change the non-effects list. Instead it buys the lines inside the same module by deleting the
single-use _capability helper and constructing the payload inline in mint. That is a
legitimate remedy I had not considered.
The RFC's projection versus what the code actually does, measured at 08d9813:
| Constraint | Limit | Base | RFC projection | Measured at head |
|---|---|---|---|---|
| Issuer module | 180 | 155 | 161 | 161 |
| Capability-signing group | 1000 | 991 | 997 | 997 |
| UOW module | 520 | 520 | 520 | 520 |
| Tenant-transaction group | 940 | 932 | 932 | 932 |
mint function |
80 | 48 | 75 | 75 |
Every cell matches. The gates agree:
$ /tmp/venv13/bin/python conformance/rewrite_architecture_check.py
rewrite architecture constraints: PASS
$ /tmp/venv13/bin/python conformance/ofarm_pkg_contract_check.py
RESULT: PASS (0 failures)
$ /tmp/venv13/bin/python conformance/temporal_contract_candidate_check.py
TEMPORAL CANDIDATE PASS: CONFORMANT_CLASSIFIED
I note the slice consumed most of the remaining room in two places at once: the group is at
997/1000 and mint is at 75/80. Not a finding — both are inside their limits — but the next
consumer of either has three and five lines respectively, and should be told so rather than
discovering it.
Ruff (pinned 0.15.5) across kernel/, deployment/, conformance/ reports exactly one error,
F401 on kernel/profiles/si_ffs/si_bindings.py:37. It is present at base too, byte for
byte, in a file this PR does not touch. Not a finding against this PR.
S-1 (validator fails open on C=None) — RESOLVED, and pinned by a test
eebe865 added the requirement that the direct mint test for C=None assert
CapabilityMintError and zero KMS calls, "not a broad exception: the generic validator's absent
challenge context is optional, and a raw arithmetic TypeError is not the specified issuer
refusal." That is the mechanism I described, correctly stated.
test_issuer_requires_exact_integer_creation_before_key_read parametrises
none / true / false / text / float / int-subclass and asserts reader.calls == [] and
client.calls == [] — refusal before the key read, not merely before KMS. _IntSubclass(NOW_US)
is a nice touch: type(x) is not int is exactness, not isinstance.
I did not take that on trust. Removing the guard and re-running:
===== A: remove the exact-int guard =====
FAILED ...test_issuer_requires_exact_integer_creation_before_key_read[float]
FAILED ...test_issuer_requires_exact_integer_creation_before_key_read[int-subclass]
6 failed, 75 passed
The guard is load-bearing and the test fails on its removal. S-1 is closed.
S-2 (TENANT_CHALLENGE_MAX_AGE_MICROSECONDS not in __all__) — RESOLVED by explicit decision
The RFC now says: "Import them explicitly; no tenant_contract or __all__ change is needed."
That is one of the two dispositions I asked for, taken deliberately, and it keeps the non-effects
list intact. Accepted; I withdraw the point.
Should fix
S-3 — The factory accepts a non-integer creation time, so a malformed row refuses under the wrong outcome code
§ One immutable challenge value requires "one frozen, required three-field value" whose
factory must "never coerce a string into a UUID or supply a missing timestamp", and
§ Ordering, failures and limits maps "malformed rows/UUID joins" to
ValueError → BINDING_REFUSED, keeping CapabilityMintError → CAPABILITY_REFUSED for "invalid
mint inputs/time windows".
TenantChallenge.from_database_rows enforces the UUID half of that and not the timestamp half.
It checks both rows' shape, both UUIDs' type, non-zero identity and exact equality, then returns
cls(created[0], created[1], observed[1]) with observed[1] unexamined. The dataclass is
frozen=True, slots=True and annotates created_at_us: int, which is not enforced at runtime.
Measured directly, with the production issuer and the real TenantUnitOfWorkManager, varying only
the observer row's timestamp column and keeping the UUID join valid:
value | factory | UOW outcome | key reads | KMS
'1788000000000123' | ACCEPTS (str) | CAPABILITY_REFUSED | 0 | 0
1788000000000123.0 | ACCEPTS (float) | CAPABILITY_REFUSED | 0 | 0
None | ACCEPTS (NoneType) | CAPABILITY_REFUSED | 0 | 0
True | ACCEPTS (bool) | CAPABILITY_REFUSED | 0 | 0
There is no security consequence, and I checked that before writing this. Every case refuses
before any signing-authority read and before any KMS call, and no unit of work is exposed. The
issuer's own exact-type guard catches all four. What is wrong is narrower:
- The "required" three-field value does not enforce its own declared type, so an ill-typed
TenantChallengeis constructible from database rows. The RFC gives the factory that job. - A malformed database row surfaces as
CAPABILITY_REFUSED, not theBINDING_REFUSEDthe
RFC's own mapping specifies for malformed rows. The UOW's
except (psycopg.Error, TypeError, ValueError)branch exists for exactly this class of fault. - It is untested at the transport layer. The 13-case matrix in
test_malformed_or_misjoined_rows_refuse_before_mint_and_bindingvaries row shape and UUIDs
only; no case varies the timestamp type. Every observer row in it carries a valid integer.
The fix is one clause in the factory (or type(observed[1]) is not int) and one parametrize row.
Counter-argument. One could hold that a timestamp's type is a mint-input concern, that the
issuer guard already owns it, and that the factory should stay minimal per EXC-005. That is
defensible — but then the RFC's § Ordering mapping and its "or supply a missing timestamp" clause
are describing behaviour the code does not have, and the document should move instead. Either
resolution closes this; leaving both as they are means the implementation and its own contract
disagree about a refusal path.
Checked and decided were not findings
N-1 — The live evidence runs, and it is a genuine K-01 regression test.
This is the claim both prior reviews had to defer. On real PostgreSQL 17.10 with the real
ofarm_ed25519 native binder:
$ pytest kernel/tests/test_postgresql_tenant_capability_signing.py -q
4 passed in 11.82s
$ pytest test_postgresql_tenant_capability_retirement.py \
test_postgresql_tenant_challenge_observation.py \
test_postgresql_tenant_uow.py -q
31 passed in 95.03s
Then the decisive check — revert the challenge.created_at_us + AGE term and re-run the live
suite unchanged:
E kernel.tenant_uow.TenantBoundaryError: tenant boundary refused (CAPABILITY_REFUSED)
FAILED ...test_real_delayed_issuer_binds_exact_protected_challenge_deadline
FAILED ...test_real_issuer_cancellation_rolls_back_and_next_transaction_is_fresh[before-bind]
FAILED ...test_real_issuer_cancellation_rolls_back_and_next_transaction_is_fresh[after-bind]
3 failed, 1 passed
A 20 ms real elapsed delay is enough. K-01 reproduces end-to-end in the production composition,
and the fix closes it. The test asserts the exact cap
(expires == challenge.created_at_us + TENANT_CHALLENGE_MAX_AGE_MICROSECONDS) and that the
challenge bound beat the TTL bound, decoded from the actual JWS rather than from a helper's return
value.
N-2 — The genuine 62-second expired-challenge test is load-bearing too.
test_expired_worker_challenge_remains_observable_without_renewal was extended rather than
duplicated, as the RFC asked. It refreshes the fixture receipt after the genuine wait and
asserts now_us <= signing_authority.observed_at_us and
issuance_end_us > observed_at_us before minting — so the refusal cannot be a stale receipt or a
retired key masquerading as the deadline check. It then asserts CapabilityMintError whose
__cause__ is TenantCapabilityContractError, and zero KMS calls.
Neutralising both mechanisms (the min() term and the validator kwarg) and re-running just
that test:
E Failed: DID NOT RAISE CapabilityMintError
1 failed in 72.33s
The genuinely expired challenge would be signed. The expensive test earns its 72 seconds.
N-3 — The validator call is not decorative. Removing only
challenge_created_at_unix_microseconds=challenge.created_at_us fails 6 unit tests, including
test_issuer_refuses_integer_extremes_even_when_minimum_masks_them[challenge-subtract-skew-underflow]
and [challenge-add-age-overflow-masked-by-key-end]. So the RFC's "even an out-of-range C whose
candidate loses the minimum must refuse" is enforced by the validator, not by the arithmetic, and
that is pinned.
N-4 — Nonce evaluation order is preserved, deliberately. Inlining _capability into mint
could have moved self._nonce_factory() relative to the digest conversions, changing which
refusals consume a nonce. The commit message names this, the code keeps
nonce = self._nonce_factory() before issued_at and the _raw_digest calls, and
test_nonce_is_evaluated_once_before_invalid_authority_digest_refuses pins it. Checked because
inlining is exactly where this kind of thing gets lost.
N-5 — The statement-order pin is exact.
test_observation_and_mint_use_one_transaction_and_immutable_exact_value asserts the full
history: CHECKOUT, BEGIN ISOLATION LEVEL READ COMMITTED, create, observe, MINT, bind, context, YIELD, COMMIT, POOL_RETURN, on one connection, with pool.return_states == [(IDLE, False)]. It
also asserts FrozenInstanceError on set and delete for all three fields. That is INV-001 done
properly.
N-6 — The UOW change is line-for-line what was promised. Nine lines replaced nine lines;
kernel/tenant_uow.py is still 520/520. _uuid remains live at lines 151, 155 and 254, so
nothing is orphaned. TenantUnitOfWork's shape pin is untouched (_bind is on the Manager).
N-7 — The test inventory is mechanically reproducible, not hand-edited.
entryCount recorded: 4269 len(entries): 4269
entriesSha256 recorded: 9e0bbaa5...c17be3
entriesSha256 computed: 9e0bbaa5...c17be3 MATCH
$ pytest kernel/tests --collect-only -q -> 4269 tests collected
in inventory not collected: 0
collected not in inventory: 0
vs base: added 75, removed 0
+41 test_google_kms_signing.py
+29 test_tenant_uow_observation.py
+ 4 test_postgresql_tenant_capability_signing.py
+ 1 test_postgresql_tenant_capability_retirement.py
Zero drift, zero removals, and the additions land only where the slice added tests.
test_postgresql_tenant_challenge_observation.py gained code but no new node, consistent with
extending an existing test rather than adding one.
N-8 — ERRATA E-010 does not overclaim. It moves to past tense for the original defect, cites
this Delivery, and states: "Closure requires PR #378's own real-issuer-to-binder evidence and
final acceptance; earlier prerequisite evidence is not consumer proof." K-01 is not declared
closed. Correct.
N-9 — Test budgets are not strained. test_google_kms_signing.py 489/800,
test_tenant_uow_observation.py 290/800, test_tenant_uow.py 695/800,
_tenant_signing_support.py 83/800. The two test_postgresql_tenant_* files match no
TEST_GLOBS pattern and are outside the test accounting entirely — a pre-existing property of
the glob list, not something this PR introduced.
N-10 — The signing fixture is honest about what it simulates. live_signing uses the real
SigningAuthorityReader connecting as ofarm_app and re-reading ofarm.observe_signing_authority()
on every mint, the real SigningEvidenceVerifier, and the real GoogleKmsSigner. Only the KMS
client and the observer receipt are fixtures, both labelled in the module docstring and the class
docstring ("No cloud call or HSM claim"). S is a live database observation per mint, not a frozen
constant — which is what makes the 20 ms delay test mean anything.
N-11 — The retirement test uses the real control API. It rotates the pinned key via
ofarm.rotate_tenant_capability_key and closes admission via
ofarm.close_tenant_capability_admission as ofarm_capability_key_control_login, then asserts
CAPABILITY_REFUSED with client.calls == []. Not a stubbed key state.
Method, and what it made easier than production
- Interpreter: CPython 3.12.13 built from the
v3.12.13tag, with the repository-pinned Ruff
0.15.5 fromrequirements-review-tools.lock, so all three conformance gates executed rather
than refusing. - Database: PostgreSQL 17.10 built from the
REL_17_10GitHub tag; libsodium 1.0.22
from1.0.22-RELEASE(the versionnative_evidence.pypins) built static;ofarm_ed25519
built and installed with the repository's own Makefile against that server. - The one deviation, stated plainly. Provisioning pins the exact
server_versionstring
17.10 (Debian 17.10-1.pgdg13+1). A source build reports17.10. In a throwaway copy of
the tree I changed that one string and nothing else;SUPPORTED_POSTGRESQL_SERVER_VERSION_NUM
matched170010unmodified. Every other file was byte-identical to the head.apt.postgresql.org
is 403 at the egress gateway, so the pgdg package itself is not reachable from here. - That pin is load-bearing, not cosmetic: on PostgreSQL 16 the chain fails at database
creation withunrecognized locale provider: builtin, a 17-only feature. Worth knowing. - What I did not do. I did not reproduce the native release identity, BuildKit provenance or
reproducible-container evidence — my server and extension are ordinary source builds, so nothing
I ran speaks to the publication receipt. I did not run the full 4,269-node suite, the locked
three-independent-cluster two-run baseline, or anything on macOS/ARM. KMS and the observer
receipt were the PR's own fixtures throughout; no real HSM was involved, and no assertion of
mine distinguishes a real signature from the RFC 8032 test-seed one. - A fixture error I made and caught. My first attempt at S-3 set
observed_rowusing a
challenge UUID captured before the run, but_Connectionregenerates that UUID on each
create_tenant_challenge. The refusal I measured was a UUID mismatch, not a timestamp fault,
and I would have reported the wrong mapping. Pinning both rows explicitly gave the result above.
Recording it because the same shape of error is what a fixture-built claim usually hides. - Neutralize-and-rerun is doing the real work in this review. Five separate reversions, each
re-run against the suite that is supposed to catch it. Every one failed the way it should. That
is a stronger statement than "the tests pass".
Position relative to the other review on this head
The concurrent Phase A review (pullrequestreview-5130226680, same head 83d8c24) reached
0 Blockers on a source-and-design basis and said so explicitly: "I did not execute repository tests
or package checks", and "Actual module sizes and readability remain implementation-review
questions". My Blocker was precisely that the sizing was not deferrable, because the RFC's own
177-line estimate already failed the group budget and every remedy touched the non-effects list.
eebe865 settled it by finding a remedy inside the boundary, so the disagreement is now moot and
resolved in the design rather than in review.
Both prior reviews on this PR are authored by samovers, as is this one. The "independent design
reviews" gate in § Verification is still not met by any of them.
What is left before merge
Nothing blocking. S-3 is a two-line change plus a test row. Beyond that, the PR's own checklist
governs: the locked Linux x86_64 / Python 3.12.13 / PostgreSQL 17.10 three-cluster two-run
baseline, the publication receipt and native provenance, and the separate exact-head content and
scope reviews — none of which this pass substitutes for.
1 participant
Delivery identity and decision
Closes #377. Parent Tracking Epic: #167.
Normal new Delivery with one live implementation PR and no merged implementation PR. No recovery or transferred approval.
Risk: high. Decision
OFARM2-TENANT-CAPABILITY-DEADLINE-001, version1.Status: semantic approval verified; implementation, exact-head review, both hosted baselines, native verification, publication and independent receipt validation complete. Ready for final task-user acceptance; merge is not authorized.
Implementation head:
08d9813d1683bf3765e0052f796a3b877764ab34.Baseline: remotely verified
bb3fe718f16721165fcd1ac9cb634cf8fb2815c7.Database prerequisite #375 / PR #376 is merged.
Audit K-01 demonstrated that signing-observation time plus 60 seconds exceeds the protected challenge deadline after a positive observation delay, unless earlier key retirement masks the defect. This Delivery gives the production issuer one complete capability: mint a capability bounded by that original protected deadline when a valid interval remains, or refuse before signing when it does not.
Primary trust boundary and containment
Signing and capability issuance. UOW changes are limited to mechanical transport of the already accepted database observation. No transaction, identity, tenant, key custody, readiness or database authority decision moves into the issuer.
Protected assets: challenge UUID/time, correct signed validity, principal/tenant binding, KMS signing authority and one-use transaction admission. The supported production-foundation entry is
TenantUnitOfWorkManager.unit_of_work(principal)wired toTenantCapabilityIssuerbyapplication_runtime; this does not open the intentionally closed governed routes.Trusted sides: protected database challenge and observation routine, existing principal resolver and authenticated principal, signing-authority database reader and receipt verifier, KMS signer, native binder, UOW transaction owner. Untrusted sides and inputs: external credentials before the existing verifier, app/worker requests, returned external KMS/observer material until existing verification, and malformed or misjoined transport values as adapter-failure injection. An ordinary app/worker cannot edit the protected creation time. Tests that replace database results model transport faults, not a newly claimed hostile SQL privilege.
Excluded capabilities: compromised superuser/migrator, altered trusted application code or database binary, forged trusted observer key, arbitrary protected-table mutation, production key compromise and unsupported database restore. Existing controls and refusal posture for those boundaries remain unchanged.
Primary risk: joining the wrong creation time to a challenge or silently substituting a later clock, producing a signed validity window the binder rejects. Containment: one immutable UUID-joined value, the original protected integer time, the existing validator before KMS, and unchanged final binder revalidation.
Authority map
Permitted effects and detailed design
ofarm.current_tenant_challenge()once. Its STABLE snapshot contract requires this ordering.min(C + TENANT_CHALLENGE_MAX_AGE_MICROSECONDS, S + TENANT_CAPABILITY_MAX_TTL_MICROSECONDS, E)using explicit imports of the existing separate named limits. Notenant_contractor__all__change is needed._capabilityhelper and its now-unusedSigningAuthorityannotation import. Construct the same fully named payload directly insidemintbefore its existing validation and signing. Preserve evaluation order with an explicit nonce value evaluated before the issued-time local and authority digest conversions. This removes a function/call/argument transfer within the same issuer, without changing another group member or adding an abstraction.The durable rationale is in
docs/rfcs/OFARM_Tenant_Capability_Deadline_RFC_v0_1.md. That document records the accepted implementation design; it is not OFARM law or an amendment of ADR 0003/the frozen signed contract.Ordering, failures and limits
idle checkout → BEGIN READ COMMITTED → create → separate observe → join immutable value → read signing authority/verify receipt → validate → KMS sign → bind → validate current context → yield → existing commit/rollback.The new observation neither renews nor consumes a challenge. It reads on the UOW connection; the signing reader retains its existing separate connection and authority observations. No stronger shared snapshot or revocation ordering is claimed.
Malformed rows/UUID joins preserve
ValueError → BINDING_REFUSED; invalid mint inputs/time windows preserveCapabilityMintError → CAPABILITY_REFUSED. SQL failures take the existing rollback-or-discard path. Before-yield BaseException cancellation propagates and the outer UOW discards a non-idle connection; after-yield cleanup and lost-commit-acknowledgment behavior remain unchanged. No retry, new error category or cleanup-policy rewrite is in scope.Validation before signing does not promise that later binding succeeds. KMS/lock latency, later database-clock movement, principal revocation, key retirement or admission closure can still make the unchanged binder refuse. No invalid admission yields a UOW. No-signing assertions apply only to pre-sign refusals; cancellation after RPC dispatch cannot prove no remote signature occurred.
No migration, durable-state change or new rollback/recovery protocol is needed. The accepted V11 database prerequisite is already present; no mixed-version rollout or compatibility adapter is promised.
Invariants, source and focused evidence
The matrix states the acceptance requirements; executed results are recorded below. Negative cases use the production foundation entry or its owned factory/mint seam; injected row/cancellation/clock faults are identified as such.
_bind+TenantChallenge.from_database_rows. One recorded history proves create/observe/mint/bind order, same connection, exact C and immutable fields. Missing/short/extra rows, wrong UUID type, zero UUID or mismatch refuse before mint/bind._bindtransport plus unchanged_run/pool. Inject observer execute/fetch errors and pre-yield cancellation; assert no bind/yield/commit, correct rollback or discard before pool return. Retain failed rollback, post-yield cancellation and ambiguous commit regressions.Use the existing real-role tenant fixtures and public key-control APIs. Reuse the current genuine expiry wait where practical instead of duplicating 62 seconds. Do not alter protected timestamps, role timeouts, binder predicates or schema to manufacture success. Isolate lifecycle-mutating cases so module fixtures cannot hide order dependencies. Deterministic clock-fault cases are supplemental and must not be described as actual host-clock adjustment or live external HSM evidence.
Smallest complete change and code excellence
_capabilitywrapper and its unused annotation import within the issuer. No legacy constructor default or fallback remains.mint: 48mint: 75With the other signing members unchanged, the effective issuer ceiling is 164. The earlier 177-line estimate omitted the aggregate cap and would total 1013; that fit claim was withdrawn and corrected before approval. Implemented source matches the corrected static projection and passes the existing architecture check. No module, group or function budget changed.
The complete slice includes issuer, mechanical transport, focused unit and real-binder evidence, fixture updates and regenerated test inventory in this one PR. No enabling-only companion PR is planned.
Expected areas and non-effects
Expected:
kernel/tenant_capability_issuer.py; only_bindinkernel/tenant_uow.py; relevant issuer/UOW/PostgreSQL tests and test helpers; mechanically generatedconformance/review_baseline_test_inventory.json; this durable RFC and the existing E-010 ERRATA disposition after evidence is complete. Additional paths are permitted only when demonstrably within this same boundary.The final 12 changed paths are the RFC, ERRATA, inventory, issuer, UOW,
kernel/tests/test_google_kms_signing.py,kernel/tests/test_tenant_uow.py,kernel/tests/test_tenant_uow_observation.py,kernel/tests/_tenant_signing_support.py,kernel/tests/test_postgresql_tenant_capability_signing.py,kernel/tests/test_postgresql_tenant_capability_retirement.py, andkernel/tests/test_postgresql_tenant_challenge_observation.py.The separate retirement test module reuses existing module-scoped provisioning fixtures to isolate an irreversible test key-lifecycle transition from other tests. The shared test support serves the live signing, retirement and existing expiry modules. These are test-only paths inside the predicted verification scope; they add no production interface, provisioner, schema, authority, custody mechanism or capability. The existing genuine expiry wait is reused rather than duplicated. Only two production Python files change, with a net addition of six production lines; the single-use payload helper is deleted.
No changes to migrations, database roles/functions, signed contract bytes, canonical/extracted documents, shared validator, principal/key/receipt authority, KMS policy, runtime configuration/composition/readiness, selector, audit, closed governed routes, workflow/admission/publication machinery, module/group/function budgets, profiles or capability claims. K-02/K-03/K-04 legacy remediation and broader import simplification remain separate work. No production deployment, release or current/default promotion is authorized.
Verification and current status
Phase A and its focused B-1 correction review reached zero design Blockers before the refreshed same-task card. The task user approved decision version 1 at
2026-09-07T11:11:30.828Z, original messagemsg_01a07b90-ee0c-79f3-bc4b-fe109dac7f2a, after refreshed cardmsg_0883c92931c61918016a9e9b88900887d2867b9f5acf81ddb8at2026-09-07T11:10:09.223Z. Both originals were directly retrieved and verified in Codex task01a07734-2572-7990-8e0d-c3bd908123c2; this PR text is navigation only. Semantic approval does not authorize merge or deployment.Executed local checks on the complete implemented content before commit:
Local Python is 3.12.13 on Darwin; disposable PostgreSQL 17.10 runs on Linux ARM with the frozen native verifier image. Three cluster identities were independently verified; the live integration uses the tenant cluster. These focused checks are supplemental, not locked Linux baseline equivalence. An initial live attempt failed at fixture setup because sandbox TCP access was denied; the authorized retry executed all 26 tests successfully. No production/private cloud service was used. Existing PR #376 evidence remains historical.
The B-1 correction and implementation preserve the approved capability, primary boundary, authority, effects/non-effects, invariants, named PR and production posture. No Phase A semantic deviation or new approval is needed for the additional test-only paths.
Exact-head coordinated content review reports zero Blockers at
08d9813d1683bf3765e0052f796a3b877764ab34: #378 (comment). Separate immutable admission: #378 (comment), body SHA256725a70582f3bc23b0245b418c738b094c7b9f57a0480591d561204c678ac6687. Admitted source run https://github.com/samovers/OFARM2/actions/runs/34116628952 succeeded: both 4,269-case runs, prescribed equivalence and both native architectures passed. Publisher https://github.com/samovers/OFARM2/actions/runs/34118757959 succeeded. Receipt artifact 10017373196, SHA256cf9a8a53387ba43fed56bf836aa94024afc78cbaca7f5c160f10fda8f0a956cc, and exact live artifact/admission/head/environment/inventory bindings independently verified. Both source and published equivalence documents were recomputed successfully with unchanged base-pinned policy. Local native-image download/rebuild is not claimed. The automatic review job posted no current-head disposition and is not counted as a fourth content review.The complete implementation head remained frozen throughout review and admitted verification. Full locked Linux x86_64/Python 3.12.13/PostgreSQL 17.10 three-cluster evidence is now this consumer’s own evidence; PR #376 remains historical. Final scope/excellence and evidence recheck passed. The complete exact-head packet precedes separate later user merge authorization.
Not provisional: this is a permanent narrow consumer of an accepted API; no temporary mechanism or expiry timer. Reapproval is required if capability, boundary, authority, effects/non-effects, decision invariants, named PR or production posture changes. Discovery of in-boundary test files alone does not change semantic scope.
Approval navigation is recorded above. No approval is created by this PR description, reviews, credentials, checks or earlier PR #376 decisions. Final exact-head quality acceptance and merge authorization remain pending.
Next: task-user final review of the complete exact-head packet and separate merge authorization; the PR remains open and unmerged.