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.json now carries a fixed public key, which is what pins the extension id and therefore the chrome.storage.local partition 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 key later 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:
(a) Keep the generated key. Nothing to do. Accepts that the private half was generated by tooling on this host.
(b) Generate your own and replace key before 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.
(c) Decide CRX packing is not wanted for 1.0 and treat the key field 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.
Two release-credential decisions surfaced by https://git.eeqj.de/sneak/AutistMask/pulls/347 (implementing https://git.eeqj.de/sneak/AutistMask/issues/310). Both are yours; neither blocks that PR from merging.
## 1. The Chrome signing key — decide before 1.0 ships, not after
`manifest/chrome.json` now carries a fixed public `key`, which is what pins the extension id and therefore the `chrome.storage.local` partition 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 `key` later 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:
- **(a) Keep the generated key.** Nothing to do. Accepts that the private half was generated by tooling on this host.
- **(b) Generate your own and replace `key` before 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.
- **(c) Decide CRX packing is not wanted for 1.0** and treat the `key` field 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.
clawbot
added this to the 1.0.0 milestone 2026-08-23 16:03:44 +02:00
sneak
was assigned by clawbot2026-08-23 16:03:44 +02:00
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 different chrome.storage.local partition 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.
One caveat on option (a)/(b), surfaced by the review of https://git.eeqj.de/sneak/AutistMask/pulls/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 different `chrome.storage.local` partition 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 the key stripped 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 as README.md states, 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 key later changes the extension id and orphans the storage partition.
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 `next` `a098bb0` — 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 the `key` stripped 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 as `README.md` states, 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 `key` later changes the extension id and orphans the storage partition.
Decision recorded on sneak's standing instruction to act on the recommendation: the generated Chrome key stays until sneak supplies one of his own (the swap is one PR when he does), and 1.0 ships without AMO signing, with the documented Developer Edition route. Nothing ships anywhere yet, so the key can still be replaced without cost. Closing; reopen with a public key to swap it in.
Model: fable-5-1
Decision recorded on sneak's standing instruction to act on the recommendation: the generated Chrome key stays until sneak supplies one of his own (the swap is one PR when he does), and 1.0 ships without AMO signing, with the documented Developer Edition route. Nothing ships anywhere yet, so the key can still be replaced without cost. Closing; reopen with a public key to swap it in.
Model: fable-5-1
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.Decision recorded on sneak's standing instruction to act on the recommendation: the generated Chrome key stays until sneak supplies one of his own (the swap is one PR when he does), and 1.0 ships without AMO signing, with the documented Developer Edition route. Nothing ships anywhere yet, so the key can still be replaced without cost. Closing; reopen with a public key to swap it in.
Model: fable-5-1