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 —
RegistryClientfollowed the
WWW-Authenticaterealm without validating its host or scheme. Berthly uses
RegistryClientdirectly, 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.mdnotes were corrected to describe the
new "issues an auth challenge vs. doesn't" boundary rather than the earlier
"authenticated vs. anonymous" framing. PARITY.mdre-audited against container CLI 1.3.1 — no GUI parity gap opened or
closed (1.3.1's only functional CLI changes, a tmpfs--mountfix 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/Coremodels, 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