GitTop: keyring-core and betting on the modular path

GitTop now uses keyring-core with a separate credential store for each platform.

Most of the diff is dependency plumbing. GitTop already separates shared application logic from OS code because Windows, Linux, and macOS behave differently in several places.

What changed

• Upgraded iced_aw to 0.14.1.
• Added keyring-core for the shared secret-management API.
• Replaced the old keyring crate dependency with explicit credential stores:
  • windows-native-keyring-store
  • apple-native-keyring-store
  • zbus-secret-service-keyring-store
• Added init_keyring and unset_keyring so GitTop explicitly installs the credential store during startup and releases it during shutdown.
• Updated native_backend_name, keyring_available, and related helpers to use the new API.
• Upgraded sha2 to 0.11.0.
• Fixed a panic caused by slicing strings around special characters in PR titles by checking is_char_boundary(idx).

The PR title fix was tiny and overdue. Rust strings are UTF-8, so a byte index can land in the middle of a character. The truncation code now checks is_char_boundary(idx) before slicing.

Why move

The keyring crate now directs application developers to keyring-core and separate credential-store crates.

It requires more setup, which fits GitTop’s existing platform split.

GitTop already keeps OS code under src/platform:

Windows/macOS: iced::application
Linux:         iced::daemon

On Linux, especially Wayland, tray mode closes the window and creates a new one when the user opens GitTop again. Windows and macOS can use the normal desktop application path.

Credentials have the same platform split. Each OS has its own store, setup requirements, and failure modes. GitTop now chooses the store during startup instead of relying on one dependency to choose it implicitly.

Maintenance risk

keyring-core is the documented forward path, but some of the modular store crates move slowly. Commits, PRs, and issues in those repositories see less activity than keyring-rs itself.

Following the documented guidance means depending on pieces that may receive less maintenance. I am comfortable with the architecture and wary of the maintenance load.

The old crate chose more of the implementation for the app. The new API makes the lifecycle explicit:

set_default_store(...)
// use Entry::new(...)
unset_default_store()

GitTop now owns that lifecycle. Startup initializes the store, shutdown releases it, and availability checks query the selected backend. Diagnostics also report the backend GitTop selected.

I think this is the right direction. I am less sure it will stay painless.

Platform stores in GitTop

The tray already uses different machinery on each OS. Notifications use WinRT toasts on Windows, DBus on Linux, and Notification Center on macOS. Memory trimming calls EmptyWorkingSet() on Windows and malloc_trim() on glibc Linux. Windows also needs its own dark-mode handling to match the window frame.

Credential storage now follows that model: a shared API in application code, backed by the store for the current OS. I prefer seeing that choice in the code even though it gives GitTop more setup and teardown work.