Handling passwords when stdin is a pipe (as opposed to a TTY)

[cipriancraciun]

At the moment (in v1.0.0) when stdin is a pipe (for example some-command-to-print-secret | cosign generate-key-pair) the tool tries to read the password twice and fails to verify it. (I know there is COSIGN_PASSWORD, but I would like to avoid exposing it as an environment variable.)

This is not exactly a "bug", more an "unexpected behaviour", since most tools that input passwords, if they detect a pipe (or anything that is not a TTY) as stdin, they just don't prompt for passwords and read it once.

---

How would I propose to handle it:

• add two (mutually exclusive flags), --password 'some-secret' and --password-fd 7 (that can be used in bash as --password-fd <( some-command-to-print-secret)), that could be used to supply passwords; (noting that --password is even worse security wise than environment variables;)
• if one starts cosign without any flag or environment variable denoting passwords, and /dev/stderr is not a TTY, then fail; (I say /dev/stderr because one should always use that for TTY interaction, and because someone might just use stdin as the blob to be signed;)

[cipriancraciun]

Also, strangely even if COSIGN_PASSWORD is exported, the tool still reports Enter password for private key: and Enter again:, although it does seem to use the environment variable.

[dlorenc]

Thanks for the detailed report! This does look incorrect. Would you like to give fixing this a try? I'd be happy to provide some pointers.

[cipriancraciun]

[@dlorenc] Would you like to give fixing this a try? I'd be happy to provide some pointers.

I might give it a try (my assumption is to look in the GetPass function).

However quickly looking through the source code I see that term.ReadPassword is used in quite a few places, therefore perhaps a policy regarding password management should first be identified, and then implemented throughout the code-base (not just the private key handling).

(I see that in the master branch, the GetPass already tries to handle pipes.)

[dlorenc]

Hmm, I only see that in two places:

cosign/cmd/cosign/cli/generate_key_pair.go

Line 156 in 1f9d3d9

return term.ReadPassword(0)

and

cosign/pkg/cosign/pivkey/pivkey.go

Line 196 in 9adaad5

func getPin() (string, error) {

We could reduce more, but one is for a PIN and one is for a password.

It looks like the GetPass stuff is probably the right place to fix this.

[dlorenc]

Closed, fixed with above