[mstattma]

Purpose

Prepare the signer-aligned dependency version 0.37.13+signer.1.0.9 for signer
1.0.9. The intended tag is castlabs-v0.37.13+signer.1.0.9.
This PR only prepares the release. It does not authorize a tag, a release or
publication. Publication waits for reviewer approval (Bibin or thasso) and then
the protected-environment gate.

Inputs (unchanged from published 0.37.13+signer.1.0.8)

• Native castlabs/c2pa-rs@6021100cc5060b06061ca15b634281cfeb97c718. This is
  still the tip of c2pa-rs feat/trusted-vsi-functional, so no native change is
  pending.
• Cargo.lock SHA-256 ff5cf2de2403ff491957fc8a2206c289203d2799a30425bd615f7c9e69974a8f.
  I re-checked it against the blob at 6021100.
• Rust 1.96.0, native 0.92.0-dev, trusted contract revision 3, capability mask
  63, the feature set and the Python runtime API are all unchanged.
• The base branch tip is abc9a034, which is the published 1.0.8 source
  (release ID 415634231, tagged run 39010024287). That tag, its release and
  its assets/evidence stay untouched and are not relabeled.

The base remains 0.37.13 because neither the Python line nor the native line
changed. Only the +signer.<version> label moves. The policy example in the
release notes used to say 0.37.14+signer.1.0.9. I changed it to the actual
identity, so please confirm that 0.37.13 is the intended base.

Changes (version label and release metadata only)

• pyproject.toml, the c2pa.py version header, the inputs lock, the input
  and evidence schemas, and castlabs_release.py (RELEASE_VERSION, release
  body) now carry 0.37.13+signer.1.0.9.
• castlabs-vsi-release.yml:
  • Tag trigger 'castlabs-v0.37.13\+signer.1.0.9', with the literal + still
    escaped.
  • Updated the concurrency group, the Linux/Windows wheel and bundle names,
    the expected versions, and the tag gate of the release job.
  • The release-tag check and the no-clobber draft discovery jq filter now
    use the new tag.
  • Unchanged: the castlabs-vsi-release environment, owned no-clobber draft
    creation, prerelease=false, the marker/label checks, source/branch-tip
    validation and attestations.
• trusted-vsi-paired.yml: FUNCTIONAL_BUILD_VERSION and
  CASTLABS_RELEASE_EXPECTED_VERSION.
• Tests:
  • Updated to the new identity.
  • New negative cases cover the published 1.0.8 identity: as a tag ref
    against the 1.0.9 lock, as a wheel dist-info, as a functional build
    version, and as a PyPI version.
  • A guard fails if the release or paired workflow still mentions
    signer.1.0.8.
• Docs: README, release notes and the trusted-VSI contract record 1.0.8 as
  published and describe 1.0.9 as preparation only.

Verification so far

• Locally: tests/test_castlabs_release_tooling.py and
  tests/test_trusted_vsi_build.py passed (66 tests, no native code), along
  with the lock-value and release-value helpers and git diff --check. There
  were no local cargo or native builds.
• Hosted, non-publishing: paired Linux/Windows qualification of head
  98ccd6de63d89eca9c23f27658f6b29fe99daffc passed:
  https://github.com/castlabs/c2pa-python/actions/runs/39622774539
  (castlabs-vsi-release.yml, trusted_vsi_only=true, native 6021100c).
  Each platform ran 286 focused, 929 non-threaded (release smoke required) and
  54 threaded tests, plus the real-native ladder harness and 286 tests against
  the installed 0.37.13+signer.1.0.9 wheel. Nothing was skipped. All
  release jobs were skipped and no artifacts were uploaded. The PR Build run
  39622768702 passed, including Castlabs release tooling.

Remaining after approval (not done here)

1. Integrate into feat/trusted-vsi-functional. A fast-forward keeps the
   qualified SHA equal to the release source. If a merge commit is used, its
   tree must match the qualified tree.
2. Optionally, a build-only artifact run on the exact branch tip.
3. Push the tag castlabs-v0.37.13+signer.1.0.9 at that tip. The tagged run
   builds and tests both platforms. Its release job waits for the protected
   castlabs-vsi-release environment and then creates an owned no-clobber
   draft.
4. Validate the tagged assets, evidence and attestations, then publish by exact
   release ID.

No PyPI. Signer pins must be updated only after these immutable facts exist.

[mstattma]

@cl-percy start

[mstattma]

Hosted non-publishing qualification of head 98ccd6de63d89eca9c23f27658f6b29fe99daffc

Paired Linux/Windows qualification passed:
https://github.com/castlabs/c2pa-python/actions/runs/39622774539. It was
dispatched from castlabs-vsi-release.yml with trusted_vsi_only=true. Both jobs
logged Python 98ccd6de and native 6021100c.

Job	Focused	Non-threaded (release smoke required)	Threaded	Installed 0.37.13+signer.1.0.9 wheel
ubuntu-24.04 (119300271632)	286 passed	929 passed	54 passed	286 passed
windows-2022 (119300272011)	286 passed	929 passed	54 passed	286 passed

Both jobs also ran the real-native ladder harness, with no skips.

• All release prepare/build/test/publish jobs were skipped.
• The run uploads no artifacts by design. Its isolated wheels are qualification
  bytes, not release candidates.
• The PR Build run 39622768702 passed, including Castlabs release tooling.

What I did not run, and why:

• Native was not re-qualified. 6021100c is unchanged, is still the c2pa-rs
  feat/trusted-vsi-functional tip, and was already qualified by c2pa-rs runs
  39004441528 and 39004441573.
• A branch-tip build-only artifact run is not possible yet. It requires this
  commit on feat/trusted-vsi-functional, so it can run only after review.
• No tag or draft was created.

@thasso, the REST review request rejected you as a non-collaborator on this
repository, so I'm asking for your review here instead. BibinBaby444 has been
requested formally. Either approval is enough for the publication gate.

[sripadmasm]

Review (head 98ccd6d): approve

Read-only review. No blocker, major or minor findings.

Native: unchanged.

• The lock still pins c2pa-rs 6021100c. compare 6021100c...feat/trusted-vsi-functional reports identical.
• Cargo.lock, toolchain, features and targets are unchanged.
• sdk/src/settings/builder.rs:413/425 (all_actions_included / auto_all_actions_included) are present.
• So the specVersion 2.4 / allActionsIncluded behaviour that signer contentauth#62 relies on, and verified natively on +signer.1.0.8, is preserved.

Python runtime: unchanged. The only change under src/ is the comment at src/c2pa/c2pa.py:14. __version__ never enters a manifest.

Release identity: consistent across pyproject, the lock, schemas, castlabs_release.py, both workflows and the tests. The body marker is now distinct from 1.0.8's, and new negative tests reject the 1.0.8 identity. No gates are weakened. The qualification run passed on Linux and Windows.

Suggestions

• Native byte check: after the tagged run, compare the SHA-256 of libc2pa_c.so / c2pa_c.dll in the 1.0.9 bundles with the 1.0.8 release (ID 415634231). Equal hashes would prove "native unchanged" byte for byte.
• Signer pin: signer 1.0.9 must pin the full local version, c2pa-python==0.37.13+signer.1.0.9. Under PEP 440, ==0.37.13 also matches the 1.0.8 wheel.

Release order for signer 1.0.9: see castlabs/stardustproof-c2pa-signer#55.

[mstattma]

@sripadmasm thanks for the review. You only have read access to castlabs/c2pa-python, so GitHub cannot record a formal approval here; your review above (approve, no blocker/major/minor findings) is recorded as an advisory approval. Publication still waits for a formal approving review from a reviewer with write access. Your two suggestions are adopted for publication: (1) after the tagged run, the native libc2pa_c.so / c2pa_c.dll SHA-256 in the 1.0.9 bundles will be compared with the 1.0.8 release (ID 415634231) and recorded; (2) signer 1.0.9 will pin the full local version c2pa-python==0.37.13+signer.1.0.9.