Merge branch 'main' into autofill/update-inline-menu-documentation

.github/CODEOWNERS

@@ -11,8 +11,8 @@
 package.json
 package-lock.json
 
-# DevOps for Actions and other workflow changes.
-.github/workflows @bitwarden/dept-devops
-
 # Architecture department for architecture content.
 docs/architecture @bitwarden/dept-architecture
+
+# Shared workflows ownership
+.github/workflows/build.yml @bitwarden/dept-bre @bitwarden/tech-leads

.github/labeler.yml

@@ -0,0 +1,3 @@
+adr:
+  - changed-files:
+      - any-glob-to-any-file: docs/architecture/adr/**

.github/workflows/build.yml

@@ -13,10 +13,10 @@ jobs:
 
     steps:
       - name: Check out repo
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4.2.0
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
 
       - name: Set up Node
-        uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4.0.4
+        uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
         with:
           cache: "npm"
           cache-dependency-path: "**/package-lock.json"

.github/workflows/labeler.yml

@@ -0,0 +1,16 @@
+name: "Pull Request Labeler"
+
+on:
+  pull_request_target: {}
+
+jobs:
+  labeler:
+    name: "Pull Request Labeler"
+    permissions:
+      contents: read
+      pull-requests: write
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/labeler@8558fd74291d67161a8a78ce36a881fa63b766a9 # v5.0.0
+        with:
+          sync-labels: true # Remove labels if matches are removed

.github/workflows/lint.yml

@@ -13,10 +13,10 @@ jobs:
 
     steps:
       - name: Check out repo
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4.2.0
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
 
       - name: Set up Node
-        uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4.0.4
+        uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
         with:
           cache: "npm"
           cache-dependency-path: "**/package-lock.json"

.github/workflows/scan.yml

@@ -24,12 +24,12 @@ jobs:
 
     steps:
       - name: Check out repo
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4.2.0
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           ref: ${{ github.event.pull_request.head.sha }}
 
       - name: Scan with Checkmarx
-        uses: checkmarx/ast-github-action@9fda5a4a2c297608117a5a56af424502a9192e57 # 2.0.34
+        uses: checkmarx/ast-github-action@f0869bd1a37fddc06499a096101e6c900e815d81 # 2.0.36
         env:
           INCREMENTAL:
             "${{ contains(github.event_name, 'pull_request') && '--sast-incremental' || '' }}"
@@ -45,7 +45,7 @@ jobs:
             --output-path . ${{ env.INCREMENTAL }}
 
       - name: Upload Checkmarx results to GitHub
-        uses: github/codeql-action/upload-sarif@461ef6c76dfe95d5c364de2f431ddbd31a417628 # v3.26.9
+        uses: github/codeql-action/upload-sarif@662472033e021d55d94146f66f6058822b0b39fd # v3.27.0
         with:
           sarif_file: cx_result.sarif
 
@@ -59,13 +59,13 @@ jobs:
 
     steps:
       - name: Check out repo
-        uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4.2.0
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: 0
           ref: ${{  github.event.pull_request.head.sha }}
 
       - name: Scan with SonarCloud
-        uses: sonarsource/sonarcloud-github-action@eb211723266fe8e83102bac7361f0a05c3ac1d1b # v3.0.0
+        uses: sonarsource/sonarcloud-github-action@383f7e52eae3ab0510c3cb0e7d9d150bbaeab838 # v3.1.0
         env:
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

custom-words.txt

@@ -49,6 +49,7 @@ passcode
 passwordless
 pinentry
 PNSs
+POSIX
 precompiler
 proxied
 recompositions
@@ -67,6 +68,7 @@ signtool
 signup
 sqlcmd
 struct
+structs
 subfolders
 subprocessor
 toolset

docs/architecture/adr/0023-integration-identifiers.md

@@ -0,0 +1,97 @@
+---
+adr: "0023"
+status: Accepted
+date: 2024-10-22
+tags: [server]
+---
+
+# 0023 - Identifying Integrated Clients
+
+<AdrTable frontMatter={frontMatter}></AdrTable>
+
+## Context and Problem Statement
+
+Traffic on the Bitwarden platform continues to grow. As that load increases on our systems it
+becomes imperative to understand how and when our various clients are connecting to our API and
+other server-side components. Not all traffic is currently well-formed and certain key pieces of
+information such as accurate device type signatures and user agents as well as client versions are
+missing or invalid. To best support client-server interactivity there is a desire to not only inform
+deprecated or obsolete integrations that there could be issues, but to protect those server-side
+components from integrations that could do outright harm to the platform or client data.
+
+Beyond the immediate observability needs, there is a significant portion of the community that uses
+alternative (not developed by Bitwarden) clients to access vault data and perform operations. These
+integration methods are perfectly acceptable but are largely unknown, with many not necessarily
+being offered as independent applications but custom integrations for proprietary purposes.
+Bitwarden would like to register these integrations somehow to better understand platform usage and
+utilize common sense constraints to keep the overall platform more resilient and prepare for traffic
+shape changes. Furthermore, a number of Bitwarden-developed integrations are largely external such
+as our [Splunk][splunk] and [Sentinel][sentinel] apps that should also be registered.
+
+## Considered Options
+
+- **Maintain current integration method** - Make no changes to validation or registration of traffic
+  and expect self-regulation of integrations.
+- **Support only Bitwarden integrations** - Utilize application signature checks and other security
+  features to only allow Bitwarden-developed clients to connect to server-side components, therefore
+  constraining traffic to known entities.
+- **Validate baseline expectations** - Inspect and eventually enforce several checks on traffic so
+  that all integrations provide a minimum amount of information on their state so that the platform
+  can be better monitored.
+- **Register integrations along with validation** - Develop a simple registration method for
+  integrations so that they are enumerated and known to Bitwarden, whether internally or externally
+  developed. Associate validation with registered integrations for enhanced developer feedback.
+
+## Decision Outcome
+
+Chosen option: **Register integrations along with validation**.
+
+While this is more effort for Bitwarden to develop than just adding validation, combining efforts to
+expect more from integrations' request data with also providing a registration identifier is a
+simple addition.
+
+### Positive Consequences
+
+- Integrations are registered and known to the platform for sensible traffic identification.
+- Bitwarden's operations group receives data to aid in maintainability of the platform, especially
+  to keep things running well for users while keeping out bad actors.
+- Feedback to Bitwarden support teams on version usage is available.
+- Bitwarden's support policy of a certain number of major versions can be more actively enforced.
+
+### Negative Consequences
+
+- Integrations will need to make the effort to register with Bitwarden and adjust their requests,
+  potentially with brief disruptions for them.
+- Very small latency may be added for the additional validations.
+
+### Plan
+
+Documentation will be provided on the Help Center or this contributing docs site indicating the
+minimally-required request headers for all clients to provide when communicating to the Bitwarden
+platform. Release notes will include mention of this and the future enforcement after a set number
+of major releases. Documentation will also be expanded to offer guidance on how unofficial clients
+should form their provided client version to accurately represent supported "windows" of
+client-server interactivity (or a mapping to the latest Bitwarden server release they have certified
+or tested their integration against) as well as an appropriate [device type][devicetypes].
+
+Operations teams will perform the necessary development to validate that required headers are
+present and enable its enforcement after that time; requests will be rejected as a `400 Bad Request`
+when required headers are missing and a `403 Forbidden` when provided headers or their values are
+not supported.
+
+A process will be established for integrations to submit support tickets requesting a client
+identifier. Customer Success will work with operations teams to register integrations and deliver
+the needed information. Existing Bitwarden integrations will be issued their own client identifiers,
+and this will also be used as an opportunity to establish contact and build a stronger relationship
+with external entities and the community. Client details will be provided in requests to the
+Bitwarden platform, with the goal being the identification of conformance per client to the
+technical needs of the Bitwarden server infrastructure; attestation and the guarantee that a client
+is who they say they are will be considered as a future effort. Subsequent enhancements may occur
+beyond the client identifier wherein API keys and authentication token scopes will further refine
+permissions of an integration.
+
+Self-hosted instances will not perform any checks for client identifiers or required request data.
+
+[splunk]: https://bitwarden.com/help/splunk-siem/
+[sentinel]: https://bitwarden.com/help/microsoft-sentinel-siem/
+[devicetypes]: https://github.com/bitwarden/server/blob/main/src/Core/Enums/DeviceType.cs

docs/architecture/sdk/password-manager/index.md

@@ -0,0 +1,11 @@
+# Password Manager
+
+The Password Manager SDK is designed for internal use within Bitwarden and supports key
+functionality for managing encrypted data, vault access, and user authentication. Written in Rust,
+the SDK is versatile and provides bindings for a variety of platforms, including mobile clients
+(Kotlin and Swift) and web clients (JavaScript/TypeScript).
+
+This section will provide guidance on developing with the SDK in a way that ensures compatibility
+across both mobile and web platforms. It will cover best practices for structuring code, addressing
+platform-specific challenges, and ensuring that your implementation works seamlessly across
+Bitwarden’s mobile and web applications.

docs/architecture/sdk/password-manager/web/index.md

@@ -0,0 +1,7 @@
+# Web
+
+The Password Manager SDK supports web-based clients, allowing developers to integrate core password
+management functionality into JavaScript/TypeScript environments. The SDK is packaged as an NPM
+module under `@bitwarden/sdk-internal` and uses WebAssembly (`wasm`) to enable interaction with Rust
+code. This section will provide guidance and best practices for working with the SDK in a browser
+environment.