Pass password via stdin, not an env var

[clonejo]

Fixes #80

Contains a workaround for restic/restic#5236

[drdo]

Thanks for the PR!

My main hesitation with this is that it is a bit fragile, depending on the exact byte for byte message that restic prints when asking for a password via stdin.

Would it not work to keep passing the password via env var but log the Command prior to setting the env var and so avoid logging the password?

[clonejo]

Would it not work to keep passing the password via env var but log the Command prior to setting the env var and so avoid logging the password?

Then the password would still be readable to other processes of the same user.

I'm hoping restic will move this issue, given that it's breaking the --json API.

We can't really drop all lines that don't start with {, since there may be an error in there that we need to bubble up.

[drdo]

Good point about the other processes.

There is also an additional problem where even if we are in redu plain password mode, the user may have one of the restic environment variables set and so restic would not even prompt for a password and we would fail to find the password prompt.

[drdo]

The errors from restic should all be in stderr, right? So anything non-json in stdout must be the password prompt (at least for the particular restic commands we care about).

This would stop being true if they do fix it and move the prompt to stderr.

[clonejo]

Well, at least this Verbosef goes to stdout: https://github.com/restic/restic/blob/060a44202fb0da073414e6c6672a5abfc28ac9ed/cmd/restic/global.go#L373

Warnings and errors seem to go to stderr.

[clonejo]

We could also lower the verbosity to 0? (--quiet)

[clonejo]

Another option could be --password-file /dev/stdin.

[drdo]

Another option could be --password-file /dev/stdin.

This seems like a better option that gets around the other problem of the user independently setting env vars and having to parse password prompts.

There is only the question of what to do on Windows.

[clonejo]

There is also an additional problem where even if we are in redu plain password mode, the user may have one of the restic environment variables set and so restic would not even prompt for a password and we would fail to find the password prompt.

I am not not waiting for the prompt, just skipping the stray log line, if it is there.

[drdo]

Maybe let's go back to your original idea of just writing to stdin but be a bit more flexible and ignore the first line of the output if it fails to parse as json.

The idea being to not break redu if restic either changes the message or fixes this and moves the message to stderr.

[clonejo]

If we discard non-JSON lines anyway, --quiet/--verbose=0 feels more reliable. Warnings and errors should end up in stderr anyway.

Or we fix the logging of the password first, and change the password passing later.

Anyway, you're the maintainer :)

[drdo]

Yes, --quiet is better than this, let's go with that.

[clonejo]

implementation is pushed