* Pinning version of AST instead of using latest * adding the pinned version of the commit * adding an array join * pinning version of dotnet * trying the AST pin of the version we started using * disabling jobs and adding test step to window job * adding dotnet 2.1.x to see if that fixes the issue * removing the test code and testing the addition of .net 2.1.x * repinning to last successful sign * trying the newest version of AST * disabling the non-windows jobs again * disabling the windows build job and added a test job * removing stray comma * changing the multiline delimiter * pivoting away from our EV cert and testing with a test one * switching back to the EV cert and adding a verbose flag * disabling some steps that are breaking * swithing back to the test cert * testing new format for the ast command * removing the node portions of the test since they are not needed * trying AST without the tenat-id * rolling back to original commit * switching to custom AST for better troubleshooting * removing the ast commit logic and forcing latest * fixing up the pwsh sign command * fixing the AST verison * making sure that the secrets are not blank * trying the EV cert for signing * Using pinned commit from AST instead of custom code * fixing env * building the actually pinned commit instead of whatever the other thing was... * testing the windows job * removing the dotnet 2.1.x dependency since the older AST version shouldn't need it * reenabling the test ast job since something is failing * moving the git switch command * testing new gh-action * fixing the gh-action path * updating the hash of the new action * enabling the build jobs again * updating the hash for the new Install AST action * fixing linter issues |
||
---|---|---|
.github | ||
.vscode | ||
jslib@da132217da | ||
patches | ||
resources | ||
scripts | ||
src | ||
stores | ||
.editorconfig | ||
.gitignore | ||
.gitmodules | ||
.nvmrc | ||
CONTRIBUTING.md | ||
crowdin.yml | ||
gulpfile.js | ||
LICENSE.txt | ||
package-lock.json | ||
package.json | ||
README.md | ||
SECURITY.md | ||
sign.js | ||
tsconfig.json | ||
tsconfig.renderer.json | ||
tslint.json | ||
webfonts.list | ||
webpack.main.js | ||
webpack.renderer.js |
Bitwarden Desktop Application
The Bitwarden desktop app is written using Electron and Angular. The application installs on Windows, macOS, and Linux distributions.
Build/Run
Requirements
- Node.js v14.17 or greater
- NPM v7
- Windows users: To compile the native node modules used in the app you will need the Visual C++ toolset, available through the standard Visual Studio installer. You will also need to install the Microsoft Build Tools 2015 and Windows 10 SDK 17134 as additional dependencies in the Visual Studio installer.
Run the app
npm install
npm run electron
Debug Native Messaging
Native Messaging (communication with the browser extension) works by having the browser start a lightweight proxy application baked into our desktop binary. To setup an environment which allows
for easy debugging you will need to build the application for distribution, i.e. npm run dist:<platform>
, start the dist version and enable desktop integration. This will write some manifests
to disk, Consult the native manifests documentation for more details of the manifest
format, and the exact locations for the different platforms. Note that disabling the desktop integration will delete the manifests, and the files will need to be updated again.
The generated manifests are pre-configured with the production ID for the browser extensions. In order to use them with the development builds, the browser extension ID of the development build
needs to be added to the allowed_extensions
section of the manifest. These IDs are generated by the browser, and can be found in the extension settings within the browser.
It will then be possible to run the desktop application as usual using npm run electron
and communicate with the browser.
Contribute
Code contributions are welcome! Please commit any pull requests against the master
branch. Learn more about how to contribute by reading the CONTRIBUTING.md
file.
Security audits and feedback are welcome. Please open an issue or email us privately if the report is sensitive in nature. You can read our security policy in the SECURITY.md
file.