SecureShell Go 1.4.1

Saving a password or key used to fail outright on any machine where no
system keyring answered — and then stop, with nothing the user could do
about it. 1.4.1 removes that dead end.

Credentials no longer depend on having a keyring

Where no Secret Service provider is reachable, SecureShell Go can now
protect credentials with an app passphrase instead, encrypting them
into its own private file with the same Argon2id + AES-256-GCM container
the encrypted-backup feature uses. The passphrase wraps a random vault
key, so the slow key derivation runs once when you unlock rather than on
every read and write.

There is still no plaintext fallback anywhere — this is a different
protection, not a weaker one.

The system keyring is still preferred whenever it answers, and there is
deliberately no path that silently moves an install with a working
keyring onto the passphrase vault. A keyring that is merely locked
means "unlock it", not "migrate everything"; the offer to create a vault
only appears where no keyring has ever worked, and that fact is
remembered across restarts.

The packaging gaps that caused it

• Debian/Ubuntu: the package depended on libsecret-1-0, which is
  only the client side of the Secret Service API — nothing pulled in a
  daemon to talk to. It now recommends gnome-keyring (accepting an
  existing kwalletd or keepassxc instead).

• Snap: password-manager-service is declared but snapd never
  connects it automatically, so every snap install hit this. The app now
  names the exact command instead of suggesting software you already
  have:

  sudo snap connect secureshellgo:password-manager-service
  

• Installing a downloaded .deb with dpkg -i skips Recommends
  entirely. Use sudo apt install ./secureshellgo_*.deb and the
  dependency comes along.

Honest diagnostics

The message no longer claims no keyring is installed. The Linux plugin
raises a single error code for three different situations — no provider
reachable, a provider with no collection aliased default, and a
default collection that would not unlock — and which one occurred is not
knowable from inside the app. It now says the keyring "could not be
reached or unlocked", which is true in all three cases.

Migration from the vault back to a keyring is deliberately not
implemented rather than half-built.