alexion
e42101e08b
The base Stylix Firefox target themes only fonts and the reader view, leaving the toolbar and tabs at Firefox's default look. Enable colorTheme so Stylix recolours the chrome Nord from the shared scheme through its managed Firefox Color add-on, with no hand-written chrome CSS and no flake input of ours. Scope ADR 0005's no-pinned-add-on rule to the three functional extensions and record the signed, Stylix-managed theming add-on as a deliberate exception.
3.4 KiB
status
| status |
|---|
| accepted |
Stock Firefox with policy-installed extensions
The browser Module ships stock mainline Firefox (pkgs.firefox, the release train), and installs its three extensions — an ad and content blocker, the operator's password manager, and a video sponsor-skipper — through Mozilla's enterprise ExtensionSettings policy, keyed by add-on id with an install URL and installation_mode = "force_installed".
Firefox fetches each signed add-on from Mozilla's add-on site at runtime and enables it automatically.
We chose this over an ESR, unbranded, or Developer Edition build carrying hash-pinned add-on packages from the Nix store. Stock mainline Firefox refuses to load unsigned locally-built add-ons, so the pinned-package path forces the browser variant: it works only on a build that relaxes signature enforcement, which the mainline release does not. Pairing the variant to the extension mechanism makes this the pivotal, hard-to-reverse decision — the choice of build dictates the whole extension story — so it is recorded here rather than left implicit in the Module.
The trade-off is deliberate. The policy path gives up build-time reproducibility of the extension binaries, and needs network on first launch to populate them, in exchange for staying on current mainline Firefox with add-ons that are actually enabled and no new flake input.
Considered Options
- Stock mainline Firefox with policy-installed extensions (chosen). Current release train, no signature-enforcement caveat, no extra flake input. The extension binaries are fetched signed at runtime rather than pinned, so their exact versions are not reproducible from the flake and first launch needs network.
- ESR or unbranded Firefox with hash-pinned add-on packages (e.g. via a NUR add-ons input). Rejected: it buys reproducible extension binaries but drags in an older or unusual browser variant to satisfy the signature check the mainline build enforces, plus a new flake input to maintain, for a browser the operator wants on the mainline feature and security cadence.
- Stock Firefox with extensions installed by hand. Rejected: the state would live outside the flake, would not survive a reimage, and defeats the point of declaring the browser at all.
Consequences
- The Module needs no new flake input and no add-on package set. The extension list is three id/URL pairs under the enterprise policy.
- Extension versions are whatever Mozilla currently serves, not a pinned hash, so the browser tracks upstream add-on updates automatically and the flake does not gate them.
- First launch after a fresh build requires network to fetch the add-ons. An offline first boot comes up with the extensions not yet present, populating them once online.
- Moving to a pinned-package posture later would mean changing the browser variant as well, since the two are coupled — the reason this is captured as a decision rather than a detail.
- The no-pinned-package rule scopes to the three functional extensions, which is where the signature-enforcement conflict bites. Nord chrome theming comes from the Stylix Firefox Color add-on, a signed add-on that Stylix pins and manages, so it loads on stock mainline Firefox and adds no flake input of ours. That is a bounded, deliberate exception, not a reversal: it is what lets the browser be themed from the shared Stylix scheme without hand-written chrome CSS.