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)
t8y2