The overrides were not being passed to the askpass kitten.
And we dont need to support backward compatibility for secrets with no
backend, since this feature has never been released.
Motivation: Some environments disallow or do not reliably accept one-way
pubkey-only auth, or require keyboard-interactive password + TOTP. This adds an
optional, host-scoped automation via kitty's native askpass to reduce repetitive
manual entry while preserving the ssh kitten UX.
- Add auth_config.go to parse password/totp_* from ssh.conf by host block
- Ignore these keys in main ssh.conf parser to avoid bad-line warnings
- Pass host/user to askpass for host-aware lookup
- Auto-answer password and OTP prompts in askpass; fallback to UI otherwise
Security: Secrets in ssh.conf are plain text; users should enforce strict
permissions or avoid storing passwords if unacceptable. Only login password/OTP
prompts are auto-answered; passphrases and host key confirmations are not.
feat(ssh): add secret backend support for auth passwords and TOTP secrets
Introduce support for specifying secret backends in SSH auth config, currently supporting only the "text" backend for storing secrets directly. This allows for future extensibility while maintaining backward compatibility by treating values without a backend as "text:<value>".
The changes include new fields in AuthEntry for backends, updated parsing logic in lineHandler, error handling for invalid backends, and normalization for existing configs. A new parseBackendSecret function handles the parsing with validation.
Move code to incrementally update lsc config into the kitten module do
that it is more likely to stay in sync with any future changes to the
kitten cli.
This commit addresses a few issues with the implementation of
'--incremental':
- Unspecified settings are reset to their default value, which
defeats the purpose of the option.
- It is assumed that the names of options in 'LayerCLIOptions' map
one to one with the names of fields in 'LayerShellConfig' but this
isn't true. For example: The 'margin_top' cli option sets the
'requested_top_margin' layer shell config.
- When some options are set to a certain value, they force other
options to be some value. The current implementation doesn't
account for this.
- The documentation is contradictory.
In the case where a portals.conf file does not exist in the user
configuration, there is nothing to patch; we should default to defining
the relevant portals for kitty.
1. Make sure we coalesce XDG_DATA_HOME as per the spec
On my machine /etc/profile.d/flatpak.sh sets
XDG_DATA_DIRS=$HOME/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
but XDG_DATA_HOME is unset.
2. Update directory creation logic to find-or-create
`enable_portal`'s current behavior is to first find a writable directory and
write the portal definition to it, then fall back to creating a directory
in the first available configuration directory.
This is incorrect in the case where one of the locations in
XDG_DATA_DIRS already has a directory, we should still prioritize
XDG_DATA_HOME.
