Auto-update the bundled extensions from our own store - #126
Merged
Merged
Conversation
We built a store with one-click install and Chromium auto-update -- crx.ts stamps our update_url into the manifest before signing, precisely so Chromium polls /api/store/updates.xml rather than Google. Then every listing was created by hand, which in practice meant almost none were: the store holds exactly one extension, and our own MarkSyncr is not in it. That is the gap worth closing. An extension in the store auto-updates for anyone who installed it. An extension outside the store reaches TronBrowser only by being rebuilt into the bundle, and reaches everyone else only when Google approves it. MarkSyncr has three releases sitting in Chrome review right now. So publishing runs from CI. scripts/store-publish.mjs resolves the listing by slug, creates it on first run, and posts the version with the manifest and the artifact URL. The reusable workflow wraps it so an extension repo adds six lines rather than its own half of the job. Two behaviours worth stating. A version that is already published exits clean instead of failing, so re-running a tag is safe. And the artifact is polled before submitting, because the store fetches it itself and a release asset can lag its tag by a few seconds -- submitting into that window fails for a reason that has nothing to do with the extension. Verified against the live store: an existing listing resolves by slug (coinpay-wallet), an unknown name takes the create path, and a manifest that is not MV3 is refused before anything is sent. Nothing publishes until TRONBROWSER_STORE_TOKEN exists. The API deliberately refuses to mint a publisher token from a token -- it has to come from a signed-in browser session -- so that one step is Anthony's and cannot be automated away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Extensions load with --load-extension, and Chromium never auto-updates an extension loaded that way. That is why a bundled extension could only change when the whole browser was re-released: v3.15.0 shipped a MarkSyncr vault import bug that had already been fixed upstream, and there was nothing to do but wait for the next TronBrowser build. So the launcher updates them itself, against tronbrowser.dev/store, which has no review queue in front of it. The store already stamps its own update_url into each signed manifest for exactly this purpose; what was missing was anything on this side asking. The bundled copy is never written to -- it lives in the install tree, which may be read-only and is replaced wholesale on upgrade. Newer versions land in an overlay under the data dir, and an extension loads from the overlay only while it is genuinely newer. When a browser upgrade brings the bundle level with it, the overlay is deleted rather than left to shadow it forever. The check runs detached and applies on the NEXT launch. Blocking startup on the network to save one launch's staleness is a bad trade, and swapping an extension's files under a running Chromium is worse. Everything about it fails soft: no curl, no unzip, an unreachable store, an extension the store has never heard of, a download that is not the extension we asked for -- each leaves the bundled copy in place. A browser that will not start because a store was down would be a far worse bug than a stale extension. TRONBROWSER_NO_EXT_UPDATE=1 turns the whole thing off. Two things worth keeping in mind. Versions are compared numerically per field, because a string compare puts 1.2.10 below 1.2.9. And this script runs under `set -eu`, so _manifest_version returns 0 with no output for a missing file: the first version of it returned 1, which inside a command substitution would have taken the browser down on every launch where the overlay did not exist yet. The functional test caught that before it shipped. Verified against the live store under set -eu: a staged coinpay-wallet 0.0.1 is replaced by 0.10.1 and loads from the overlay, an extension the store does not have is left alone, and the run survives to the end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
ThreatCrush Security Scan52 finding(s) HIGH/CRITICAL: 3 | MEDIUM: 28 | LOW: 21
…and 2 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Auto-update the bundled extensions from our own store
Extensions load with --load-extension, and Chromium never auto-updates an
extension loaded that way. That is why a bundled extension could only change when
the whole browser was re-released: v3.15.0 shipped a MarkSyncr vault import bug
that had already been fixed upstream, and there was nothing to do but wait for
the next TronBrowser build.
So the launcher updates them itself, against tronbrowser.dev/store, which has no
review queue in front of it. The store already stamps its own update_url into
each signed manifest for exactly this purpose; what was missing was anything on
this side asking.
The bundled copy is never written to -- it lives in the install tree, which may
be read-only and is replaced wholesale on upgrade. Newer versions land in an
overlay under the data dir, and an extension loads from the overlay only while it
is genuinely newer. When a browser upgrade brings the bundle level with it, the
overlay is deleted rather than left to shadow it forever.
The check runs detached and applies on the NEXT launch. Blocking startup on the
network to save one launch's staleness is a bad trade, and swapping an
extension's files under a running Chromium is worse.
Everything about it fails soft: no curl, no unzip, an unreachable store, an
extension the store has never heard of, a download that is not the extension we
asked for -- each leaves the bundled copy in place. A browser that will not start
because a store was down would be a far worse bug than a stale extension.
TRONBROWSER_NO_EXT_UPDATE=1 turns the whole thing off.
Two things worth keeping in mind. Versions are compared numerically per field,
because a string compare puts 1.2.10 below 1.2.9. And this script runs under
set -eu, so _manifest_version returns 0 with no output for a missing file:the first version of it returned 1, which inside a command substitution would
have taken the browser down on every launch where the overlay did not exist yet.
The functional test caught that before it shipped.
Verified against the live store under set -eu: a staged coinpay-wallet 0.0.1 is
replaced by 0.10.1 and loads from the overlay, an extension the store does not
have is left alone, and the run survives to the end.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com