github henrywang/Berthly v1.4.1
Berthly 1.4.1

5 hours ago

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 to 1.2.2 even 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-stale container installer, 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/Core models, 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

Don't miss a new Berthly release

NewReleases is sending notifications on new releases.