Add two new options to customize how extension permissions are checked:
- `extensions.exhaustivePermissions`
Ensures that the permissions requested by all extensions managed by
home-manager are authorized
- `extensions.exactPermissions`
When enabled, the user must authorize only the permissions that the
extensions requests, not more nor less.
Tested with rebased
https://github.com/nix-community/home-manager/pull/6411 so I could find
all instances of config usage in docs.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Co-authored-by: Robert Helgesson <robert@rycee.net>
Adds extension permissions as suggested in
https://github.com/nix-community/home-manager/issues/7001.
Adds the 'profiles.<name>.extensions.settings.<name>.permissions' to Firefox
derivatives. If set, this option adds an assertion that fails if an extension
package requests permissions that weren't added to the permissions option. In
order to not require 'profiles.<name>.extensions.force' to be set when only
permissions, but no extension settings were defined, the relevant assertions
were changed. They now check whether any 'extensions.settings.<name>.settings'
was set instead of checking whether 'extensions.settings' was set.
---------
Co-authored-by: Robert Helgesson <robert@rycee.net>
Co-authored-by: awwpotato <awwpotato@voidq.com>
This resolves issue that someone might try and configure bookmarks and a
policy will prevent it from applying properly.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Add an example of using extension settings to control installation and
accesibility of a extension in the policies option.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Creates the user.js if profile.extensions.settings is set.
This fixes the case when profile.extensions.settings is set but every
other option in the mkIf is false, resulting in no user.js creation.
Reduce maintenance burden and increase efficiency by automatically
importing modules following a specific convention.
Co-authored-by: awwpotato <awwpotato@voidq.com>
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
This allows `programs.firefox.profiles.*.userChrome` to be set to a:
derivation, path/path-like string to directory or file, or multiline
text to be used as content verbatim.
This allows setting, for example(s):
```nix
programs.firefox.profiles."jacob.default".userChrome = pkgs.wavefox;
programs.firefox.profiles."jacob.default".userChrome =
"${pkgs.wavefox}/userChrome.css";
```
The legacy attrset option type for `firefox.profiles.<name>.bookmarks`
was accidentally removed in 9d55428. This adds back support for this
type by refactoring the bookmarks submodule. This also adds a new test
ensuring this won't happen again.
This splits the bookmarks submodule into a seperate file, to make it easier to maintain (like how the search module was previously split out in #5697).
This also refactors bookmarks to require a new force option, to be more explicit about overriding existing bookmarks.
A path may be preferred for some uses, and allowing it avoids the user
needing to `builtins.readFile`, thus creating duplicates and making it
more difficult to determine the actual store path.
The or operator is left associative, and since there is another
argument after the first term, the interpreter tries to apply whatever
the or-expression evaluates to. If the first operand is unset, it
evaluates to removeAttrs, and everything is fine, but if it is set to
a boolean (which is what it should be set to), then it tries to apply
a boolean to arguments, and we get a type error. Bracketing
explicitly with parentheses fixes this.
It presumably went unnoticed because not many people have tried
setting the option
`programs.firefox.profiles.<profile>.search.engines.<engine>.isAppProvided`.
Native messaging hosts module assumed all hosts are packages, and we
were passing null before.
The patch also adds a test case for a null firefox package to avoid
regressions in the future for this common (on Darwin at least) scenario.
Note: Thunderbird doesn't need a similar change because it doesn't allow
a null package.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
On Linux, both Thunderbird and Firefox use the same directory to contain
native messaging host modules. On this platform, we have to merge both
directories with native hosts into one.
The patch introduces a separate helper module to manage native host
directory generation. Now program modules (firefox, thunderbird) declare
native hosts to initialize; while the new helper module determines
*where* and *how* to merge them on disc.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
Prevents extensions settings from accidentally being overriden when
using `profiles.<name>.extensions.settings`. Adds the
`profiles.<name>.extensions.force` option to acknowledge the risk.
This commit refactors programs.firefox.profiles.<name>.extensions in
order to support both installation of extensions (addons) and their
configuration. It does this by setting the
`extensions.webextensions.ExtensionStorageIDB.enabled` user_pref to
false.
When this preference is set to false, support for storing extension
settings in sqlite databases, also known as IndexedDB or IDB, is
reverted back to the JSON format present in firefox versions prior to
version 63, as seen here:
https://blog.mozilla.org/addons/2018/08/03/new-backend-for-storage-local-api/
IndexedDB was made the default due to performance improvements, but had
the consequence of removing any possibility of declarative extension
configuration without the assistance of firefox's policy system. The
policy system is supported by a small amount of extensions, such as
uBlock Origin, but has to be explicitly supported. Even when supported,
it provides significantly less granular control when compared to the
JSON storage format.
Within the context of the profiles submodule, `${name}` refers to the
profile name, and not the Firefox fork name.
This fixes all descriptions to use the right name. This fixes a
previous commit that introduced a dependency between the documentation
and the user's configuration.
* firefox: fix referencing firefox fork name in profile-specific docs
Within the context of the profiles submodule, `${name}` refers to the
profile name, and not the firefox fork name.
This fixes all descriptions to use `${cfg.name}` instead.
* firefox: prefer cfg.name instead of name for consistency
Add `preConfig`, which acts like `extraConfig`, but placed before
`settings`. This will allow to overwrite settings in `preConfig`,
using `settings` option.
When `cfg.package` is already wrapped, and wrapped without the
`ExtensionSettings` key set, this would always add that key, even if its
value was blank. This would result in `cfg.finalPackage` being a
functionally-identical, but differently-input-addressed package. This is
generally undesirable as it may result in multiple derivations being
built, and also if the value of `cfg.package` is expected to be
unchanged by the user (e.g. because they want it to be consistent
between NixOS and HM configuration).
Add a test to ensure this does not regress in the default case. Only
test on newish stateVersion since the logic for `isWrapped` differs on
older versions.
Using a fixed application name in the salt for the search engine name
hash can break with minor branding changes. For example, LibreWolf 127
used the application name "LibreWolf", but in version 128 it is
"Firefox".
The proper name can be found in about:support -> Application Basics.
Because it doesn't have to be related to the product name visible in
most of the browser (for example in the window title and help menus),
we shouldn't rely on cfg.name for that.
The application name can be read from lib/*/application.ini and we can
use that if the browser was installed via Home Manager. If not, we can
fall back to cfg.name.
