Release CanastaBase 1.3.15 with Debian security updates

[Copilot]

The immutable 1.3.14 images contain 24 fixable HIGH/CRITICAL findings across amd64 and arm64. Current rolling images already include the patched Debian 12 packages.

• Patch release

  • Bump VERSION to 1.3.15, triggering publication of a new immutable image.
  • Preserve the immutable 1.3.14 tag.

• Release notes

  • Document the security-focused package refresh.

• Refs Scheduled CanastaBase image vulnerability scan #208

[github-actions]

🐳 The image based on b86982c1 commit has been built with 1.43.9-20260723-209 tag as ghcr.io/canastawiki/canasta-base:1.43.9-20260723-209

[jeffw16]

@copilot Does this fix all 168 high/critical security issues?

[Copilot]

@copilot Does this fix all 168 high/critical security issues?

Yes—for all 168 findings reported against 1.3.14. Those are 20 unique CVEs repeated across both architectures and affected package aliases; every finding has a fixed Debian 12 package version. A fresh build upgrades those packages, and the scheduled scan already reports 0 findings for both platforms of latest. Final confirmation will occur when 1.3.15 is published and rescanned after merge; the immutable 1.3.14 image itself remains vulnerable.

[cicalese]

Mechanically this is a correct security-rebuild release, and it's the step the observed drift called for. A few things to weigh, one of which is a governance question that matters more than the diff.

The mechanism is right

VERSION 1.3.14 → 1.3.15 is the correct trigger: on merge the push job rebuilds (the Dockerfile's aptitude upgrade pulls current Debian security packages), publishes canasta-base:1.3.15, and — since IS_RELEASE flips true — attests its SBOM. The immutable 1.3.14 tag is preserved. No code change needed; the rebuild alone refreshes the packages.

Governance: this is an auto-PR'd release

This is a bot-drafted VERSION bump opened off the rescan tracking issue — the pattern the project has decided against (rescan is a trigger/reminder, not automation that cuts releases; the version bump stays a deliberate human action). A human still reviews and merges, but the PR itself is the automation in question. Worth a conscious decision before accepting, rather than treating it as a routine PR — it sets the "rescan auto-cuts releases" precedent.

Fixes #208 is the wrong linkage

#208 is a workflow-managed rolling dashboard — the rescan opens/updates/reopens/closes it based on findings. It is not a bug a single release resolves. Merging with Fixes #208 auto-closes it, and the next nightly scan reopens it: 1.3.15 is a fresh rebuild that will still carry the most recently disclosed CVEs (latest, rebuilt hours ago, currently shows 4). That close-on-merge / reopen-on-scan flap muddies the issue history. Use Refs #208 and let the workflow own that issue's state.

Two smaller things

• The body cites "168 fixable findings." That's the pre-Count distinct CVEs in scheduled image rescans #211 inflated count; the honest figure is ~24 distinct CVEs. Awkward to ship a release PR quoting the exact inflation Count distinct CVEs in scheduled image rescans #211 just removed — please update it.
• The release note is a full sentence referencing the issue. The convention is a terse noun phrase + the PR number, e.g. 1.3.15 - July 23, 2026 - Rebuild with current Debian 12 security updates (#209).

Don't mistake this for "done"

Merging publishes a patched base, but because of the layered pinning it does nothing for deployed installs until Canasta bumps its BASE_IMAGE pin to 1.3.15 (→ new Canasta version) and the CLI bumps its canasta pin. It's step 1 of the three-layer manual walk — which is also why Fixes #208 overstates it: the deployed stack isn't remediated by this PR alone.

If it's kept: change Fixes #208 → Refs #208 and correct the body's stale number before merging.

[cicalese]

LGTM