a874299412e0bdc148a4134e6d11635662e761c5
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a874299412 |
release: package the extension, pin the Chrome extension id, and prove the wallet survives a reinstall (closes #310)
There was no packaging target anywhere, no artifact, and no `key` in `manifest/chrome.json` — so an unpacked Chrome load derived its extension id, and therefore its `chrome.storage.local` partition, from the absolute checkout path. Moving or re-cloning the checkout presented an empty wallet, with no error and nothing in the UI to say so. `manifest/chrome.json` now carries a fixed `key`: the public half of an RSA keypair, which pins the extension id to `gipbhkogfopeahplcjhipkgpcimdpkip`. The private half is a credential and is not in this repo; no target generates one into the working tree, and `tests/extensionId.test.js` fails if a `.pem` is ever committed. Changing `key` changes the id and orphans every wallet stored under the old one. `make package` (script/package) runs `make build` — the only audited path to a release build — and writes one self-contained, versioned archive per browser into `release/`, plus `SHA256SUMS`. The archives are deterministic: entries sorted, timestamps fixed, compression level fixed, so two builds of one commit are byte-identical. Self-containment is checked rather than assumed: every path the manifests and the popup HTML reference is resolved and required to be inside the archive, a reference that climbs out of the extension root is a hard failure, and files left at the `dist/` root — `dist/styles.css`, which build.js copies into each browser directory — are reported as deliberately not shipped rather than dropped by a glob. The archive is then read back off disk and compared member by member against the directory it was built from. The zip writer and reader are stdlib zlib in `script/lib/zip.js`; no new dependency, and nothing unpinned. One version, enforced rather than generated. `script/lib/version.js` requires `package.json`, `manifest/chrome.json` and `manifest/firefox.json` to agree and fails the build naming each file and what it said, instead of reading from one of the three. `BUILD_COMMIT` now carries `-dirty` when the working tree does not match `HEAD`, and `-unknown` when git cannot say; the full hash behind the About screen's commit link stays clean so the link still resolves. Two real-browser observations, both run through the pinned harnesses: - `tests/e2e/storagePartition.js` loads the build from two different paths in one Chrome profile. With `key`: same id, and the second load reads the first load's storage. Without `key`: different ids, and the second load sees an empty partition. Loading both keyed copies at once yields one id, not two. - `tests/e2e/firefox/reinstall.js` installs the packaged XPI in a real Firefox, creates a wallet, quits the browser, restarts on the same profile, adds the add-on again, and decrypts the vault back to the original recovery phrase. It then observes that an explicit uninstall DESTROYS that storage — correct browser behaviour, but for a wallet it means Remove is irreversible except from the recovery phrase, so README.md says so. Firefox ships an UNSIGNED XPI. README.md states plainly that release Firefox and ESR will refuse it, that Developer Edition, Nightly or an Unbranded build is required, and that a temporary add-on does not survive a browser restart. AMO signing, CRX packing, tagging and any upload are deliberately out of scope. |
||
|
|
12b0c4d1c6 |
build: remove dist/ when a release build fails (closes #333)
A failed release build no longer leaves a complete, loadable debug bundle in dist/ whose every wallet uses the publicly committed test recovery phrase. Each step of the release build runs through script/discard-dist-on-failure, which removes dist/ on failure, says on stderr that it did and why, and returns the step's own status. build-debug is deliberately unwrapped. script/verify-build is untouched. |
||
|
|
aea999db85 |
build: make verify-build take an explicit expectation and a build receipt (closes #309)
verify-build read its expectation from AUTISTMASK_DEBUG in its own environment and the Makefile invoked it bare, so an operator with that variable exported who ran the release target got an INSECURE debug build — every wallet it creates uses the publicly committed test phrase — verified green, exit 0. It also had no provenance: a 26-byte file containing the right marker string passed, the content script and manifest.json were never inspected, and an entire hand-written dist/ passed. --expect release|debug and --receipt PATH are now both required, with no defaults and nothing read from the environment. build.js records every file it emits with its sha256 and writes the receipt; the Makefile mktemps it outside the repo per invocation with a trap, and build.js refuses a receipt path inside dist/. Verification runs three passes in a load-bearing order — receipt shape, full dist/ walk, then per-file bytes — so an unwalkable subtree cannot make files look absent. dist/constants-bundles.txt, which was an unsigned trust root living inside the tree it vouched for, is gone. What this proves is bounded and stated as such: dist/ is byte-for-byte the output of the build.js run that just finished, within one make build invocation. It proves nothing about the honesty of the source tree or build.js, and nothing to anyone handed a dist/ from elsewhere — that is signing, #310. The standalone make verify-build target is removed because its only input would be dist/ itself, i.e. the artifact vouching for itself. Verified: make check green, test-verify-build 39 cases (was 18), test-e2e 55/55 and test-e2e-firefox 8/8 with make build running uncached inside both images. All four original bypasses now exit 1. Mutations: digests disabled fails exactly 4 cases, dropping the dist/ walk fails exactly 8, restoring the ambient fallback fails exactly 1. |
||
|
|
ff3387d8cf | feat: vendor and censor the phishing blocklist at build time (closes #219) | ||
|
|
52c7c1b060 |
test: containerized Firefox end-to-end harness (closes #184)
check / check (push) Successful in 34s
Drives the real popup in a real Firefox with dist/firefox/ installed as an unpacked MV2 temporary add-on via geckodriver. make test-e2e-firefox, outside make check like the Chrome suite. Zero npm dependencies: plain fetch and child_process against geckodriver's HTTP API. Base image, Firefox tarball and geckodriver are each pinned by digest and verified at build time. Error capture reads the privileged console service through Marionette's chrome context, not WebDriver BiDi. BiDi delivers nothing at all for extension pages, so a BiDi-based harness would observe zero events and report success -- the vacuous-check shape this repo has shipped twice. Both the driver and the README say so where someone would be tempted to simplify. Demonstrated to discriminate: a background page that throws at the top of the file, a missing import, and an async throw where every UI assertion still passes each fail the run. Three limits are measured and documented rather than papered over: capture is poll-based so an error is attributed to a step, not a moment; the console ring buffer holds 250 messages and evicts the oldest, measured against a clean-run peak of 4; and the drained window ends roughly 1.5s after the last step, with observed jitter rather than a hard boundary. Content-script capture is marked unverified because --network none leaves no page to inject into, and that same choice inverts coverage of network-dependent code. |
||
|
|
86cdea5e4e |
chore: repo policy compliance sweep — test rerun, frozen lockfile, documented targets (closes #166)
check / check (push) Has been cancelled
|
||
|
|
e9fa8bec47 |
build: assert DEBUG is off in every emitted bundle as a post-build check (closes #170)
check / check (push) Successful in 18s
build.js records which emitted bundles contain src/shared/constants.js, and constants.js carries a marker constant-folded from DEBUG itself. script/verify-build cross-checks the two and fails on every way of not knowing, so deleting the __BUILD_DEBUG__ define now breaks the build instead of shipping a live debug branch. |
||
|
|
e8ad8325c8 |
test: containerized Chrome end-to-end harness that drives the real popup (closes #181)
check / check (push) Has been cancelled
Runs the real popup in a pinned containerized Chrome and fails on any uncaught page error or console.error. Also fixes the two defects it caught: the missing showView import in addToken.js and the missing addressDotHtml import in transactionDetail.js. closes #150 closes #151 |
||
|
|
f7f141a757 |
security: make DEBUG a build-time flag defaulting to off (closes #149) (#169)
check / check (push) Has been cancelled
Fixes the highest-severity item in the repo: `src/shared/constants.js` had `const DEBUG = true;`, so `generateMnemonic()` returned the publicly committed `DEBUG_MNEMONIC` for every wallet created from a build of `main`, and the real entropy path was dead code in every artifact we could produce. ## What changed **`build.js`** — `AUTISTMASK_DEBUG` is read from the environment and injected as a `__BUILD_DEBUG__` entry in the existing esbuild `define` map, next to the other `__BUILD_*__` defines. Only the exact value `1` enables it; unset, empty, `true`, or a typo all yield a release build, so the insecure direction requires a deliberate opt-in and any mistake fails safe. The build prints `Build mode: release (DEBUG off)` or `Build mode: DEBUG (INSECURE - hardcoded test mnemonic, do not ship)`. **`src/shared/constants.js`** — `DEBUG` now uses the same `typeof` guard that `src/shared/buildInfo.js` already uses for the other build-time defines, and defaults to `false` when the define is absent (jest, plain `require`). `DEBUG_MNEMONIC` stays in the tree and stays exported. **`Makefile`** — new `build-debug` target (`AUTISTMASK_DEBUG=1` + the same build) so a debug build stays a one-liner for development. **`README.md`** — new "Debug Builds" subsection under Getting Started, and the DEBUG Mode Policy section now states that `DEBUG` is build-time-only and spells out the boundary against the runtime toggle. **`tests/wallet.test.js`** — new, covering both build modes. **`TODO.md`** — refreshed in the same commit (details at the bottom). No new `if (DEBUG)` branch was added and nothing about what DEBUG *does* changed: still exactly the red banner plus the hardcoded test phrase, per the README DEBUG Mode Policy and `RULES.md:76-80`. ## The interaction with the #145 settings toggle This is the subtle part, so spelling out the reasoning. There are two distinct debug flags in the tree after #145: 1. the compile-time `DEBUG` constant from `constants.js`, and 2. the runtime `debugMode` state flag, which the settings easter egg toggles and which `settings.js:379` pushes into `log.js` via `setRuntimeDebug()`. `log.js` merges them: `isDebug()` is `DEBUG || _runtimeDebug`. That merged value feeds exactly two things — the log level threshold (`log.js:24`) and the red banner (`views/helpers.js:71`). Making the banner user-toggleable is the intended behavior of #145, and this PR leaves it alone. `generateMnemonic()` does **not** consult `isDebug()`. It reads the compile-time `DEBUG` binding directly. That distinction is what makes a release build coherent: with `__BUILD_DEBUG__` false, `DEBUG` is false in the bundle, so no amount of clicking the version ten times and flipping the toggle can reach `return DEBUG_MNEMONIC`. The user can turn the banner and verbose logging on in a release build; they cannot turn the hardcoded phrase on. The failure mode to guard against is someone later "tidying up" the two flags by routing `wallet.js` through `isDebug()`, which would silently reintroduce this exact vulnerability with the runtime toggle as the trigger. Three things now guard that: a comment at the `wallet.js` call site saying it must stay the compile-time constant and why, the same statement in the README DEBUG Mode Policy, and a regression test that calls `setRuntimeDebug(true)`, asserts `isDebug()` is genuinely true, and then asserts `generateMnemonic()` still returns fresh entropy. I considered instead making the runtime toggle unavailable in release builds, but rejected it: that removes a feature #145 deliberately added, and it defends the wrong boundary. The banner is not the dangerous part; the mnemonic path is, and that one is already unreachable. ## Verification `make check` — green, 5 suites, 55 tests, plus lint and fmt-check. It also ran via the pre-commit hook on the commit itself. The new tests, per the verification standard in the manager comment on the issue (not just `a !== b`) — with the flag off: two successive `generateMnemonic()` calls differ, both pass `isValidMnemonic`, both are 12 words, neither equals `DEBUG_MNEMONIC`, and the result derives a usable HD wallet (`xpub` + a well-formed first address), so a broken implementation returning a counter or a truncated phrase would fail. Same assertions again with the runtime toggle forced on. With the flag on (`__BUILD_DEBUG__` defined before a `jest.resetModules()` re-require): `DEBUG` is `true` and `generateMnemonic()` returns `DEBUG_MNEMONIC`, so the debug path is proven working rather than silently deleted. Build artifacts — `make build` and `make build-debug` both produce `dist/chrome` and `dist/firefox` successfully. Grepping the minified bundles for the emitted `DEBUG` export value across all four bundles (chrome popup, chrome background, firefox popup, firefox background): # after make build $ grep -roh 'DEBUG:![01]' dist/chrome dist/firefox | sort | uniq -c 4 DEBUG:!1 # after make build-debug $ grep -roh 'DEBUG:![01]' dist/chrome dist/firefox | sort | uniq -c 4 DEBUG:!0 `!1` is minified `false`, `!0` is `true`. Also checked the fail-safe path: `AUTISTMASK_DEBUG=true make build` prints `Build mode: release (DEBUG off)` and likewise yields `4 DEBUG:!1`. One thing a reviewer should know about the grep: the `DEBUG_MNEMONIC` string literal is still present in the release bundle. That is not a leak of anything (the phrase is in this public repo already) and it does not mean the branch is live — esbuild cannot tree-shake a CommonJS `module.exports` object, so the constant survives while `DEBUG` folds to `false`. The compiled function is `function PL(){return ML?UL:f_.fromEntropy(globalThis.crypto.getRandomValues(new Uint8Array(16))).phrase}` where `ML` is the `DEBUG:!1` export. So "the phrase string is absent" is *not* the right test for a release build; "the exported `DEBUG` is `!1`" is, which is what I checked. ## `TODO.md` refresh Per the manager comment: Status rewritten (no branch in flight — `feat/issue-144-settings-about` landed as #145, scripts-to-rule-them-all landed as #148, so the `scripts/` question is resolved; `make check` recorded as verified green on `main` at `23aeae4`); the completed "Verify main passes make check" Future Step removed; Future Steps rewritten against the #149-#168 backlog in rough priority order, keeping branch pruning (now #167) and the pre-1.0 security review (noting #149 and #157 are parts of it but it is broader). One deliberate deviation to flag rather than bury: the manager asked that Next Step become this issue. Taken literally against the Workflow section, this commit *completes* #149, which would normally move it into Completed Steps. I followed the repo's existing convention for in-flight work instead — the previous Next Step was phrased as "Land feat/issue-144-settings-about", so Next Step is now "Land #149 ... PR open, awaiting review", which is accurate until this merges. Whoever merges should move it to Completed Steps and promote the first Future Step. Happy to change it if the reviewer prefers the strict reading. ## Out of scope `script/lint` being `prettier --check` only and unable to catch undefined identifiers (#152) — noted in the TODO but not fixed here; I greped for `DEBUG` consumers by hand rather than relying on lint, as advised. Nothing else in the DEBUG consumer set (`log.js`, `helpers.js`, `state.js`, `settings.js`) changed behavior. Co-authored-by: sneak <sneak@sneak.berlin> Reviewed-on: #169 Co-authored-by: clawbot <clawbot@noreply.example.org> Co-committed-by: clawbot <clawbot@noreply.example.org> |
||
|
|
d046a24115 |
scripts-to-rule-them-all (#148)
check / check (push) Successful in 5s
Reviewed-on: #148 Co-authored-by: sneak <sneak@sneak.berlin> Co-committed-by: sneak <sneak@sneak.berlin> |
||
|
|
e41efc969d |
Use make targets exclusively in Getting Started
check / check (push) Successful in 11s
Add make install target wrapping yarn install. The Makefile is the authoritative interface for all repo operations. |
||
|
|
065f0eaa81 |
Add project scaffolding
check / check (push) Successful in 10s
Makefile, Dockerfile, CI workflow, prettier config, manifests for Chrome (MV3) and Firefox (MV2), source directory structure, and minimal test suite. All checks pass. |