feat(fdosecrets): Add persistent client authorization via path and SHA-256 allowlist

[mynameisdeleted]

Overview

Currently, KeePassXC only remembers Secret Service (FdoSecrets) access authorizations in memory for the active session. Every time a background daemon restarts or the system reboots, its PID changes and KeePassXC prompts the user for access again (e.g. goa-daemon, IDE language servers, credential helpers).

This PR adds persistent client authorization by storing the executable's canonical path and SHA-256 checksum in keepassxc.ini under [FdoSecrets]/AuthorizedClients.

---

How It Works

• Remember Decision: Checking "Remember this decision" (or selecting "Allow All") in the access prompt saves the client as path:sha256 in settings.
• Revoke: Selecting "Deny All" removes the executable from the allowlist.
• Verification on Connect: When a client connects via D-Bus, KeePassXC checks whether its canonical path and current SHA-256 hash match an authorized entry. If matched, access is granted automatically without a prompt.
• Binary Integrity: If a binary is modified or updated, the hash will not match, safely falling back to the confirmation prompt. Approving it again with "Remember" updates the saved hash.

---

Changes

1. Config: Added FdoSecrets/AuthorizedClients string list setting.
2. FdoSecretsSettings: Added helpers to check, add, and remove path:sha256 client entries using canonical paths and SHA-256 hashing.
3. DBusClient: Automatically grants access on connection if the client is allowlisted.
4. AccessControlDialog: Saves or revokes client authorization on dialog completion based on the user's choice and the "Remember" checkbox.

---

Testing

• Verified with goa-daemon and language servers: access is granted silently after process restarts and reboots.
• Verified that binary changes trigger the prompt again, and re-approving updates the stored hash.
• Verified that "Deny All" removes the client from the allowlist.

[michaelk83]

This PR adds persistent client authorization by storing the executable's canonical path and SHA-256 checksum in keepassxc.ini under [FdoSecrets]/AuthorizedClients.

That doesn't sound secure at all. Anyway, this is already in progress in #13610.
(This is the 2nd duplicate PR in the last week or so, which I guess shows the level of interest for that feature.)

[mynameisdeleted]

While investigating storing FdoSecrets/AuthorizedClients in database CustomData, I realized a full defense-in-depth solution requires migrating other security settings currently stored in plaintext keepassxc.ini:

• Secret Service & Browser: ConfirmAccessItem, Browser/Enabled, SearchInAllDatabases
• Security & Vault: Security/* (idle lock timeouts), PasswordGenerator, and KeeShare keys

Moving these policies to per-database CustomData is very doable and ensures vault security posture cannot be silently tampered with at rest without decryption keys. Because that represents a broader architectural change across multiple subsystems, I preserved keepassxc.ini backwards compatibility in this PR and propose addressing the full migration in a dedicated follow-up PR.

[mynameisdeleted]

I noticed @Aetf's comprehensive work in #13610, which strongly validates storing client authorizations and executable hashes in database CustomData.

Given the substantial scope and surface area of #13610 (~6,000 lines across 50 files), I would propose a phased approach:

1. This PR (Phase 1): Delivers the core client authorization functionality in a lightweight, focused change (~400 lines) with backwards-compatible config fallback and simple database-level management.
2. Phase 2 (Separate PR): A dedicated architectural initiative to migrate other plaintext security policies (ConfirmAccessItem, auto-lock timers, KeeShare keys) into per-database encrypted CustomData.
3. Phase 3 (Follow-up): Advanced UI enhancements and fine-grained per-entry/process-tree rule editing once the core data models are stabilized.

I’m happy to leave both open and let the maintainers decide whether they prefer the monolithic overhaul in #13610 or this phased, incremental path.

[mynameisdeleted]

Update: /proc/PID/exe Verification & PR Scope

I just pushed an update (ec532228) that consolidates the SHA-256 calculation into a single FdoSecretsSettings::hashProcess() function:

• On Linux, it inspects /proc/<pid>/exe directly to hash the running binary inode, avoiding TOCTOU path races and working even if binaries are updated/replaced while running.
• It falls back cleanly to the file path on non-Linux platforms or when a PID is unavailable.
• Propagates client PID from PeerInfo through DBusClient and AccessControlDialog.

Regarding configuration storage: I considered migrating client authorizations strictly to encrypted database CustomData, but keeping keepassxc.ini support in this PR preserves backwards compatibility and keeps this PR focused (~400 lines). Since truly hardening the local config threat model also entails moving other plaintext settings (ConfirmAccessItem, auto-lock timeouts, KeeShare keys) into database metadata, I plan to propose that full migration as a dedicated architectural follow-up PR.