What it takes to trust an open-source app that updates itself

#kubernetes #opensource #security #buildinpublic

An auto-updater is a strange thing to ship in open source. You're asking someone who chose your project specifically because they could read the code to now trust a binary that lands on their machine without them clicking anything.

ROZOOM's 0.23.0 release ships the first version of that channel: a background check, a silent download, and one entry in the notification bell - no toast, no modal stealing focus - "Rozoom 0.23.1 is ready / Restart to finish updating," with a single action, "Restart now." Nothing else changes until you click it.

Here's what that channel actually is, and what happened before we trusted it enough to ship it.

What actually updates itself

The updater works on AppImage (Linux), Windows, and macOS (Apple Silicon) builds. Deb and rpm packages don't auto-update - that's not a footnote, it's the whole story if you're on one of those: you keep updating by hand, the way you already do.

If you're on 0.22.6, this update won't find you automatically. 0.22.6 doesn't have an updater in it at all - there was nothing there to check with. Install 0.23.0 by hand, once. From there, supported platforms take over.

The part that isn't in the release notes

Every update ROZOOM downloads gets checked against a signing key before it's allowed to install. Get that key wrong once and you've built a supply chain for anyone who compromises it.

Ours almost was. The key pair got sent through a messenger app before it ever shipped - a private key and its password, together, outside the places we'd normally trust either. No release had used it yet, so we didn't debate it: we rotated the pair and treated the old one as burned. The cost of doing that before publishing is one line in a config file. After publishing, it's every installed copy losing its update channel for good.

The second thing was less dramatic and more revealing. Turning on this feature meant making the AppImage build a hard requirement instead of a "best effort" step - and the moment we did, it stopped passing. It turned out our AppImage build had been silently failing behind a continue-on-error flag since 0.22.3. Every Linux release for months had shipped without one, and CI stayed green the whole time.

Fixing it for real took three passes, each one a public PR:

the build was resolving system libraries from vendored dependency folders instead of the host, and fell over (#160)
that fix exposed a second one: a GTK plugin inheriting the same lookup path and grabbing an incompatible zlib (#161)
only after both landed did a full run go green on Linux, Windows, and macOS together (#159)

What we watched happen

0.23.1 existed for exactly one reason: prove the update path works outside CI, on a real machine, not just that the artifacts exist. We installed 0.23.0 fresh, let the updater find 0.23.1 on its own, and let it run start to finish - background check, silent download, one entry in the bell.

Clicked "Restart now," confirmed the one prompt it puts up - any open exec sessions close - and the app came back. Sidebar showed 0.23.1, notification gone, binary hash matching the published release asset.