fix(store): stamp our update_url into the .crx, so installs can update - #65
Merged
Conversation
#62 pruned them from build-release.sh, which covers linux/macos/deb/rpm/ AppImage. The Windows job stages separately with Copy-Item -Recurse and kept shipping them: v3.8.9's tronbrowser-win-x64.zip contains moshpit.test.js (12077B) and moshpit-drift.test.js (4106B). Mirror the prune in the pwsh path so every platform matches. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Chromium polls the update_url baked into the installed manifest — it never consults the feed the store advertises on the listing page. Most publishers omit it (it points at us, and they write their manifest long before they list here), so a store install pinned itself to whatever version it was installed at and never moved again, while the store served a correct updates.xml that nothing ever asked for. CoinPay Wallet is the live case: the store, its gupdate feed and the packed .crx are all at 0.9.2, but the shipped manifest has no update_url, so every existing install sits on the version it was first given. The .crx is packed on demand and we already know the feed URL, so set it there, before signing (the CRX3 signature covers the zip bytes). Overwriting a publisher's own update_url is deliberate: the id comes from the store's signing key, and only our feed can serve an update Chromium accepts for it. Verified against the real published 0.9.2 bundle: all 13 files stay byte-identical, only the empty directory entries drop (Chromium recreates those from the paths), and the resulting .crx carries the feed URL. Note this cannot rescue already-installed copies — they have no update_url to poll, so they need one manual reinstall to get onto the channel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
ralyodio
marked this pull request as ready for review
August 1, 2026 08:50
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.
Why
Chased down "still getting CoinPay Wallet v0.9.0". Every server-side link is already correct:
coinpayportalmasterextension-v0.9.2asset/api/store/extensions/coinpay-wallet)live/api/store/updates.xml)download.crxThe break is on the client. Chromium polls the
update_urlbaked into the installed manifest — it never consults the feed the store advertises. CoinPay Wallet's manifest has noupdate_url(neither does its zip), so every install pins itself to the version it was first given, and the store's correctupdates.xmlis never fetched by anyone.routes.tseven documents the assumption — "Extensions setupdate_url… in their manifest" — but nothing enforces or supplies it, and publishers write their manifest long before they list here.What
packCrxsigned the publisher's zip bytes verbatim. Since the.crxis packed on demand and the route already knows the feed URL,stampUpdateUrlnow rewritesmanifest.jsonto point at it, before signing (the CRX3 signature covers the zip bytes).Overwriting a publisher's own
update_urlis deliberate: the extension id is derived from the store's signing key, so only the store's feed can serve an update Chromium will accept for that id — a foreignupdate_urlpoints at a different id and silently does nothing.Verification
services/apistore suite: 52/52 pass (5 new cases),tsc --noEmitclean..crxcarries the feed URL with the version intact.Caveat
This cannot rescue already-installed copies — they have no
update_urlto poll, so they stay put. Existing installs need one manual reinstall to get onto the update channel; everything installed after this lands updates on its own.🤖 Generated with Claude Code