Add environment variables for API keys that point to files and commands, instead of the API key itself

[ddribin]

Output of restic version

> restic version
restic 0.16.3 compiled with go1.21.6 on linux/amd64

What should restic do differently? Which functionality do you think we should add?

Using a service like Amazon S3 or Backblaze B2 means storing the API key in an environment variable. From the docs:

https://restic.readthedocs.io/en/latest/030_preparing_a_new_repo.html#amazon-s3

$ export AWS_ACCESS_KEY_ID=<MY_ACCESS_KEY>
$ export AWS_SECRET_ACCESS_KEY=<MY_SECRET_ACCESS_KEY>

https://restic.readthedocs.io/en/latest/030_preparing_a_new_repo.html#backblaze-b2

$ export B2_ACCOUNT_ID=<MY_APPLICATION_KEY_ID>
$ export B2_ACCOUNT_KEY=<MY_APPLICATION_KEY>

The secret key should be treated like a password, as it provides access to that service. It would be more secure to store secret keys in a file or in a password manager, instead of the environment. I propose all *_KEY environment variables have two other alternatives:

• Reading the key from a file, e.g. AWS_SECRET_ACCESS_KEY_FILE, B2_ACCOUNT_KEY_FILE
• Reading the key from a command, e.g. AWS_SECRET_ACCESS_KEY_COMMAND, B2_ACCOUNT_KEY_COMMAND

This also adds parity with RESTIC_PASSWORD_FILE and RESTIC_PASSWORD_COMMAND:

https://restic.readthedocs.io/en/latest/040_backup.html#environment-variables

What are you trying to do? What problem would this solve?

I am trying to more securely send passwords and API keys to restic. Using environment variables is okay, but it is better to read from a file or command. This has some good background: https://clig.dev/#environment-variables:

Do not read secrets from environment variables. While environment variables may be convenient for storing secrets, they have proven too prone to leakage:

• Exported environment variables are sent to every process, and from there can easily leak into logs or be exfiltrated
• Shell substitutions like curl -H "Authorization: Bearer $BEARER_TOKEN" will leak into globally-readable process state. (cURL offers the -H @filename alternative for reading sensitive headers from a file.)
• Docker container environment variables can be viewed by anyone with Docker daemon access via docker inspect
• Environment variables in systemd units are globally readable via systemctl show

Did restic help you today? Did it make you happy in any way?

Yes! I have been running it on multiple Linode servers as a remote/offsite backup to Backblaze B2 for a few years now.