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/
1 Like
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.
1 Like
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.
I was playing around with my script and found an easy way to encrypt the password file using almost this same command with variables. The only concern is that, if I “debug” the script using bash -x script then it will show all the exports in plain text including the password file. Does this happen if I use the command you posted when debugging restic?
What I did was to create a variable RESTIC_PASSWORD=$(gpg --decrypt --quiet pass.gpg) in my configuration file so the script export this variables and execute the commands. It works but as I said, if someone knows how to use bash then all the effort is worthless.
No, it won’t show the password.
I don’t understand this statement.
There seems to be a general misconception: if someone has permission to modify your shell scripts and/or shell startup files or is able to execute commands as your user account, you’ve lost either way. That’s even the case if you just enter the password manually each time. That attacker model is extremely powerful, so it’s very hard to defend against, and usually it’s not worth it.
So, when you (manually) run bash -xv to debug your scripts and the password shows up, that’s usually not a problem to worry about.
1 Like
You’re totally right. What I was thinking was, for example, if I want to setup restic for various hosts in an office, then I would need the script to use an encrypted password file because that way the regular user cannot retrieve the repo password but the downside about this is that I need the script to use a passwordless private GPG key for automation and that could need to be inside the same user, so it is useless because if the person find both, then the user can decrypt the password file or even use the same script to perform some malicious attack. So going back to basics, it is better to create a user just for restic as mentioned in the docs examples.
Thanks for your answer and again for this great software.
Yup. This is exactly why Pidgin does not encrypt passwords, for example – it has to decrypt them automatically, so an encrypted password is as good as a plaintext password when the attacker has easy access to the key.
- Obscure a password. This means we do something to store the password in some format other than plain text, but we automatically convert it for you. This is security by obscurity, and is a Very Bad ThingTM in that it gives users a false sense of security that we (Pidgin, Finch, and libpurple developers) believe would be worse to have than to let informed users deal with the password issue themselves. Consider that a naive user might think that it is safe to share his or her accounts.xml, because the passwords are “encrypted”.
2 Likes
Sorry if this is necrobumping, but you can achieve this in Gnome and KDE using --password-command and secret-tool.
The parameters are a little bit annoying to figure out, but essentially you are saving under and searching for key-attribute values, and can configure something like type, repo and host or whatever you want:
secret-tool store --label="Restic" type restic repo $reponame host $hostname'
and then get the data into restic using
restic --password-command 'secret-tool lookup type restic repo $reponame host $hostname
and on MacOS you can use the security command, again with some fields that you define, like a service name (-s) and account name (-a)
security add-generic-password -s restic -a $hostname -w
and get the secret back into restic using
restic --password-command 'security find-generic-password -s restic -a $hostname -w'
I am very successfully using these with crestic, so these lines end up in my crestic.cfg and I am simply calling crestic home backup.
Be aware that you have to unlock your machine with graphical desktop manager like GDM or SDDM in order for the keyring to be unlocked and the keys to become available. Logging in via SSH will not unlock the keyring. Once you log out, the keys will become unavailable again.
1 Like