Merge branch 'master' into autofill/update-autofill-deep-dive-documen…

…tation

.github/workflows/build.yml

@@ -18,10 +18,10 @@ jobs:
     runs-on: ubuntu-22.04
     steps:
       - name: Checkout repo
-        uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
 
       - name: Set up Node
-        uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3.8.1
+        uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65 # v4.0.0
         with:
           cache: "npm"
           cache-dependency-path: "**/package-lock.json"

.github/workflows/lint.yml

@@ -18,10 +18,10 @@ jobs:
     runs-on: ubuntu-22.04
     steps:
       - name: Checkout repo
-        uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 # v4.1.0
+        uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
 
       - name: Set up Node
-        uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3.8.1
+        uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65 # v4.0.0
         with:
           cache: "npm"
           cache-dependency-path: "**/package-lock.json"

.nvmrc

@@ -0,0 +1 @@
+v18

docs/architecture/adr/0019-adopt-web-push.md

@@ -44,10 +44,9 @@ problems with long-lived background connections.
 New solutions must be able to not only scale to essentially infinite connections but balance cost
 with user growth, all the while delivering high availability. Existing options for mobile
 notifications specifically either have device limits (e.g. [Azure Notification Hubs][hubspricing])
-or lack service level guarantees while not offering modern technologies. Furthermore, some clients
-(e.g. [F-Droid][fdroid]) cannot utilize well-established (albeit proprietary) push backends. A
-single service provider is desired for as much functionality as possible, while still offering
-flexibility for self-host.
+or lack service level guarantees. Furthermore, some clients (e.g. [F-Droid][fdroid]) cannot utilize
+well-established (albeit proprietary) push backends. A single service provider is desired for as
+much functionality as possible, while still offering flexibility for self-host.
 
 ## Considered Options
 
@@ -58,56 +57,63 @@ With respect to mobile notifications:
   solution that shards devices across many Notification Hubs within new subscriptions.
 - **Adopt a new offering for mobile push notifications** - Use something other than Azure
   Notification Hubs that doesn't have limits, perhaps with some technology sacrifices.
-- **Adopt a new combined push service provider** - Not only migrate away from Azure Notification
-  Hubs but also select a service provider that supports native mobile notifications as well as other
-  desired protocols like Web Push.
 
 With respect to protocol modernization:
 
 - **Keep the SignalR solution and continue to scale up** - Maintain the cluster of notifications
   service virtual machines and keep pushing for a larger set to handle scale. Also move all mobile
   notifications to the custom solution and abandon Azure Notification Hubs.
-- **Adopt a new offering for non-mobile push notifications** - Use something other than SignalR like
-  a homegrown [Web Push][webpush] backend inside the notifications service. Host a compatible Web
-  Push backend for self-host with the clients that need it.
+- **Utilize a new approach for non-mobile push notifications** - Use something other than SignalR
+  like a homegrown [Web Push][webpush] backend inside the notifications service. Host a compatible
+  Web Push backend for self-host with the clients that need it. Use Web Push with Azure Notification
+  Hubs for the Bitwarden cloud.
 - **Adopt a new combined push service provider** - Not only migrate away from SignalR where possible
-  but also select a service provider that supports native mobile notification protocols.
-  Additionally implement a Web Push backend for self-host as described above.
+  but also select a different service provider than Azure Notification Hubs that supports native
+  mobile notification protocols. Additionally implement a Web Push backend for self-host as
+  described above.
 
 ## Decision Outcome
 
-Chosen option: **Adopt a new combined push service provider**.
+Chosen options: **Work around Azure Notification Hubs limits** and **utilize a new approach for
+non-mobile push notifications**.
+
+During research and planning of the decision, Azure Notification Hubs unveiled support for the Web
+Push protocol, therefore significantly adjusting the outcome. By continuing to use Azure
+Notification Hubs a significant technology investment can continue to be leveraged, users will not
+need to be migrated, and the focus can instead be on scale and support for new device types that can
+benefit from Web Push.
 
 ### Positive Consequences
 
 - Web Push is [well-supported][caniuse] in most places we need it and is a valuable technology
   upgrade with ease of maintenance in the future.
-- Several service providers offer Web Push backends for our cloud offering, and the protocol can be
-  implemented within the notifications service for self-host.
+- Several service providers -- including Azure Notification Hubs -- offer Web Push backends for our
+  cloud offering, and the protocol can be implemented within the notifications service for
+  self-host.
 - Web Push fits well into Manifest V3 and service workers.
 - Infrastructure maintenance burdens and cost for the notification service should significantly
   decrease.
 
 ### Negative Consequences
 
-- Need to watch Safari support for Web Push which was just recently released at time of writing.
-- Potential cost increases for selecting a different service provider.
+- Need to watch Safari support for Web Push which was somewhat recently released at time of writing.
+- Potential cost increases for utilizing multiple Azure Notification Hubs.
 
 ### Plan
 
 The notifications service will continue to exist and support APIs for the SignalR connections as
-well as new ones for Web Push. Cloud-based clients will connect to a unified service provider that
-has Web Push whenever feasible and otherwise utilize the existing SignalR implementation when Web
-Push cannot be leveraged. Self-host clients will utilize a similar blend of Web Push and SignalR
-provided by the notification service. Web Push's necessary key exchange and security (VAPID) can use
-existing in-house technology for self-host and the service provider for the cloud. Clients will
-largely migrate to Web Push connections over time and the load on SignalR will significantly reduce,
-although the latter is planned to be supported for certain clients for the foreseeable future.
-
-Mobile devices will all migrate to the same unified service provider that supports native iOS (APNS)
-and Android (FCM) push notification protocols alongside Web Push. Future support for [Unified
-Push][unifiedpush] will be considered alongside Web Push for incompatible clients, although the
-SignalR implementation continues to be available.
+well as new ones for Web Push. Clients will connect using Web Push whenever feasible and otherwise
+utilize the existing SignalR implementation when Web Push cannot be leveraged. Self-host clients
+will utilize a similar blend of Web Push and SignalR provided by the notification service. Web
+Push's necessary key exchange and security (VAPID) can use existing in-house technology for
+self-host and the service provider for the cloud. Clients will largely migrate to Web Push
+connections over time and the load on SignalR will significantly reduce, although the latter is
+planned to be supported for certain clients for the foreseeable future.
+
+Mobile devices will continue to use Azure Notification Hubs with native iOS (APNS) and Android (FCM)
+push notification protocols alongside Web Push. Future support for [Unified Push][unifiedpush] will
+be considered alongside Web Push for incompatible clients, although the SignalR implementation
+continues to be available.
 
 Utilizing end-to-end encryption -- with user encryptions keys -- of push notification payloads will
 be considered while migrating compatible clients to the new provider to provide stronger security of

docs/architecture/mobile-clients/watchOS.md

@@ -1,6 +1,6 @@
 # watchOS
 
-## Overall Architecture
+## Overall architecture
 
 The watchOS application is organized as follows:
 
@@ -72,7 +72,7 @@ the watchOS one) and run it on the device.
 
 :::
 
-## Synchronization iPhone <-> Watch
+## Synchronization between iPhone and Watch
 
 In order to sync data between the iPhone and the Watch apps the
 [Watch Connectivity Framework](https://developer.apple.com/documentation/watchconnectivity) is used.
@@ -151,7 +151,7 @@ The next ones are the states in which the Watch application can be at a given ti
 - **Need Device Owner Auth:** The user needs to set up an Apple Watch Passcode in order to use the
   app
 
-## Persistence and Encryption
+## Persistence and encryption
 
 On the Watch [CoreData](https://developer.apple.com/documentation/coredata) is used as persistence
 for the ciphers. So in order to encrypt the data in them a Value Transformer in each encrypted

docs/contributing/code-style/sql.md

@@ -57,7 +57,7 @@ GO
 ```
 
 When adding a new `NOT NULL` column to an existing table, please re-evaluate the need for it to
-truly be required. Do not be afraid of using Nullable<T\> primitives in C# and in the application
+truly be required. Do not be afraid of using Nullable\<T\> primitives in C# and in the application
 layer, which is almost always going to be better than taking up unnecessary space in the DB per row
 with a default value, especially for new functionality or features where it will take a very long
 time to be useful for most row-level data, if at all.

docs/contributing/dependencies/index.md

@@ -0,0 +1,141 @@
+---
+sidebar_custom_props:
+  access: bitwarden
+---
+
+# Dependency Management
+
+Bitwarden uses [Renovate](https://www.mend.io/renovate/) for automating dependency updates. Renovate
+will automatically create pull requests for dependencies on a weekly cadence. Security updates will
+generate pull requests immediately.
+
+## Ownership
+
+Bitwarden's repositories fall under two categories: team-owned and shared.
+
+### Team-owned repositories
+
+Team-owned repositories are "owned" by a single team from a dependency standpoint. The assigned team
+is responsible for reviewing, approving, and merging dependency updates. Some reasons a repository
+might be team-owned are that it's primarily developed by that team, or to balance out the number of
+dependencies teams have to manage.
+
+Some examples of team-owned repositories are [`directory-connector`][dc], which is owned by the
+_Admin Console_ team, and [`key-connector`][kc], which is owned by the Auth team.
+
+### Shared repositories
+
+Shared repositories don't have any direct owner. Instead each dependency is allocated to a team. The
+team assigned to a dependency is responsible for reviewing, approving, and merging that dependency.
+For major upgrades the team is responsible for coordinating the upgrade with the other teams.
+
+Examples of shared repositories are [`server`][server] and [`clients`][clients].
+
+## Example PR
+
+<figure>
+
+![Screenshot of a  Renovate PR](./renovate-pr.png)
+
+<figcaption>Example Renovate PR</figcaption>
+
+</figure>
+
+Renovate PRs contain several areas of interest. The above example PR contains two grouped
+dependencies. The PR proposes to upgrade the dependencies from `6.0.21` to `7.0.12`. The age of the
+version is **13 days**, and **13%** of repositories have adopted this version. Renovate has seen a
+**74%** test success rate across Renovate-managed repositories and has a low confidence in the
+change. For more details read
+[Renovate documentation about Merge Confidence](https://docs.renovatebot.com/merge-confidence/).
+
+## Workflow
+
+Renovate will automatically create pull requests during the weekend, which naturally aligns with
+each team allocating some time during the following Monday to work through their respective queue of
+pull requests. The teams should work together to resolve outstanding pull requests within the week
+to avoid stagnation.
+
+:::info
+
+The main exception being major upgrades that can sometimes take a longer amount of time to
+coordinate. Ideally the team will have already coordinated and resolved deprecations in advance.
+
+:::
+
+A Renovate PR may contain a single dependency or a group of related dependencies. At Bitwarden, we
+typically group dependencies we know are related and should be upgraded at the same time. We try to
+keep groups as small as possible to minimize the impact and increase confidence in approving and
+merging.
+
+### Review
+
+A typical dependency workflow involves the following steps:
+
+1. Read the proposed changes.
+2. Review the release notes of each dependency, for each released version between the current and
+   the proposed upgrade. Identify if there are any deprecations or breaking changes affecting our
+   code.
+   1. For breaking changes, either resolve them yourself, or for major changes, coordinate with the
+      other teams.
+   2. For deprecations, create high priority Jira tickets on the affected teams' backlogs with a due
+      date at least one sprint before the next scheduled major release of the dependency.
+3. Verify CI status.
+4. If test coverage is lacking, check out locally and manually confirm a few key areas.
+5. Review the proposed code changes and approve the PR.
+6. Write a Jira ticket containing testing notes for QA.
+7. Merge the PR. Assign the Jira ticket to QA.
+
+If you need to change the code to resolve any issues, please tag a team member for the final review.
+
+### Jira ticket
+
+The handoff between developers and QA will be a Jira ticket. The ticket should contain the affected
+dependency, any relevant release notes for sections to test, and some testing notes on affected
+areas.
+
+### QA testing
+
+While developers are responsible for writing a Jira ticket with testing notes, the QA engineer
+should practice due diligence by also considering the impact of the dependency change and if needed
+discuss with the engineer about potentially increasing or decreasing the scope of testing.
+
+### Reverting
+
+In the event QA finds a regression, the developer is responsible for assessing the impact and either
+immediately revert the update or resolve the regression in a new PR.
+
+### Closing irrelevant PRs
+
+Sometimes Renovate will create PRs for dependencies that we are currently unable to upgrade for
+various reasons. For example, `contributing-docs` depends on `docusaurus`, which supports specific
+versions of `react`. We cannot upgrade `react` until `docusaurus` supports it.
+
+In those cases the team can comment on the PR with a reason for not upgrading and close the PR.
+
+## Renovate configuration
+
+Renovate is configured by a `.github/renovate.json` file in each repository. We follow an internal
+template for consistency. The template is available at the
+[template repository](https://github.com/bitwarden/template/blob/main/.github/renovate.json).
+
+Renovate uses a concept called
+[`PackageRules`](https://docs.renovatebot.com/configuration-options/#packagerules) that allows us to
+specify ownership of dependencies and ensure the appropriate team is added as reviewers. Below is an
+example assigning `@angular/core` to the Platform team.
+
+```json
+{
+  "matchPackageNames": ["@angular/core"],
+  "description": "Platform owned dependencies",
+  "commitMessagePrefix": "[deps] Platform:",
+  "reviewers": ["team:team-platform-dev"]
+}
+```
+
+For repositories maintained by a single team there is no need to use `packageRules` to assign
+ownership. Instead ensure appropriate code owners are set up.
+
+[dc]: https://github.com/bitwarden/directory-connector
+[kc]: https://github.com/bitwarden/key-connector/
+[server]: https://github.com/bitwarden/server/
+[clients]: https://github.com/bitwarden/clients/

docs/contributing/index.md

@@ -97,7 +97,7 @@ While researching, we'd like to ask you to refrain from:
 
 If you have something that you feel is close to exploitation, or if you'd like some information
 regarding the internal API, or generally have any questions regarding the app that would help in
-your efforts, please contact us at <https://bitwarden.com/contact> and ask for that information. As
+your efforts, please [contact us](https://bitwarden.com/contact) and ask for that information. As
 stated above, Bitwarden wants to help you find issues, and is more than willing to help.
 
 Thank you for helping keep Bitwarden and our users safe!

docs/getting-started/clients/mobile/android/index.md

@@ -5,13 +5,12 @@
 Before you start, you should have the recommended [Tools and Libraries](../../../tools/index.md)
 installed. You will also need to install:
 
-1.  Visual Studio 2019 (required for a dependency not included yet in VS 2022; development can be
-    done in VS 2022)
-2.  [dotnet Core 3.1 (latest)](https://dotnet.microsoft.com/en-us/download/dotnet/3.1)
+1.  Visual Studio 2022
+2.  [.NET 7 (latest)](https://dotnet.microsoft.com/en-us/download/dotnet/7.0)
     - Note: Even if you have an M1 Mac with ARM 64 architecture, you can install all x64 SDKs to run
       android
 3.  [Xamarin (Android)](https://learn.microsoft.com/en-us/xamarin/get-started/installation/?pivots=macos-vs2022)
-4.  Android SDK 29
+4.  Android SDK 33
     - You can use the SDK manager in [Xamarin, Visual Studio][xamarin-vs], or [Android
       Studio][android-studio] to install this
 

docs/getting-started/clients/mobile/ios/index.mdx

@@ -10,18 +10,17 @@ import TabItem from "@theme/TabItem";
 
 ## Requirements
 
-- dotnet Core 2.0 (latest)
-- dotnet Core 3.1 (latest)
+- [.NET 7 (latest)](https://dotnet.microsoft.com/en-us/download/dotnet/7.0)
 - Xamarin (iOS)
-- A Mac with Xcode installed
+- A Mac with Xcode 15 installed
 
 ## Apple Developer Account Setup
 
 1. Accept your invite to the Bitwarden Apple Developer team. You should get a request in your email
    with the subject "You're invited to join a development team." Click the link, "Accept Invitation"
-   and you'll be prompted to create an Apple ID for your <http://bitwarden.com> email address. If
-   you didn't receive this email, contact the IT department (@IT in slack). Accept the terms and
-   conditions and complete the sign up flow
+   and you'll be prompted to create an Apple ID for your Bitwarden email address. If you didn't
+   receive this email, contact the IT department (@IT in slack). Accept the terms and conditions and
+   complete the sign up flow
 
 2. Go to [Apple ID Online](https://appleid.apple.com/) and log in with your new Apple ID. Set up
    2-factor authentication (using mobile phone and/or trusted device) - this is critical because

docs/getting-started/server/self-hosted/index.md

@@ -54,7 +54,7 @@ places:
 
 To get an Id and Key, it’s fine to either
 
-- grab them from <https://bitwarden.com/host/>, or
+- [request a host installation ID](https://bitwarden.com/host/), or
 - generate a Guid (Id) and random alphanumeric string (key)
 
 Record these for use in the next steps.

docs/getting-started/server/sso/local.md

@@ -65,9 +65,10 @@ This uses
     docker-compose --profile idp up -d
     ```
 
-9.  You can test your user configuration by navigating to <http://localhost:8090/simplesaml>, then
-    Authentication → test configured authentication sources → `example-userpass`. You should be able
-    to login with the users you’ve configured.
+9.  You can test your user configuration by navigating to
+    [http://localhost:8090/simplesaml](http://localhost:8090/simplesaml), then Authentication → test
+    configured authentication sources → `example-userpass`. You should be able to login with the
+    users you’ve configured.
 
 ## Configure Bitwarden
 
@@ -99,8 +100,8 @@ however any currently authenticated users will have to log out for changes to th
 effect.
 
 To log out as a user, navigate to
-<http://localhost:8090/simplesaml/module.php/core/authenticate.php?as=example-userpass> and click
-Logout. Alternatively, you can use a private browsing session.
+[http://localhost:8090/simplesaml/module.php/core/authenticate.php?as=example-userpass](http://localhost:8090/simplesaml/module.php/core/authenticate.php?as=example-userpass)
+and click Logout. Alternatively, you can use a private browsing session.
 
 ### SAML configuration