I'm currently using a small script to create my backups that has two statements.
borg create ...
borg prune ...
Both commands require the password to be entered. I'm currently entering those passwords manually. It would be great if only one password was required. I could use an environment variable but I don't like the idea of storing my password in the shell environment while doing the 'create' part.
I suggest adding a single command that does create and prune.
Alternatively you could add a repl mode where you run borg commands line by line (create, prune). Then one could even pipe the commands to borg.
If you do not enter it manually, but have it in the BORG_PASSPHRASE env var, it won't ask.
Yes I could use the BORG_PASSPHRASE environment variable, but I don't like that idea because of cat /proc/<pid>/environ. Try that on any process below the shell that exports BORG_PASSPHRASE (like borg). You can read the password. Using /proc/
As the password is required to decode the repo key and derive some key material for block map etc. It can be discarded after these values are present.
because of cat /proc/
/environ
For exactly this reason the environ file has 0400 access rights.
As the password is required to decode the repo key and derive some key material for block map etc. It can be discarded after these values are present.
I don't follow?
This does not prevent root or any user with CAP_DAC_OVERRIDE from reading it. The environment may not be as secure on other UNIX like OS.
The environment is passed down to any spawned process that does not know about the secrets. This may leak the keys.
This does not prevent root or any user with CAP_DAC_OVERRIDE from reading it. The environment may not be as secure on other UNIX like OS.
Ok, but someone with root/DAC_OVERRIDE can per definition read anything anyway. He could even attach a (python) debugger to your processes and just print the variables. Or just read the script/file where the password is stored.
In this scenario there is hardly a way to do this safely. Even passing it over an open and inherited file descriptor (like gpg(1) supports it) wouldn't be safe.
The environment is passed down to any spawned process that does not know about the secrets. This may leak the keys.
Fair point.
RemoteRepository.init "env = dict(os.environ)" should be fixed.
The environment may not be as secure on other UNIX like OS.
Also a fair point that needs investigation.
I think this ticket should be closed and every single point found valuable should be taken to its own ticket: