chore: release: v3.14.1

[kevindeforth]

resolves #4174

[claude]

PR title type suggestion: The prefix release: is not a standard conventional commit type. For version bumps and lock file updates, use chore: instead.

Suggested title: chore: release v3.14.1

[gilcu3]

Nice!

nit: (you fixed it while I was writing :) )

[claude]

Pull request overview

Release-boilerplate PR cutting v3.14.1 off release/v3.14, split out of the closed #4172 (the substantive content landed separately via #4177, #4178, #4179). It is the mechanical output of scripts/ops/prepare-release.sh: workspace version bump, prepended git-cliff changelog section, refreshed ABI snapshot, regenerated license notices.

I verified the generated artifacts: all four PRs merged into release/v3.14 since the 3.14.0 tag (#4177, #4178, #4179, #4186) appear in the new changelog section, the version is consistent across Cargo.toml, Cargo.lock, the ABI snapshot and licenses.html (34 workspace crates in both Cargo.lock and licenses.html), and no stale 3.14.0 references remain outside the intentional migration-module names/comments. The findings below are about what the release communicates and the docs it ships, not the boilerplate itself.

Changes:

• Workspace version 3.14.0 → 3.14.1 (Cargo.toml, propagated through Cargo.lock).
• New ## [3.14.1] changelog section listing the four release-branch PRs under "Miscellaneous Tasks".
• Contract ABI snapshot version string updated; third-party license notices regenerated.

Reviewed changes

Per-file summary

File	Description
Cargo.toml	[workspace.package] version → 3.14.1.
Cargo.lock	34 workspace crates re-versioned to 3.14.1; no dependency changes.
CHANGELOG.md	New [3.14.1] - 2026-08-19 section, all four entries under "⚙️ Miscellaneous Tasks".
crates/contract/tests/snapshots/abi__abi_has_not_changed.snap	metadata.version → 3.14.1 (only change — the ABI itself is unaffected).
third-party-licenses/licenses.html	Workspace crate versions in the MIT "Used by" list bumped to 3.14.1.

Findings

Blocking (must fix before merge):

• CHANGELOG.md:8-18 — this section is lifted verbatim into the GitHub release notes (.github/workflows/release.yml:83), and as generated it presents the whole release as four housekeeping chores. The actual operator-visible payload of 3.14.1 is:

  • attestation validity window 7 → 21 days (crates/mpc-attestation/src/attestation.rs:28),
  • launcher_hash_unused_ttl_seconds default 14 → 21 days (crates/contract/src/config.rs:45),
  • a 3.14.0 → 3.14.1 migration that mutates stored state — it extends every current participant's stored Dstack attestation expiry by 14 days and raises the stored TTL (crates/contract/src/v3_14_0_state.rs:55-74, crates/contract/src/tee/tee_state.rs:500-521).

  "Extend attestation expiration dates (chore: extend attestation expiration dates #4178)" under Miscellaneous Tasks conveys neither the magnitude nor that migrate() rewrites attestation state — yet that is precisely what operators are being asked to vote in (per testnet contract release 3.14.1 #4174, voting in a contract instead of running an emergency migration is the entire point of this release). RELEASES.md §Changelog conventions and the --prepend rationale in scripts/ops/prepare-release.sh:88-96 explicitly support hand-authored sections, so please add an explicit block, e.g.:

  ### ⚠️ Contract behavior changes
  
  - Attestation validity window: 7 → 21 days (`DEFAULT_EXPIRATION_DURATION_SECONDS`).
  - `launcher_hash_unused_ttl_seconds` default: 14 → 21 days.
  
  ### 🔀 Migration (3.14.0 → 3.14.1)
  
  - `migrate()` extends each current participant's stored Dstack attestation expiry by 14 days
    and raises `launcher_hash_unused_ttl_seconds` to at least 21 days.

  Related: RELEASES.md §SemVer states a patch is "bug fixes only, full backward compatibility". A tripled attestation window plus a state-mutating migration is a deliberate exception here — better stated in the notes than left implied by a chore label.

• Documentation drift shipping with the release (review-blocking per CLAUDE.md §Documentation alignment). chore: extend attestation expiration dates #4178 changed both constants without touching any doc; this PR is the last gate before the tag, so it needs fixing here or in one follow-up commit on release/v3.14 before the Release workflow runs:

  • docs/running-an-mpc-node-in-tdx-external-guide.md:1670 and :1829 — operator-facing, both still state launcher_hash_unused_ttl_seconds, "default 14 days".
  • docs/design/auto-remove-launcher-hashes-design.md:37,40,75,115-117,125,149-150 — "default 14 days", "currently 7 days", "14 days after the last node leaves", "fresh 14-day". Lines 80-81 are now actively false: "the 14-day default is >= DEFAULT_EXPIRATION_DURATION_SECONDS (the attestation window, currently 7 days), leaving ample margin" — it is 21 vs 21, i.e. exact equality, zero margin. That matters because the migration extends expiries additively (v3_14_0_state.rs:63-69) while config.rs:86-89 documents that a TTL change does not re-date existing launcher entries, so between migration and the next refresh_launcher_usage an extended attestation can outlive its launcher entry's old 14-day stamp. It self-heals on the next verify_tee, but the margin the doc claims no longer exists, and Config::validate (crates/contract/src/config.rs:127) only compares defaults, not per-entry expiries.
  • docs/design/attestation-verifier-contract.md:214 — "today a hardcoded DEFAULT_EXPIRATION_DURATION_SECONDS of 7 days", and it proposes lowering that constant to ~1 day as the lever bounding a wrongly-accepted entry's lifetime. This release moves it the other way; needs updating or a "superseded by" banner.
  • docs/design/operator-prepaid-attestation-storage.md:30 (and :149) — "Reclamation waits for the entry to expire (7 days)" is the basis for the "prepay for a spare" guidance; operators now wait 3× longer.
  • docs/threat-model-diagram.md:286 — T11 "verify_tee kicks nodes after 7 days".

Non-blocking (nits, follow-ups, suggestions):

• Forward-port gap for chore: extend attestation expiration dates #4178. Code search over the default branch confirms main still has DEFAULT_EXPIRATION_DURATION_SECONDS = 60 * 60 * 24 * 7 and DEFAULT_LAUNCHER_HASH_UNUSED_TTL_SECONDS = 14 * 24 * 60 * 60, and extend_dstack_attestation_expiries has no hits there — whereas ci: move runner images to ubuntu 26.04 #4177 and ci: fix the skopeo image to use an immutable tag #4186 do have main counterparts (ci: move runner images to ubuntu 26.04 #4134, ci: fix the skopeo image to use an immutable tag #4184). So 3.15.0 cut from main silently reverts this hotfix, and main's migration path would inherit 3.14.1 state carrying already-extended expiries without knowing about them. main has also moved migrate() into crates/contract/src/api/lifecycle.rs, so it is not a clean cherry-pick. Worth tracking as a blocker for the next minor rather than for this PR.
• When 3.15.0 is cut from main, ci: move runner images to ubuntu 26.04 #4134/ci: fix the skopeo image to use an immutable tag #4184 will re-appear in the generated section as duplicates of what 3.14.1 already shipped. Per the .cliffignore convention in RELEASES.md (and the existing 3.9.1 block), consider appending them on main at that point.
• CHANGELOG.md:8 stamps the prep date (2026-08-19), not the publish date — fine if the Release workflow runs promptly, off by however long the release slips.

⚠️ Issues found