feat(auth): read the password from stdin or prompt for it

[ftarasenko]

--os-password / OS_PASSWORD were the only ways to supply a Keystone password, and neither is a good place for a secret: a flag value is visible in ps and lands in the shell history, and an exported variable is inherited by every child process.

This adds the two sources that close that gap — one koc-native, one upstream parity — both consulted from Authenticate.

--os-password-stdin (koc-native)

Reads the password from standard input, docker login --password-stdin style: the whole of stdin less one trailing line ending, so a password may legitimately begin or end with a space.

koc server list --os-password-stdin < ~/.config/koc/password
pass show keystack/admin | koc server list --os-cloud keystack --os-password-stdin

• More than one line is rejected — that is a whole openrc piped in by mistake, and authenticating with its first line is the confusing outcome.
• Conflicts with an explicitly typed --os-password and with --creds-from-ns / --creds-from-vault, which bring their own credentials.
• Overrides OS_PASSWORD (background configuration, not a typed flag) and, via markForced, outranks a named cloud's stored password exactly like a typed flag does.
• Deliberately flag-only, with no OS_* default: consuming stdin is something a run must opt into visibly.

Upstream has no equivalent — osc-lib's only non-OS_PASSWORD route is the interactive prompt, which a CI job cannot use.

Interactive prompt (python-openstackclient parity)

When nothing supplied a password and stdin is a terminal, koc now asks on stderr without echo, the way osc-lib does through getpass, instead of failing. This covers the --os-cloud case where the clouds.yaml entry carries a username but deliberately no password.

A non-interactive run is never prompted: it fails with no credentials found, whose message now also names --os-password-stdin and the prompt, rather than blocking on a pipe nobody is going to write to.

Shared behaviour

Neither source fires when the request authenticates without a password (application credentials, a pre-issued token). Both write the result back to Options, so a second Authenticate in the same process neither re-reads an exhausted stdin nor prompts twice; gophercloud's own reauth replays the stored auth options and never reaches either.

Verification

New internal/auth/password_test.go (20 cases) covers the parsing rules, every conflict, the "authenticates without a password" cases, the reauth replay, and three end-to-end runs through Authenticate against a mock Keystone — including the clouds.yaml-with-no-password path.

The real binary was also exercised against a mock Keystone that records the token-request body:

Case	Result
printf 'piped-pw\n' | koc … --os-password-stdin server list	request body carried "password":"piped-pw"
no password, no tty	no credentials found: … pass --os-password-stdin, or run interactively to be prompted
no password, under a pty	Password: prompt; body carried the typed password
--os-password typed --os-password-stdin	mutually-exclusive error, no request sent
empty stdin / whole openrc piped	distinct errors, no request sent
application credentials under a pty	no prompt
prompted password with --debug	dump shows "password":"<redacted>"

Gate: gofmt clean, go vet clean, go test ./... green, go test -race green, offline -mod=vendor GOPROXY=off build and test green. golangci-lint could not be run locally — the available binary is v2.5.0, built with go1.25, and it refuses this module's go 1.26.0 target — so the pinned v2.13 in CI is the first real lint run on this code.

docs/coverage.md command counts are unchanged (no command is added, renamed or removed); the "koc-native global flags" paragraph, which said "one global flag", now lists --os-password-stdin alongside --timeout. README gains a "Where the password comes from" subsection under Authentication.

🤖 Generated with Claude Code

https://claude.ai/code/session_01McdyrP2uagmAnTsE3oMvha

---

Generated by Claude Code