Sign and verify macOS MCP artifacts with a stable Developer ID requirement. Reject unsigned npm reruns, verify archive integrity, and clean up the isolated CI keychain on success or failure.
Closes#10715
The keyring crate's Linux backend requires C libdbus, which cross builds
(zigbuild) cannot link, so Linux desktop users hit the same
desktop-migrated-but-MCP-blocked failure that macOS/Windows users hit in
0.4.94 - with no native build to fix it on. Replace the Linux keyring
path with the secret-service crate (pure-Rust zbus, no C dependencies,
speaks the session-bus protocol directly), keeping the exact on-disk
attribute layout the keyring crate writes (target/service/username,
with the legacy no-target fallback) so existing desktop-provisioned
keys remain readable both ways.
- connect/collection failures (no session bus, headless servers) map to
a missing provider so callers keep falling back to the managed
.dbx/secret.key file exactly as before
- found-but-unreadable keyring items now fail fast with a specific
KEYRING_ACCESS_FAILED code on every platform instead of silently
provisioning a new key that would strand existing ciphertext
- the Linux zigbuild MCP/CLI package legs build with os-keyring
Desktop enables os-keyring and provisions the data-encryption key in the
OS keychain during the data security upgrade, but dbx-mcp/dbx-cli package
builds compiled without any keyring backend (the feature became opt-in
for the Linux cross builds), so every desktop-migrated profile made the
MCP fail with DATA_MIGRATION_REQUIRED forever - the error even pointed
users back at a migration they had already completed.
- dbx-mcp gains an os-keyring forwarding feature; the native macOS and
Windows MCP and CLI legs of the packages release build with it, Linux
zigbuild legs keep the managed .dbx/secret.key fallback
- LocalBackend::open now separates 'key unreadable in this process'
(SECRET_KEY_UNAVAILABLE with the DBX_SECRET_KEY_FILE/DBX_SECRET_KEY
escape hatch) from genuinely pending legacy data, keeping the
DATA_MIGRATION_REQUIRED contract for the latter (test covered)
jammy's mold 1.0.3 mis-links the bundled duckdb C++ library: every
runtime test panicked in duckdb_create_config. Install the current
static upstream build (with a post-install version check) instead.
sccache cannot cache the link step, so test-binary linking dominated
rust-test and the packages release build. Wrap the cargo-invoking steps
with 'mold -run' (PATH-level ld interception) instead of touching
RUSTFLAGS or .cargo config, which would rekey the shared sccache cache.
The packages job compiled dbx-cli/dbx-mcp cargo targets with no cache at
all. agent-rust only had rust-cache, so every lock change recompiled the
bundled duckdb C++ library. The GHA sccache fallback for fork PRs wrote
nothing (0% hits, all writes erroring under the v2 cache service) while
main only populates S3, so forks now build without a wrapper and lean on
the rust-cache restore from main.
luo jiyin