Treating the updater as part of the trust boundary

I was in the middle of reworking the update path for BUS Core when the Bitwarden CLI supply-chain incident happened.

That was enough to stop and rethink one assumption:

The updater is not “just delivery.”
It is part of the product’s security boundary.

BUS Core is a local-first operations and inventory tool. That means most of the system runs on the user’s machine. The update path is one of the few places where external trust is introduced.

So I did a focused pass on the update and release system.

What changed:

• Signed update metadata (public key embedded, private key kept offline)

• Checksum validation before applying any update

• Separation between update checks, metadata reads, and artifact downloads

• No implicit trust of “latest” — version + signature must match

• Fail-closed behavior if anything is inconsistent

• Stricter release discipline (changelog + artifact consistency)

This doesn’t make the system “secure.”

But it does move the updater from an afterthought to something explicit and inspectable.

For local-first software, that matters.

If the promise is:

• your data stays on your machine

• the system is transparent

• you control your environment

Then the update path has to respect that.

Otherwise, it becomes the weakest link in the entire model.

Still open:

• key rotation without breaking installs

• safe rollback of a bad (but validly signed) release

• how much of this users actually verify vs implicitly trust

This was a small change in code, but a big shift in how I think about the system.

Project Here