Skip to content

Apizr 0.4.4

Release finalization in progress. Core, OCI, MCP and Attest are coordinated at 0.4.4. Publication is authorized subject to the protected checks and approvals below; successful publication is not yet claimed by this source record. Published 0.4.3 and its original archives, tags and provenance remain unchanged. Tracking: #246 and PR #247.

Exact-source publication policy

Only 0.4.4 from protected refs/heads/master is admitted by the new policy. The selected source is the final signed squash-merge commit of PR #247, not its PR test merge or the earlier candidate head. Record its full SHA, the exact successful push CI run and all eight original archive hashes before tagging. CI, Security and Documentation must pass on that same source and repository; PR/manual runs, another ref, an unprotected branch, incomplete qualification and later failed Security/Documentation runs cannot authorize publication.

The final CI builds a separate set of four wheels and four sdists once. All six Linux/macOS target installations, disposable registry delivery, product checks, signed provenance and verified release assets must pass. A protected master push may stage provenance-verified 0.4.4 assets; PRs and other versions remain previews. Staging never uploads packages or creates a release.

After those checks, v0.4.4 must resolve to the exact selected source. The manual PyPI workflow verifies that tag, source, CI run, original bytes and provenance, then requires the existing separate protected receipt and publication approvals. It publishes core → OCI → MCP → Attest using Trusted Publishing, compares all public hashes and archives the signed timestamped receipt. Public installations outside the checkout are verified before declaring delivery complete. The MCP Registry descriptor selects 0.4.4, but its separate OIDC publication waits for the matching public packages and verified GitHub release assets. It requires explicit tag and full source SHA inputs; no previous release is selected by default.

The official Homebrew tap update is also bound to the final core sdist and protected master provenance. Publication-mode rendering requires the public immutable release asset to match the signed source; the generated Formula must pass the tap review, audit and real Apple Silicon installation checks before its update. Existing physical/hosted candidate evidence is not relabeled as final public installation evidence. No Linux or Intel Homebrew runtime qualification is claimed.

The frozen candidate source 3ddd068e64dd2f5a8148d77a0f4e7a2e2eeb5d46, its original four wheels/four sdists, hashes and qualification evidence remain unchanged in release-evidence/0.4.4-candidate/. Final source qualification and publication records are retained separately in release-evidence/0.4.4-final/. Independent sdist rebuilds are tests and never replace selected upload bytes.

Existing / confirmed gap / change / expected evidence

Existing Confirmed gap Candidate change Evidence
Catalog/IR, graph, readiness and REST/MCP bundle documents External consumers must manually extract/check metadata from executable bundles expose export / verify reuse all existing JSON and require a selected bundle digest Offline JSON-only roundtrip, A/B example, altered/unknown schema/refused build tests
DeliveryPlan/Manifest v1 and lineage-bound BuildResult Public result JSON schemas missing for non-Python consumers Generate schemas from the unchanged models; optionally check bundle-to-build links during export/verify Schema parity and existing v1 compatibility tests
OCI transfer, digest verification and explicit states Docker manifest unknown prevents first publication; Trunx uses a fixed-destination adapter Generic authenticated HTTPS confirmation of absence, bounded and fail-closed Real TLS refusal tests and disposable registry qualification
Proof publication/fetch, admission and batch resume Organizational approval boundary and handoff are scattered One consumer guide, exact references and errors Existing substitution/partial-state tests; installed-wheel registry proof

No Enterprise catalog, organizations, approval workflow or Trunx console enters Apizr. No local operation acquires a Trunx dependency. No competing CapabilityRelease contract is introduced.

Contracts and compatibility

All existing schema IDs, default serialization and stored v1 fixtures stay intact. The new export copies existing direct bundle documents; its stdout is the existing bundle manifest, not a new release model. It is additive CLI/Python API. Existing historical build/push/proof parsing remains covered; missing historical lineage cannot satisfy the optional new bundle-to-build verification.

Unknown schema versions or fields are refused, not silently upgraded. Structural JSON Schema is complemented by semantic/hash checks. Readiness remains static analysis; descriptions/annotations remain declarations. Runtime observations, technical admission and external environment approval are distinct.

The generic absence fallback handles the explicitly documented Basic-auth HTTPS case. Other ambiguous responses, including Bearer challenges, are refused. It never treats authentication, TLS or transport failure as registry absence.

Validation and artifact record

Candidate archives must be built once from a clean identified commit with scripts/coordinated_distributions.py build; candidate.json records that source and the SHA-256 of the original four wheels and four sdists. Target qualification installs those bytes outside the checkout, including the A/B document example. CI release-candidate, target exports and preview release-assets remain review artifacts, not production release evidence. Exact run IDs, outcomes and retained local artifact paths are recorded in the tracking PR/issue after execution.

The validation layers are deliberately separate:

  1. Unit/contract tests: immutable lineage, historic models, tampering, unknown schema, first-push diagnostics, auth/TLS/redirect failures and interruption.
  2. Installed-package qualification: A/B documents plus actual deterministic calls; logical ID stable, source/catalog/exposure/bundle identities changed.
  3. Disposable HTTPS OCI registry/TSA qualification: actual build, first transfer, proof publication/retrieval, digest consumption, admission and recovery. New exports bind to the actual build and verify after source/bundle removal.
  4. Real Trunx qualification: in progress; full interoperability is not claimed. The operator reports managed installations with the original wheel/lock hashes and complete dependency closures, successful delivery/recovery, and verified human approval in Trunx beta on attest-e2e / qualification-044 for MCP A/B, with positive authorization status. These are operator reports, not observations made by Apizr's disposable fixtures.

Remaining Trunx checks are consumption of immutable image/proof references after checking authorization, verification of the actual executed result, rejection of an unapproved version, and enforcement after revocation. Human approval does not establish those runtime controls. Two immediate REST B rechecks failed with admission_failed then remote_state_unconfirmed; later explicit resumes reportedly completed against the same image/proof without a new build/signature. The cause remains undetermined. Retain failures and recovery separately; these observations do not establish a generic Apizr defect.

The ongoing external qualification blocks this release only if it reveals a blocking defect in Apizr. Any demonstrated generic correction is treated separately, preserving public v1 contracts and core independence from Trunx.

What Trunx consumes

Consume the exported catalog/readiness/interfaces, existing bundle digest, DeliveryPlan/Manifest and original delivery results. Retain immutable image and proof references and verify them with independently selected trust. Trunx owns its organization/environment approval; the pipeline matches that decision to the same exact image/proof before deployment. Update all selected Apizr plugin pins together after qualification. The handoff guide describes the remaining integration boundary without inventing a Trunx API.