chore: bump to 0.4.0 and make the CI security audit actually run

[imran-siddique]

Follow-up to #469, which is the decision that PR correctly left open. What started as a version bump turned up two more problems, and the third one needs your call before this can merge.

1. Version bump to 0.4.0

#469 put signed platform evidence in gateway.attestation_evidence so the verifier has something to check the TPM quote against. GatewayAddenda is extra="forbid", so a verifier built before that field rejects the claim as CLAIM_MALFORMED, and verify_trace_claim never reads cmcp_version, so there is no negotiation path.

	result
0.4.0 verifier, older claim with no evidence	fine, fields are optional and trace.runtime is still read as a fallback
pre-0.4.0 verifier, claim from a 0.4.0 gateway	CLAIM_MALFORMED on gateway.attestation_evidence

A wire-format addition older readers reject, so minor rather than patch. Claims with no evidence serialize byte-identically to 0.3.0. cmcp_verify.__version__ is untouched, since it ships inside the cmcp-runtime distribution.

2. No version-bump PR could ever have passed CI

All six test jobs failed on the security scan with:

cmcp-runtime Dependency not found on PyPI and could not be audited: cmcp-runtime (0.4.0)

pip-audit with no arguments audits the whole environment including this package's own editable install, and fails whenever the local version is not yet published. --skip-editable drops it and keeps auditing every real dependency.

3. That fix made the audit run for the first time, and it fails

This repository has been carrying a vulnerable cryptography pin behind an audit that never got far enough to report it.

advisory	what it is	fixed in	reachable here
CVE-2026-69249	duplicate self-signed intermediates cause exponential path building	49.0.0	yes
CVE-2026-69248	X.509 verifier accepts wildcard DNS names, escaping permittedSubtrees	49.0.0	yes
CVE-2026-69247	Bleichenbacher oracle in PKCS#7 EnvelopedData decryption	50.0.0	no

The first two are reachable in the way that matters most here: a TRACE claim carries cert_chain as untrusted input, and verify_ak_ek_chain and verify_vcek_chain build paths from it.

And it cannot be fixed from this repository. I tried the floor bump and reverted it, because it produces ResolutionImpossible rather than a secure install:

agt-core 4.0.0 / 4.1.0   cryptography<49.0             <- caps us at 48.x
agt-core 5.0.0           cryptography<50.0             <- would allow 49.0.0
                         agentrust-trace<0.3.0         <- but this repo needs >=0.5

Full analysis in #471, including the upstream ask: agt-core 5.0.0's agentrust-trace<0.3.0 pin looks like a packaging oversight, and lifting it is what unblocks a non-vulnerable cryptography here.

What is in this PR now

• 0.4.0 in pyproject.toml and cmcp_runtime.__version__, plus the CHANGELOG entry for the verifier break
• pip-audit --skip-editable
• a comment on the cryptography pin recording why it cannot move yet

Why it is red, and the decision

The audit now reports honestly, so CI fails on findings that are real. Two ways forward, and it is a risk-acceptance call rather than a technical one:

• Suppress and track. --ignore-vuln all three with the reasoning in the workflow file and Fix two reachable cryptography CVEs: needs an agt-core 4.1.1 with the cap lift backported #471. CI goes green, and two reachable advisories are accepted as known-unfixed.
• Fix upstream first. Get agt-core's agentrust-trace pin raised and released, then take cryptography>=49.0 with nothing suppressed. CI stays red until that lands.

I have deliberately not suppressed anything. Accepting a reachable vulnerability in the certificate-path code of an attestation verifier is a project-lead decision, not something a bump PR should quietly do.

🤖 Generated with Claude Code