United Authenticator is a local-first TOTP authenticator (https://github.com/scyllarusllc/united-authenticator). Accounts are encrypted at rest (AES-256-GCM) with a 32-byte key generated once per install. On macOS/Windows/Linux that key is held in the OS keychain via the `keyring` crate, accessed through the `password-manager-service` interface under strict confinement.
Under manual connection, a fresh install can’t read or write that key until the user runs `snap connect united-authenticator:password-manager-service` in a terminal — which defeats the point of a “no terminal needed” desktop app and leaves first-run users stuck with no explanation beyond a DBus/AppArmor denial.
Scope of use: exactly one keychain entry per install (service=`com.pomatez.united-authenticator`, account=`vault-key-v1`), holding only the vault’s symmetric encryption key — no passwords, no OAuth tokens, no other secrets. (Google Drive backup, if the user enables it, uses a separate plain-file OAuth token store, not the keychain — this request is solely about the local vault key.)
Requesting auto-connect so the encryption-at-rest feature works out of the box on first launch.
This request has been added to the queue for review by the @reviewers team.
Hello @ScyllarusLLC 
As mentioned in the post shared by @ogra, we discourage auto-connection of password-manager-service in the general case. The interface provides access to the global password manager services provided by the desktop environment . This gives privileged access to sensitive information stored in the user’s session, not just the snap’s own secrets, but all secrets held by that service. It is also a two-way street: once connected, any other application (including other snaps) with password-manager-service connected can read or overwrite your snap’s stored entry.
Thus that’s a -1 from me, for granting auto-connection of password-manager-service interface to united-authenticator.
Hello @yomonokio and @ogra,
Thank you both for the detailed explanation. I completely understand the security implications and the “two-way street” risk of granting full read/write access to the global session secrets.
@ogra, I appreciate you pointing out the Secret Portal approach. I will investigate configuring the Rust keyring crate to utilize libsecret through the desktop interface instead of relying on the global DBus service. If the portal environment isn’t fully supported in all target distros yet, I will implement a graceful fallback that either prompts the user for manual connection or encrypts the vault key locally in $SNAP_USER_DATA.
We can go ahead and close or reject this auto-connect request. I’ll pivot to the portal/fallback architecture for United Authenticator.
(P.S. No worries about the tabularis typo at the end, yomonokio! I knew you meant United Authenticator 
)
Best regards, Scyllarus LLC, USA
1 Like
P.S. No worries about the tabularis typo at the end, yomonokio! I knew you meant United Authenticator )
Busted! Sorry for that, everything should be nice and clear now