Can this be possible to read the repro password from gnome keyring…
Hello @saviodsouza, a neat idea!
I’ll let @fd0 comment if he wishes to add such feature to restic itself. Though, I’d highly recommend we let him spend time working on compression support, which is beggining to be restic’s weakest point.
Anyway, as one common way to authorize restic is to provide
RESTIC_PASSWORD environment variable, I believe you could quickly come up with a solution by extracting needed value from the gnome keyring, setting the variable and only then calling restic.
You might find this decade old page useful: https://blog.schmichael.com/2008/10/30/listing-all-passwords-stored-in-gnome-keyring/
Not to get off-topic, but I was thinking that optimizing prunes (or in general, the in-memory index size) was the next major project. Either would be cool I guess. But honestly most of the files I back up are already compressed anyway.
I think that python script that @zcalusic linked to would be a good starting point, though I would suggest that it would be more secure to put the password into a read protected temporary file rather than an environment variable, as environment variables can be read by anyone via the /proc filing system.
From that you could then write a python script to wrapper restic that will setup passwords (and anything else you need), before calling restic. You can then call your wrapper script from cron on whatever.
As a general comment, I think restic could do with a contrib area for useful scripts such as this, as there must be loads of users who are re-inventing wheels like this and should not have to.
Opening restic/contrib folder and putting various useful snippets in there is an excellent idea @chrestomanci
That’s a common myth and it’s not true for Linux in the last two decades. By default, the file
/proc/<pid>/environ can only be read by the user the process belongs to. Here’s a bit of background: https://security.stackexchange.com/questions/14000/environment-variable-accessibility-in-linux/14009#14009
If you don’t want to use environment variables, then use the shell to run a program which prints the password to stdout, and the shell will take care that restic can read this from a (simulated) file:
$ restic --repo /srv/data/repo --password-file <(gpg --decrypt restic-password.gpg) backup /home
In this case, the password can only be read once (by restic) and won’t be contained in the process’ environment variables.
I think the gnome keyring thing has a CLI program which allows printing passwords to stdout, you can use it with restic this way.
While I in general like the idea of collecting user contributions somewhere, at the risk of sounding very negative: I’d like to keep that out of the repositories in the restic org.
The question here is: who maintains these scripts? I think we should concentrate on improving restic itself, adding important features (prune, compression, config file) over time. So the contributed scripts should live somewhere else, so users don’t get the impression that we maintain them.
How about adding a section to the manual where we collect links to repos of other people? This way, it’s clear that we (as a project) are not responsible for maintaining the scripts.
My concern with a section in the manual with links to other people’s repos is dead links and possible mixed quality of the scripts. I also think that in most cases what we want is code snippets that can be modified and re-used rather than complete scripts.
How about having a section in the restic.net documentation site for script snippets. Those pages are hosted via github, and anyone can make contributions via a pull request, but you and others can still enforce quality by reviewing those pull requests, rejecting low quality submissions, and pruning the contributions from time to time.