[Feature request] Support repository address and password using environment variables

[rapenne-s]

Hi

Most backup tools support passing the repository address and the repository password as environment variable, this makes scripting easier, and automated backups are a must.

Systemd services can load environment variables from files, which make it easy to write scripts and loading secrets from a file that can only be read by root.

It would be great if wyng could support this mechanism.

[tasket]

@rapenne-s Have you tried --passcmd? Its simple to use echo $VAR or cat file with it. And it can be added to wyng.ini settings as well.

Also, I should add this to the doc: The passphrase is always the first thing read on stdin when auth is performed for encrypted archives. So doing a regular pipe of the secret will work.

Related: #171

---

What gives me pause in directly reading the env for the passphrase is that the practice is associated with mishandling or breeches because (for example) env being dumped out in error reports (automated or otherwise). Using --passcmd "cat file" is at least a bit of an improvement. And the idea of the secret being "in the environment" sort of like "out there, bumping around in the shell" was something I didn't like (not the most rational explanation, I know).

As for examples to follow: OpenVPN is one that uses env variables extensively yet tries to limit client password input to stdin only (even userpass file has to be enabled at compile time).

OpenSSH appears to be another example.

Generally, I've expected most variables (not secrets) to be represented on the command line. Reading env directly means adding a 3rd interface (in addition to CLI and config file) where yet another interface (Python API) is already planned. This means fielding requests to expose xyz feature to env settings in addition to making troubleshooting less clear (and env dumps become a regular part of the process).

I'm open to ideas on this subject, but currently leaning toward the option that is simpler to implement and protect.

[tasket]

To clarify one point: Using --passcmd "echo $VAR" is probably the less safe option and not really the same as if Wyng were to read the env var directly – if Wyng did read the var directly, it could then unset it, which avoids subprocesses inheriting it and other issues. My feeling is that --passcmd "cat file" is safer, and --passcmd "agent-or-wallet-app" even safer.

I'm also open to hearing about counter-examples, security tools that do accept secrets via env.

[tlaurion]

Maybe it should be added to docs, but there is a simple hack around all the above, which is
<(cat /path/to/secret) which will expose an fd in logs as opposed to the secret itself @rapenne-s @tasket .

--passcmd combined to this should fill the need?

[kennethrrosen]

My feeling is that --passcmd "cat file" is safer, and --passcmd "agent-or-wallet-app" even safer.

This is how my current script works (with cat) but how does agent-or-wallet-app work? Can it qrexec to a vault VM for KeePass?