Browserpass: filling a UNIX password store from the browser

Two components, because a web page cannot read your GPG key

Browserpass is split into a browser extension and a native messaging host, and the split is the design rather than an accident. A web page in your browser cannot open a GPG-encrypted file or prompt for a passphrase, and any extension that tried would need your key inside the browser, which is exactly the risk people run a password store to avoid. So the extension handles the page, and a separate program installed on the operating system handles the store, and the two talk over the browser's native messaging channel. The README states that the native messaging host is required, and points to its own repository for installation instructions. In practice this means installing two things, and a failure to understand that pairing is the most common source of confusion for new users.

Domain names in filenames are what stops the wrong credential being offered

The matching rule is simple enough to be predictable and strict enough to be protective. A password entry file, or any of its parent folders, must contain a full domain name including the top-level domain, and optionally a port, in order to be matched automatically to a website. That is the phishing protection the README describes: an entry named for a specific site will not be offered on a lookalike domain, because the name has to match. Entries that do not carry a domain in their name still work, but the user has to pick them by hand, which is a deliberate trade of convenience for safety rather than a bug. The store also has structural constraints, since file names may not contain backslash or forward slash characters, both of which are treated as path separators.

Four ways to install the extension, each with a different update story

The README lists distinct installation routes for Chromium-based and Firefox-based browsers, and the differences are about who updates the software and when. A package manager install, such as the Arch Linux packages browserpass-chromium, browserpass-chrome and browserpass-firefox or the Debian webext-browserpass package, keeps the extension and the native host in sync and provides auto-updates. Installing from the Chrome Web Store or Firefox Add-ons also provides auto-updates. Downloading browserpass-webstore.crx from a release gives you the same extension ID as the Web Store build, so it updates itself afterwards, while browserpass-github.crx has a different ID and never auto-updates, which the README recommends for distro packaging or for users who do not want to be forced onto a new version. Unpacked archives, browserpass-chromium.zip and browserpass-firefox.zip, are the manual option.

Release artifacts are PGP signed, and the README shows how to check them

Anyone downloading a CRX or an archive outside a web store is trusting a binary, so the project publishes signatures for its release files and documents the verification procedure. The public key is hosted at max.baz.nu and mirrored on OpenPGP key servers, and it can be pulled in with a curl piped to gpg, or fetched directly by key id.

$ curl https://max.baz.nu/pgp_keys.asc | gpg --import
$ gpg --recv-keys 56C3E775E72B0C8B1C0C1BD0B5DB77409B11B601

A given file is then checked with gpg --verify, and a good result names the signing key and its fingerprint.

$ gpg --verify <file>.asc

This matters more than usual for a credential tool, since an attacker who substitutes a modified extension gets a component that can read whatever the native host is willing to hand over. The README also flags that most improvements require changing code in both the extension and the host application, so keeping the two on matching releases is a real operational task rather than a formality.

The build is driven by a Makefile that assembles per-browser bundles

The repository builds with make, and the Makefile at the root is a good map of the project structure. It reads the version from a .version file, and the default all target runs three steps: extension, chromium and firefox. The extension target recurses into src, and the two browser targets copy the shared source files into chromium/ and firefox/ directories, substituting a different manifest for each, src/manifest-chromium.json and src/manifest-firefox.json. The distribution bundles are prebuilt files such as src/js/popup.dist.js and src/js/background.dist.js, and the build has separate popup, offscreen, options and inject bundles, including an early-inject one.

.PHONY: chromium
chromium: extension $(CHROMIUM_FILES) chromium/manifest.json

The official release targets run Chrome's own pack-extension command, one variant using webstore.pem to produce the build that matches the Web Store extension ID and another producing the github build with a different ID. The repository root is small, with src/, images/, a PRIVACY.md, a Makefile and a .version file, and the extension is written in JavaScript.

Where a hosted password manager differs in approach

The realistic alternative is a browser's built-in vault or a hosted password manager with its own extension, and the difference in approach is where the encrypted database lives. A hosted manager keeps a synchronized, encrypted blob on a vendor's servers, decrypts it in the extension, and matches credentials against the site's domain. Browserpass keeps no copy: the encrypted store stays in a file on your disk, the native host reads it, and the extension never holds the key material for more than the entry being filled. The trade-off runs the other way as well. A hosted manager syncs across devices and handles encrypted sharing between users, which a per-machine GPG-encrypted store does not do on its own, and it provides a recovery path when a passphrase is lost. Browserpass depends on gpg being installed and on the user managing a passphrase, which the README lists among the requirements.

ISC licensed, actively changed, and versioned in the open

The extension carries an ISC licence, a permissive licence close to MIT, so embedding or redistributing the code in a product carries little friction. The release history shows 3.12.0 tagged on 2026-05-31, 3.11.0 on 2025-07-25 and 3.10.2 on 2025-04-06, and the last push to the repository was on 2026-10-17, which is later than the most recent tagged release and indicates work is landing in the tree between releases. The gap between 3.11.0 and 3.12.0 is about ten months, and the gap before that is under four, so the release cadence is irregular rather than fixed. The README also documents an FAQ covering the error about being unable to fetch and parse login fields, how to reuse one credential across several domains, and why the extension does not work on Mozilla domains in Firefox, which is a separate restriction from the ordinary match rule.

Editorial conclusion

Browserpass is a good fit if your credentials already live in a pass or gopass store and you want domain-scoped autofill without moving them into a browser vault. It does not fit teams that rely on a hosted password manager, on browsers without extension support, or on machines where you cannot install the native messaging host alongside a GPG key. Verify first that every store entry you expect to auto-fill has a full domain including the top-level domain in its name, since the README states that entries without one must be selected manually, and confirm the native host and the extension are on the same release before you expect new features to work.

Frequently asked questions

Official sources

1. browserpass/browserpass-extension on GitHub
2. Issues
3. License: ISC
4. README
5. Releases