Kee is a free Firefox and Chrome add-on for linking browsers to Kee Vault or KeePass (latter requires using the KeePassRPC KeePass plugin).
Official website with sign-up and download links: https://www.kee.pm
Support forum: https://forum.kee.pm
- node (16 should work but only tested with 18)
- a node package manager (tested with npm 8 and 9)
- a web browser (tested with Firefox 117)
- a Supporter's subscription to Kee Vault OR KeePass 2.x (+ .NET/Mono) + KeePassRPC.plgx
It's set up for Visual Studio Code but it shouldn't be too hard to work out how to develop using other IDEs.
- clone the repo
npm ci(ornpm installto get any newer library dependencies than those we used in official builds)- Development:
- Open two terminals/consoles
- In the 1st:
npm run devORnpm run dev-chrome - In the 2nd:
npm run start:firefoxORnpm run start:chrome
- In the 1st:
- the task in the 1st terminal will recompile and reload necessary parts of the addon each time you change a file but in some circumstances you'll need to press 'r' in the 2nd terminal to force a complete reload.
- If you mismatch the Firefox/Chrome commands most parts of the development process should be unaffected but you'll see some console warnings so try to keep them aligned when switching between browsers.
- Open two terminals/consoles
- Preparing for release or Pull Request:
npm run tscto verify that no type errors have been introduced during recent development changesnpm run lint
You may need to modify the vite config files or some of the build scripts if you add significant new sections to the WebExtension structure but it's unlikely and we can help you with that if necessary.
Exactly reproducing the files delivered from the Firefox add-on website or Chrome extension store is not possible because the websites modify the file that we build in order to attach a digital signature. One can get very close though, to the point where a diff of the files from a given release on GitHub varies from your own local build in only three ways:
- Line endings - some parts of the tool chain may treat line endings differently so that the end result could differ between operating systems.
- Version number - the CI build system holds credentials that allow it to manipulate git tags on the GitHub repository and in doing so allows for automatic incrementing of build numbers, which in turn will result in a unique version number being calculated. This can only be reproduced if you download the git repo to your local system (including all tags) and develop a custom build script or modify the source files as needed - it's most likely not worth the effort but can be done if it is important to you.
- File dates - the build output is essentially a zip file so when the newly downloaded and built files on your system are added to the zip file, they will have different dates than those that were built on the CI platform and automatically added to a GitHub Release. For this reason, even if you were to end up with the same line endings and version number, it is not possible to compare a digest (hash) of your built file and expect it to match the file built by anyone else (unless you build it at exactly the same time!)
Reproducible builds rely upon npm version 7 or higher.
Our builds are created by GitHub Actions using the following configuration:
- Ubuntu 22.04
- Node 18
- npm 8
- download the source code (e.g. from the relevant GitHub Release page) or clone the repo for the latest (often pre-release) version
npm ci && mkdir dist- manipulate package.json if you want to adjust version numbers
- For a Firefox release:
npm run build:prod && npm run pack:prod(for stable releases) and/ornpm run build:beta && npm run pack:beta(for beta releases) - For a Chromium release:
npm run build-chrome:prod && npm run pack-chrome:prod(for stable releases) and/ornpm run build-chrome:beta && npm run pack-chrome:beta(for beta releases) - XPIs and ZIPs of each variant are put into the
distfolder
/_localesLocalisation data (language translations)..txUsed by Transifex localisation scripts to help manage multiple language translation.distOutput folder for build packages (e.g. an XPI file for installation in Firefox). Created automatically by development scripts or manually if you're only building for packaging/release.extensionOutput folder for compiled files when developing or building for packaging/release.libFiles that are directly included in the resulting extension, undergoing no further adjustment or compilation.scriptsThe scripts within help prepare theextensionfile structure for hot module reloading during development, as well as ensuring that various categories of files end up in the right place, with appropriate references updated.srcmanifest.tsOutputs a manifest.json file appropriate to the current build / development environment.assetsStatic assets. These may be manipulated by the build process into a different format or excluded entirely from the final output but typically will just be included as is, into the extension/assets folder.backgroundExtension's main background script / Service Worker.commonModules that are used across multiple extension scopes (e.g. background, popup, content script, etc.)dialogsStandalone dialogs within the extension context (e.g. for the Network Authentication window).install-notesA Vue app that is shown after an extension installation has occurred.pageThe content page script that gets injected to every web page that is not Kee Vault.panelsSmall pages that are rendered as in-page panels, within an iframe, within any web page.popupThe main browser popup that clicking on the browser toolbar button will display.release-notesPages that are shown after an extension update has occurred.settingsPage to allow user to adjust many extension settings.storeThe Pinia Store definitions that are used for both Vue/Vuetify UI state storage and for automated data transfer across multiple extension execution scopes (popup, settings page, background, in-page panels, etc.)vaultThe content page script that gets injected to the Kee Vault website.
It's likely that the below does not work. It might though, at least on one or two devices in the world when the stars are aligned.
We'll take a fresh look at this challenge when working on the migration to MV3.
npm install -g @vue/devtools
npm install -g https-proxy-cli
https-proxy -t http://localhost:8098 -p 8099 --keys <folder to store and re-access self-signed certs> &
vue-devtools
sudo apt-get install libnss3-tools
Manually load https://localhost:8099 in the browser, add self-signed cert to whitelist and export the cert to a local file (or just use the generated keys folder location above... not sure if that will work or not).
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n <path to saved cert> -i <path to saved cert>
restart Chrome