Shorebird's got your back: patch signing is now on by default

Wesley Peck
Wesley PeckLead Product Manager

4 min read

The internet runs on trust, and last week a piece of that trust broke. Eight intermediate certificates issued by eMudhra, an Indian certificate authority, turned out to have compromised private keys.

Browsers have already blocked these certificates. This post explains how it affects apps built with Shorebird, and what we’re changing so that this kind of problem can’t reach your app’s new releases.

What happened and how it affects Shorebird apps

On October 17, Mozilla received a report that the private keys of eight eMudhra intermediate certificates had been compromised. Six of these could be used to issue valid-looking HTTPS certificates for any website. Cloudflare’s write-up is a good summary.

Chrome and Firefox have already blocked these certificates, but software that carries its own list of trusted certificates is still at risk until it’s rebuilt. Shorebird’s updater carries its own list, which includes the compromised certificates, built into your app at build time.

While these certificates are in your app, someone on the network between your users and Shorebird (public Wi-Fi, a compromised router) could pretend to be Shorebird and offer your app a patch of their own.

This is not a breach of Shorebird’s servers or your data. We know of no attack using these certificates against any Shorebird app.

Two things that protect your app

Shorebird’s engine for Flutter 3.47.8 removes the compromised certificates, so a release built on Flutter 3.47.8 with the latest Shorebird CLI no longer carries them.

Code Push patch signing, available since 2024, blocks this attack on any Flutter version: your release contains a public key, and your app only installs patches whose signatures match that key, so an attacker with a forged certificate can’t install a patch. If you’re already using patch signing, you’re already protected.

What we’re changing: signing is on by default

Not everyone is using patch signing, so starting today, every new release made with the latest Shorebird CLI is signed by default. If you don’t bring your own key, Shorebird creates one for your organization in Google Cloud KMS and builds its public key into your release. Every patch to that release is then signed automatically. The private key never leaves KMS, and no one at Shorebird can export it.

There’s nothing to configure, and nothing changes in how you run shorebird release or shorebird patch, in your terminal or in CI. Each release and patch in the console shows whether it’s signed.

This doesn’t override your own patch signing either. If you want to manage your trust chain end to end, you can still bring your own key.

What you need to do

  1. Already using patch signing? Nothing. Your releases keep using your own key.
  2. Everyone else: update the Shorebird CLI (shorebird upgrade) and release a new version of your app. That release is signed by default, which protects it on any Flutter version. Releasing on Flutter 3.47.8 also removes the compromised certificates from your app.

Your existing releases keep working as before. Your users are protected as they move to the new release.

What managed signing does and doesn’t protect against

Managed signing narrows who your app has to trust for patches to just Shorebird and Google, instead of every certificate authority on a bundled list.

  • An attacker on the network, or with a forged certificate: blocked.
  • An attacker who can change files in patch storage or on our CDN: blocked.
  • An attacker who takes over Shorebird’s servers, Google Cloud, or your Shorebird account: not blocked, because they could ask for a patch to be signed.

If you need Shorebird out of your trust chain entirely, bring your own key. It is still the strongest option, and nothing about it changes. You can switch from managed signing to your own key at any release; earlier releases keep their managed key and keep getting signed patches.

If you need to make an unsigned release for some reason, shorebird release takes --no-patch-signing. We don’t recommend it.

Final notes

One of the most important things you can do to ensure your app’s security is to keep your Flutter version current. We highly recommend being on the newest stable version of Flutter whenever possible.

Patch signing should never have been something you had to opt into, and now it isn’t. For more on how Code Push keeps your users safer, read Code Push makes your app more secure, not less.

Start shipping fast, today!

Integrate with your current codebase in less than 5 minutes.