groups_users and collections_groups were created with UNIQUE constraints
instead of PRIMARY KEY in the 2022-07-27 migration. Add a new migration
that promotes the unique indexes to primary keys.
MySQL auto-names a UNIQUE constraint after its first column, so the index
names to drop are 'groups_uuid' and 'collections_uuid' respectively.
Replacing the previous git checkout approach: using DIESEL_CONFIG_FILE
pointing to /dev/null gives diesel an empty config with no [print_schema]
section, so schema.rs is never written. This is cleaner than restoring
the file after the fact, which would silently hide genuine schema drift.
Two bugs exposed by the integration test workflow:
1. MySQL migration 2022-07-27: groups_users and collections_groups used
UNIQUE instead of PRIMARY KEY. Diesel requires primary keys on all
tables for schema introspection (print-schema). PostgreSQL and SQLite
migrations already used PRIMARY KEY correctly.
2. diesel.toml has [print_schema] configured, so \`diesel migration run\`
rewrites src/db/schema.rs with backend-specific types after running.
This corrupted the checked-in schema before cargo test could compile,
causing E0277 CompatibleType errors for every query. Fix by restoring
the file immediately after each migration run.
MySQL client libraries resolve 'localhost' to a Unix socket path
(/run/mysqld/mysqld.sock), which does not exist in the containerized
service. Use 127.0.0.1 to force a TCP connection.
Two jobs - one per db - each spinning up a service container:
1. diesel migration run --migration-dir migrations/<db>
Verifies every migration applies cleanly to a fresh instance.
This is the primary gap: a broken migration would otherwise only
surface on production deployment.
2. cargo test --features <db> with DATABASE_URL set
Builds and runs the test suite against the live engine. Existing
tests are unit-level (no DB access), but DATABASE_URL is wired in
so any future integration tests work without further infrastructure
changes.
Service containers: postgres:16, mysql:8.4 (utf8mb4).
diesel CLI binary is cached keyed on Cargo.lock hash to avoid
recompiling it on every run.
Triggers on the same path set as build.yml (src/**, migrations/**,
Cargo.*, rust-toolchain.toml).
Adds a cargo-deny step (EmbarkStudios/cargo-deny-action@v2)
after clippy and fmt, gated to the rust-toolchain matrix channel only.
Wires the outcome into the existing failure summary table.
Covers advisories (RustSec), license compliance, duplicate detection,
and source allowlist (crates.io only).
License allowlist reflects the full transitive dep tree: MIT, Apache-2.0,
ISC, BSD-*, 0BSD, Unlicense, Zlib, BSL-1.0, MPL-2.0, Unicode-3.0,
LGPL-2.1-or-later (r-efi, Windows-only), CDLA-Permissive-2.0 (webpki-roots).
Three known advisories are ignored:
- RUSTSEC-2023-0071: rsa Marvin Attack, no upstream fix available
- RUSTSEC-2025-0134: rustls-pemfile unmaintained, blocked on rustls upgrade
- RUSTSEC-2026-0049: rustls-webpki CRL bug, fix blocked by rustls 0.21.x chain
Duplicate versions are warned rather than denied — all are transitive.
Weekly schedule (Mondays), 7-day cooldown, grouped updates to keep PR
noise low. Actions updates prefixed `ci`, Cargo prefixed `deps`. Major
version bumps for Cargo crates are ignored - those are for manualreview
given they can introduce breaking API or behaviour changes.
ubuntu-latest is a moving target that can silently change the runner OS
on the next GitHub-side update. All other jobs in this repo already pin
to ubuntu-24.04; this makes merge-manifests and zizmor consistent.
hadolint/hadolint-action uses a Docker-based runner with hadolint
pre-bundled in ghcr.io/hadolint/hadolint:v2.14.0-debian,so no binary
downloaded at runtime. Pinning the action to a commit SHA covers the
Dockerfile that specifies the image version, closing the supply-chain
gap from the previous unverified curl | sudo install.
Split {debian,alpine}: the action takes a single dockerfile argument,
so debian and alpine are linted separately.
steps.determine-version doesn't exist in docker-build; the expression
resolves to empty string. The HCL default (testing) would have
applied, but it's moot - the bake uses push-by-digest=true so tags are
only set in merge-manifests. Dead code.
Newer versions of the Bitwarden client use Base64 with padding.
Since this is not a streaming string, but a defined length, we can just strip the `=` chars.
Fixes#6960
Signed-off-by: BlackDex <black.dex@gmail.com>
- Update Rust to v1.93.1
- Updated all the crates
Adjust changes needed for the newer `rand` crate
- Updated GitHub Actions
Signed-off-by: BlackDex <black.dex@gmail.com>
Fix an issue where it was possible for users who were not eligible to access all org ciphers to be able to download and extract the encrypted contents.
Only Managers with full access and Admins and Owners should be able to access this endpoint.
This change will block and prevent access for other users.
Signed-off-by: BlackDex <black.dex@gmail.com>
The term "seems to" is used too loosely in many of the tooltips, but in
these 2 instances it is wrong wording.
An update is either available or not. If there is no update, one could
argue that "seems to" is valid, since the Internet could be down to
check for a new version. But in this situation the update is availble.
It is impossible that an update seems to be available.
- Updated all crates
- Updated web-vault to v2025.12.2
- Updated all JavaScript files
- Updated all GitHub Action Workflows
Also added the `concurrency` option to all workflows.
Signed-off-by: BlackDex <black.dex@gmail.com>
When using the latest Bitwarden CLI and logging in using the API Key, it expects some extra fields, same as for normal login.
This PR adds those fields and login is possible again via API Key.
Fixes#6709
Signed-off-by: BlackDex <black.dex@gmail.com>