What's Changed
Berthly now builds against apple/container 1.4.1 / containerization 0.45.0 (up from 1.3.1 / 0.42.0).
Security
containerization 0.45.0 fixes a moderate-severity advisory,
GHSA-4587-w9mm-xxvh:
OCI image load followed a symlink named oci-layout or index.json inside
the archive to anywhere on the filesystem, so a crafted archive could pull
image metadata from outside the extraction directory — reachable through
Berthly's Load OCI tar sheet.
This matters for how you get the fix. Image extraction runs inside
container-apiserver, not inside Berthly itself — updating Berthly to 1.4.1
patches Berthly's own build, but a daemon still on 1.3.1 or earlier is still
running the vulnerable extraction code. You need container itself on
1.4.1 for the fix to actually apply. Berthly's version gate (below) makes
sure you can't miss that.
(A second advisory, GHSA-rgqp-277h-gcwj — a Unix-socket path buffer overflow
— is also fixed in 0.45.0 but isn't reachable through anything Berthly does;
noted for completeness.)
Version gate is now stricter
container installs on 1.2.x or 1.3.x now hit a blocking "update
required" gate instead of running as-is — a deliberate change, not a
regression. Two things made this the right call:
- The vulnerability above only reaches you once the daemon itself is on
1.4.1; a soft "recommended" nudge would leave older installs exposed
indefinitely. - This also fixes a real bug: Berthly's minimum-supported-version marker had
drifted to1.2.2even after the app moved to building against 1.3.1, so
first-time installs and the in-app updater were silently shipping a
two-versions-stalecontainerinstaller, and the "update available"
nudge never fired for a 1.3.x daemon at all.
The gate still offers a one-click in-place upgrade to 1.4.1, not just a bare
error message.
Docs
PARITY.md re-audited against container CLI 1.4.1. The new container clean
command is documented as a deliberate gap: it runs an fstrim on a running
container's rootfs and its writable volume mounts to reclaim host disk space
— it deletes nothing, so it's unrelated to Berthly's delete/prune actions.
container system status's richer output and the JSON slash-escaping change
in 1.4.1 don't affect Berthly — it talks to the daemon over the client API
directly rather than parsing CLI output.
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; 50%
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.1...v1.4.1