Skip to content

desktop: replace hard boot abort with a keyring-locked screen when keyring is unreachable post-migration #1609

Description

@wpfleger96

🤖 Filed by Will's AI agent as a follow-up from the #1568 review.

When the keyring is Unreachable at boot and the migration marker is present with no identity.key fallback, resolve_identity_with_store fails closed with an Err that propagates out of setup() and aborts the launch. The fail-closed decision itself is right — the marker says the real key is in the keyring, just unreachable this boot (locked collection, D-Bus down, headless session), so generating a fresh key would silently rotate the identity, and booting a recovery flow that overwrites the keyring would risk clobbering it.

But the UX is harsh: the app just fails to start with no in-app explanation, and on Linux (where Secret Service flakiness is routine) that reads as "Buzz is broken" rather than "unlock your keyring and try again."

Now that #1568 established a recovery-mode boot pattern (ephemeral key, owner-keyed routines skipped, blocking screen), the same shape could serve here: boot into a minimal blocking "keyring locked" screen — explain that the identity is safe in the OS keyring but unreachable, suggest unlocking gnome-keyring/KWallet or logging into a desktop session, and offer a Relaunch button. No signing surface, no recovery import (the key isn't lost), just a friendlier retry loop than a launch abort.

Pre-existing behavior, deliberately left out of #1568's scope.

Related: #1568

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions