Tusk: a KeePass browser extension built on Vue and kdbxweb

Password autofill without a native helper

Tusk is a KeePass compatible browser extension for filling passwords. The defining technical choice is in the dependency list: the extension uses kdbxweb, the JavaScript implementation of the KDBX format, rather than talking to a native desktop client. The database is opened, decrypted and read inside the browser process.

The README frames that as a deliberate position rather than a limitation. The project describes itself as a modern, clean KeePass extension built with Vue.js and kdbxweb, and it says outright that the aim is better transparency and peace of mind, with the claim that it is better than proprietary black box applications that hide design flaws from the community. The implementation details section exists to support that: separate wiki pages cover the credential cache memory and how sensitive data such as KeePass databases and keyfiles are handled.

The practical consequence of a pure browser implementation is that everything has to happen in JavaScript. The package manifest reflects that. Besides kdbxweb 2.1.1 and Vue 3, there is argon2-browser for key derivation, pako for compression, webdav 5.8.0 for reaching a database on a WebDAV server, and webextension-polyfill so the same code can talk to both the Chrome and Firefox extension APIs. axios handles HTTP, base64-arraybuffer handles binary encoding, and the UI is Vue with Materialize CSS and Font Awesome.

Storage location is therefore part of the design, not an afterthought, and the wiki has a WebDAV Support page for exactly that.

Three Vite builds: background, content and web

The repository layout shows a modern browser extension structure. There are separate Vite configurations for the background script, vite.config.background.mts, for the content script, vite.config.content.mts, and for the web part, vite.config.mts. Alongside them sit a background/ directory, an extension/ directory that receives the built output, a services/ directory and a src/ directory for the UI.

The build is orchestrated by npm-run-all scripts in package.json. The production build runs a clean step and then the web, prepare, background and js builds in sequence, and there is a separate Firefox variant that sets a firefox target before running the same chain. A prepare script executes scripts/prepare.ts, which appears to be what produces the extension manifest, since the clean script removes extension/manifest.json alongside the distribution directory.

Packaging is a zip of the extension directory:

  "scripts": {
    "dev": "run-s clear && NODE_ENV=development run-p 'dev:*'",
    "build": "NODE_ENV=production run-s clear build:web build:prepare build:background build:js",
    "build:ff": "NODE_ENV=production TARGET=firefox run-s clear build:web build:prepare build:background build:js",
    "pack:zip": "rm -f extension.zip && zip -r extension.zip extension/*"
  },

The dev mode runs the clear step, then starts the prepare, web and background builds in parallel with a development environment, so a developer editing the Vue UI gets hot reload while the background script is rebuilt separately.

The package is marked as a private module of type module, and the repository pins [email protected] as its package manager with a .yarnrc.yml and a yarn.lock at the root.

Building the extension and running its tests in a browser

Building from source needs two things and little else. The README lists the requirements as node and yarn, and then gives the whole sequence:

# install dependencies
yarn install

# build for production with minification
yarn build
yarn pack:zip

# Hot reload
yarn dev

The output of yarn pack:zip is extension.zip, which is what you would load as an unpacked extension or upload to a store listing.

The test story is unusual and worth knowing before you plan any contribution. To run tests, you first build them with yarn build-tests or yarn watch-tests, then open tests/test.html in a browser. There is no headless runner in the documented workflow, which means the test suite runs in the same environment as the extension and someone has to open a page to see the result. The tests/ directory is present in the repository alongside src/, scripts/ and services/.

Two other commands exist for day to day work. The format script runs eslint with the fix flag across the TypeScript, JavaScript, Vue and HTML sources in src/, scripts/, services/ and background/, and the eslint configuration file sits at the root next to the .prettierrc.js formatting preferences. The project also carries a tsconfig.json for the TypeScript sources, even though the runtime is JavaScript, and an .editorconfig style setup in .vscode/.

Cross origin permissions are what autofill costs

The browser permissions section is the most candid part of the README, and any evaluator of a password manager should read it.

Tusk requires cross origin permissions in order to inject credentials and to query the storage backends on the user's behalf. In Chrome, those permission requests are always prompted to the user upon first use. In Firefox, the situation is different: because of the implementation of browser.permissions, it was necessary to request all permissions at install time to avoid code rot, and the README links an explanation on Stack Overflow about why the extension API may only be called from a user input.

That difference is a genuine trade-off between the two stores. Chrome gives you a per permission prompt at first use, which is better for trust but means the extension asks for access later. Firefox forces the request at install time, which is worse for trust but keeps the extension from decaying when an API call is no longer tied to a user gesture.

A password manager is in an unusual position here, because the permissions it needs are exactly the permissions a malicious extension would want. Injecting credentials means writing into other pages, and reaching a WebDAV server means making network requests to a host of your choosing. The README addresses this by pointing at the transparency documentation, but it does not offer a least privilege mode. The Custom Fields wiki page and the Warnings and Errors page are the places to look for the detail on what the extension will and will not do with a database.

A reboot of CKP with a two year gap in tagged releases

The history explains the odd version numbers and the release pattern. The README says the project was rebooted from perfectapi/CKP, and the FAQ answers the CKPX question directly: CKPX has been rebranded as Tusk to mark its Firefox release, because the C in CKPX stood for Chrome. The name itself is explained too, from an attempt at Elephant, as in an elephant never forgets, through to something shorter that kept the imagery.

The release history is the part to weigh. The three most recent tags are v2024.8.2 from 2024-08-03, v2018.9.27 from 2018 and v2018.9.23 from 2018, so the gap between the last tagged build and the previous ones is measured in years, and the versioning scheme follows the calendar year rather than the semver convention used by most packages. The README title for the 2024 release says the project is back from the dead, and asks readers to check the release notes for that tag.

The repository itself is not dormant. The last push was on 2026-10-20, and the working tree shows an active modern setup: Vite, TypeScript, Vue 3, webextension-polyfill and eslint. The package version field in package.json reads 2.0.0, which does not correspond to any tag in the list above.

On licensing, the project metadata classifies the licence as custom because GitHub cannot map it to a known category, and points to the LICENSE file, while package.json declares the licence as MIT. Anyone redistributing Tusk should read the LICENSE file rather than rely on either label, and this article does not interpret the terms. The browser distribution is also worth checking before use, since the README links a Firefox add-on listing and a Chrome Web Store listing that may hold versions built from commits newer than the last tag.

Tusk against the extension it replaced

There is a genuine alternative here, and the project itself points at it: the CKP and CKPX extension that Tusk was forked from. If that original extension works for your browser and your KeePass setup, the difference in approach is that you stay on the older code lineage rather than the Vue and kdbxweb rewrite.

The reason to prefer Tusk is specific. It is a from scratch rebuild with a modern toolchain, a typed source tree, a documented set of wiki pages about what it does with your credentials, and WebDAV support that lets the database live on a file server the extension can reach. The reason to prefer the older extension is the release record: Tusk's newest tagged build is from 2024-08-03, so a user who needs a recent fix from the upstream project has to check whether the extension stores are serving something newer than the tags suggest.

The other comparison is with the category rather than a specific product. A browser's built in password manager keeps credentials in the browser's own storage and syncs them through a vendor account, which removes the cross origin permission question entirely but moves trust to the browser vendor. Running a desktop password manager and copying credentials by hand removes the permissions question too, and removes autofill. Tusk occupies the middle: the familiar KeePass file stays the source of truth, the filling happens in the page, and the price is broad permissions and a dependency on JavaScript cryptography inside the browser.

Given that positioning, Tusk suits someone who wants to keep one KeePass database as the single source of truth across machines, tolerates granting a browser extension wide access, and reads the credential caching page before enabling the cached master password. It does not suit someone who wants the browser to be the place where secrets never leave.

Editorial conclusion

Tusk suits a KeePass user who wants autofill without installing a native messaging helper, who keeps the database in a browser reachable location such as WebDAV, and who reads the credential caching documentation before switching it on. It does not suit a user who needs the latest KeePass format features immediately, since the newest tagged build is v2024.8.2 from 2024-08-03, and it does not suit a Firefox user who refuses broad cross origin permissions at install time. Verify first by reading the wiki pages on Credential Cache Memory and Sensitive Data, then by loading a copy of your database and confirming which storage backends the extension can reach from your browser.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. subdavis/Tusk on GitHub