- C# 83.8%
- TSQL 9.9%
- Handlebars 4.2%
- Rust 0.8%
- HTML 0.7%
- Other 0.4%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
77bb391404* Ensuring the creation date and update date are used correctly, and that editorName gets returns to clients side properly * Record the previous value and date in secret version snapshots SecretUpdateRequestModel.ToSecret mutates the entity in place and returns the same reference, so originalSecret aliased the already-updated secret and every version snapshot stored the new value rather than the previous one. Capture the value and revision date before ToSecret runs. VersionDate used the secret's CreationDate, which never changes, so every version for a secret shared one timestamp. That made OrderByDescending a total tie, leaving history order arbitrary, and let the retention prune in CreateAsync delete the newest versions instead of the oldest. Use the revision date of the value being archived. The restore path had the same problem using DateTime.UtcNow, which collided with the secret's new revision date, so it now keeps the date the archived value was set. Drop EditorName from the version response. Machine account names are encrypted with the organization key, which the server cannot read, so the field carried ciphertext for service-account editors and plaintext for user editors. Callers get EditorServiceAccountId and EditorOrganizationUserId instead and can resolve a display name from data they have already decrypted. This also removes the per-version editor lookups along with the IServiceAccountRepository and IUserRepository dependencies they needed. Add tests for the update and restore snapshots, the get-by-ids endpoint, and the ten-version retention cap, none of which were covered. * undoing changes to tests that shouldn't have been changed * Updates to code to allow for editor name to be shown on the secrets versioning UI, extracted logic into a command for adding and updating new Secret Versions. Adding and updating relevant tests * updating comment to be clearer * Update src/Core/SecretsManager/Models/Data/SecretVersionDetails.cs Co-authored-by: Rui Tomé <108268980+r-tome@users.noreply.github.com> * The API was returning raw ID numbers for the editor, which the UI can't display. I added a way to look up the actual names. Member names are stored as plain readable text, but machine-account names are encrypted and the server genuinely cannot read them. So these can't be one combined "name" field — the member name is sent as-is, and the machine-account name is sent still-encrypted for the browser to unscramble. Saving a secret and saving its version-history entry were two separate operations. If the first succeeded and the second failed, the secret was already permanently saved but the user got an error screen — so they'd try again and end up with two copies of the same secret. The fix is like a bank transfer: both steps now happen inside a single all-or-nothing operation. If the version entry fails, the secret save is undone too, so the user's retry is safe. * ensure the person reading editor names is allowed * auditing comments for correctness * Removing unused code and fixing tests * adding comments * fixing backfill issue where secrets without an initial secret version upon change doesn't retain version history * suggested improvements * Skip version pruning on the secret create path A secret created in the same transaction has no version history, so the retention query in AddWithPruningAsync always came back empty - one wasted round-trip per secret created. Extract the id-assignment and mapping step into SecretVersionWriter.AddAsync and have CreateAsync call that instead. AddWithPruningAsync keeps its pruning logic and delegates to AddAsync, as does TryBackfillPreviousVersionAsync, so the ValueGeneratedNever id rule stays defined in one place. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * updating the code to use the feature flag properly now that the PR adding the feature flag has been merged * fixing claude suggestions --------- Co-authored-by: Rui Tomé <108268980+r-tome@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
| .aspire | ||
| .claude | ||
| .config | ||
| .devcontainer | ||
| .git-hooks | ||
| .github | ||
| .run | ||
| .vscode | ||
| AppHost | ||
| bitwarden_license | ||
| dev | ||
| perf | ||
| src | ||
| test | ||
| util | ||
| .dockerignore | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| bitwarden-server.slnx | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| global.json | ||
| LICENSE.txt | ||
| LICENSE_AGPL.txt | ||
| LICENSE_BITWARDEN.txt | ||
| LICENSE_FAQ.md | ||
| README.md | ||
| SECURITY.md | ||
| TRADEMARK_GUIDELINES.md | ||
The Bitwarden Server project contains the APIs, database, and other core infrastructure items needed for the "backend" of all bitwarden client applications.
The server project is written in C# using .NET Core with ASP.NET Core. The database is written in T-SQL/SQL Server. The codebase can be developed, built, run, and deployed cross-platform on Windows, macOS, and Linux distributions.
Developer Documentation
Please refer to the Server Setup Guide in the Contributing Documentation for build instructions, recommended tooling, code style tips, and lots of other great information to get you started.
Deploy
You can deploy Bitwarden using Docker containers on Windows, macOS, and Linux distributions. Use the provided PowerShell and Bash scripts to get started quickly. Find all of the Bitwarden images on GitHub Container Registry.
Full documentation for deploying Bitwarden with Docker can be found in our help center at: https://help.bitwarden.com/article/install-on-premise/
Requirements
- Docker
- Docker Compose (already included with some Docker installations)
These dependencies are free to use.
Linux & macOS
curl -s -L -o bitwarden.sh \
"https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
&& chmod +x bitwarden.sh
./bitwarden.sh install
./bitwarden.sh start
Windows
Invoke-RestMethod -OutFile bitwarden.ps1 `
-Uri "https://func.bitwarden.com/api/dl/?app=self-host&platform=windows"
.\bitwarden.ps1 -install
.\bitwarden.ps1 -start
Production Container Images
View Current Production Image Hashes (click to expand)
US Production Cluster
| Service | Image Hash |
|---|---|
| Admin |  |
| API |  |
| Billing |  |
| Events |  |
| EventsProcessor |  |
| Identity |  |
| Notifications |  |
| SCIM |  |
| SSO |  |
EU Production Cluster
| Service | Image Hash |
|---|---|
| Admin |  |
| API |  |
| Billing |  |
| Events |  |
| EventsProcessor |  |
| Identity |  |
| Notifications |  |
| SCIM |  |
| SSO |  |
We're Hiring!
Interested in contributing in a big way? Consider joining our team! We're hiring for many positions. Please take a look at our Careers page to see what opportunities are currently open as well as what it's like to work at Bitwarden.
Contribute
Code contributions are welcome! Please commit any pull requests against the main branch. Learn more about how to contribute by reading the Contributing Guidelines. Check out the Contributing Documentation for how to get started with your first contribution.
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. We also run a program on HackerOne.
No grant of any rights in the trademarks, service marks, or logos of Bitwarden is made (except as may be necessary to comply with the notice requirements as applicable), and use of any Bitwarden trademarks must comply with Bitwarden Trademark Guidelines.
Dotnet-format
Consider installing our git pre-commit hook for automatic formatting.
git config --local core.hooksPath .git-hooks