Add strict QSL Activation v1 contract - #203
Conversation
Co-Authored-By: Codex <noreply@openai.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0503a1a9a0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if expected_authority is None: | ||
| return |
There was a problem hiding this comment.
When expected_authority is omitted, validation accepts any self-declared authority ID and receipt digest, and the CLI always takes this path because it has no authority input. An activation author can therefore fabricate human_authority, recompute the unkeyed activation hash, and receive a successful validation result without demonstrating the claimed human authorization; require a trusted expected authority for full validation or make the CLI obtain and compare one.
Useful? React with 👍 / 👎.
| target = root["target"] | ||
| if target["platform"] != bundle["target"]["platform_id"]: | ||
| _fail("activation target does not match deployment bundle target") | ||
| if target["revision"] != bundle["dependencies"]["platform"]["revision"]: | ||
| _fail("activation platform revision does not match deployment bundle platform revision") |
There was a problem hiding this comment.
When multiple environments or accounts use the same platform revision, these checks accept contradictory targets: a bundle whose target.id identifies one deployment can be paired with an activation declaring an unrelated environment/account because only the platform ID and revision are compared. The hashes preserve both conflicting declarations rather than preventing them, so a consumer routing from activation.target can apply the wrong bundle; expose and verify an activation target identifier against bundle["target"]["id"].
Useful? React with 👍 / 👎.
| if expected_bundle is None: | ||
| _fail("expected qsl.deployment_bundle.v1 is required") | ||
| try: | ||
| bundle = validate_bundle(expected_bundle) |
There was a problem hiding this comment.
When a valid expected bundle has a created_at later than the activation's created_at—or even later than the current as_of time—this path accepts it without comparing the timestamps. The result is a supposedly effective activation that claims to bind an immutable bundle before that bundle existed, undermining audit chronology; compare the parsed bundle creation time against the activation creation/effective times.
Useful? React with 👍 / 👎.
| from pathlib import Path | ||
| from typing import Any, Mapping | ||
|
|
||
| from deployment_bundle_contract import BundleValidationError, parse_bundle_json, validate_bundle |
There was a problem hiding this comment.
When this project is installed or invoked as a package, such as PYTHONPATH=python python -m scripts.activation_contract, this absolute import searches for a top-level deployment_bundle_contract module and fails with ModuleNotFoundError; the tests conceal the problem by preloading that name into sys.modules. Import the sibling relatively (with an executable-script fallback if direct file execution must remain supported) so the packaged validator is usable.
Useful? React with 👍 / 👎.
| reused = any( | ||
| previous_authority[field] == current_authority[field] | ||
| for field in ("authority_id", "authority_receipt_sha256") |
There was a problem hiding this comment.
When stages cycle, checking only the immediately preceding activation permits an older authority receipt to be replayed: for example, PAPER with receipt A, then SHADOW with receipt B, then PAPER with receipt A passes because the final validation compares A only with B. This violates the stated cross-stage reuse prohibition even when callers consistently supply the immediate predecessor, so validate against the target's authority history or a persistent receipt-use registry rather than one activation.
Useful? React with 👍 / 👎.
1 participant
Summary
qsl.activation.v1schema bound to one exact DeploymentBundle identitySafety boundary
contract_only=true)PAPER_DRY_RUNandFULL_LIVEValidation