decision: who owns the Chrome CRX signing key, and does 1.0 require AMO signing for Firefox #348
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two release-credential decisions surfaced by #347 (implementing #310). Both are yours; neither blocks that PR from merging.
1. The Chrome signing key — decide before 1.0 ships, not after
manifest/chrome.jsonnow carries a fixed publickey, which is what pins the extension id and therefore thechrome.storage.localpartition holding the wallet. The implementer generated the keypair; the private half is at/srv/code/_clawbot_secrets/autistmask-chrome-crx-key.pem(mode 0600) on the build host, and nothing of it is in the repo.Changing
keylater changes the extension id and orphans the existing storage partition — a wallet installed under the old id reads as empty. So this is cheap now and expensive after you have funds in it.Options:
keybefore any real use. Recommended if you intend this to hold real funds — you would own the only copy from the start. Say the word and I will open a PR swapping in a public key you provide.keyfield purely as an id-stabiliser, which is all it currently does. Publishing to the Chrome Web Store is out of scope either way.Recommendation: (b) if this wallet will hold anything you care about, otherwise (a).
2. AMO signing for Firefox
Not attempted — it needs AMO credentials. The PR ships an unsigned XPI and documents that release Firefox and ESR will refuse it, so Firefox use requires Developer Edition or Unbranded.
If 1.0 must install on release Firefox, AMO self-distribution signing is required and only you can authorize it. Otherwise the documented Developer Edition route stands and this closes as won't-do for 1.0.
Recommendation: ship 1.0 with the documented Developer Edition route, and treat AMO as a follow-up — it is an outward-facing publishing act, not a code gap.
One caveat on option (a)/(b), surfaced by the review of #347 and worth knowing before you choose: the Chrome Web Store assigns its own extension id at first upload and does not honour a manifest
key. So a Web Store install would land on a differentchrome.storage.localpartition than an unpacked or CRX install of the same build.Publishing is out of scope here either way, but it is the one install route where the id-stability guarantee this PR just bought does not hold — relevant if the long-term plan is a store listing rather than a self-hosted CRX.
Status for the decision: this is the last open item in milestone 1.0.0 (87 closed, 1 open). Everything else has been verified working by loading the built extension in real browsers at
nexta098bb0— first run, browser restart, phrase import, a cold-worker non-mainnet dApp send broadcasting at chainId 11155111, the approval screen with a positive control behind every refusal, the corrupt-state recovery screen, and the storage partition proven with thekeystripped as a control.Chrome is deployable today. Nothing found blocks day-one use there.
Firefox is the whole of what is left, and it is a decision rather than work. Confirmed by inspection of the built artifact: the XPI has no
META-INF, so it is unsigned exactly asREADME.mdstates, and release Firefox and ESR will refuse it. Daily Firefox use therefore means Developer Edition, Nightly or Unbranded — or re-adding a temporary add-on on every browser start.So question 2 reduces to: does 1.0 ship Firefox as "Developer Edition or unbranded build only", documented as it already is and needing no further work — or does it block on AMO self-distribution signing, which needs credentials only you have?
Question 1 (the CRX key) is unchanged and still worth deciding before real funds go in, for the reason given above: changing
keylater changes the extension id and orphans the storage partition.