Berthly 1.3.1

Berthly 1.3.1 adopts apple/container 1.3.1, which is a security patch release.
Berthly links apple/container and apple/containerization as build dependencies
and runs some of that code in-process — not only in the daemon — so updating is
recommended.

Security

apple/container 1.3.1 bumps the Containerization package to 0.42.0, which
patches six advisories. Most live in daemon-side image-unpacking / content-store /
OCI-layout code and are fixed by updating your container install, but at least
one is in code Berthly itself compiles and runs:

• CVE-2026-65388 / GHSA-mx96-5vvg-x2mg — RegistryClient followed the
  WWW-Authenticate realm without validating its host or scheme. Berthly uses
  RegistryClient directly, with your Keychain credentials, for the background
  image-update check and for "Recreate with Latest Image" / pull. A hostile or
  MITM'd registry could have redirected the credential-bearing token request to
  another host or downgraded it to plain HTTP.

Also carried by 0.42.0: GHSA-x7pf-2jmj-pgcq, GHSA-f689-h8m7-3jp2,
GHSA-r3h2-rgqf-9hv9, GHSA-697p-8837-37h3, GHSA-g3rx-2m58-rr63.

Behavior change — plain-HTTP registries that require authentication

The CVE fix makes RegistryClient refuse the token exchange the moment a
non-HTTPS registry answers with a WWW-Authenticate challenge — whether or not
credentials are sent. What this means in Berthly:

Registry	Status on 1.3.1
Public HTTPS registry with normal auth (Docker Hub, GHCR, ECR, GCR, quay)	Unaffected
A plain local registry with no authentication (registry:2, "Allow insecure registry")	Unaffected — anonymous push/pull still work over HTTP
An HTTP registry that requires login (htpasswd / bearer-token auth) — including on localhost, a .internal name, or a private-network IP	No longer usable. Sign-in, pull, and push all fail. It needs an HTTPS endpoint.
An HTTPS registry whose auth server is on an unrelated domain	Now rejected (rare)

This is an upstream security decision, not a Berthly regression, and there is no
workaround short of serving the registry over HTTPS — the container CLI's own
registry login fails identically. Berthly now turns the failure into a plain
explanation ("apple/container 1.3.1 refuses to send credentials to a registry over
plain HTTP … this registry needs an HTTPS endpoint") on the Add Registry sheet,
instead of surfacing the raw refusing insecure credential exchange error.

Also in this release

• The registry-scheme picker and PARITY.md notes were corrected to describe the
  new "issues an auth challenge vs. doesn't" boundary rather than the earlier
  "authenticated vs. anonymous" framing.
• PARITY.md re-audited against container CLI 1.3.1 — no GUI parity gap opened or
  closed (1.3.1's only functional CLI changes, a tmpfs --mount fix and a Claude
  Code plugin, don't reach Berthly).
• Internal: silenced a pre-existing main-actor-isolation compiler warning on the
  registry-scheme resolver; tightened a flaky end-to-end test timeout.

---

Testing

This release shipped only after its gate run passed on the release commit:

• 532 unit tests passed — 90% line coverage of the pure
  logic layer (Berthly/Core models, mapping, and planning; 56%
  including the daemon/terminal I/O plumbing, which the end-to-end suite
  exercises against a real daemon instead).
• 77 UI tests (deterministic mock-daemon XCUITest) and
  20 real-daemon end-to-end journeys guard the UI wiring and the
  daemon integration. SwiftUI view bodies are covered by these suites, not
  unit tests, by design.

Full Changelog: v1.3.0...v1.3.1