use the saved passphrase even on first backup
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Déjà Dup |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
My use case: as a system administrator I would like to pre-populate users' dconf and keyring such that their backups run automatically without prompting the user.
I mostly managed to do that, including populating the password that is looked up by lookup_keyring() at https:/
However (at least in my version) the password is requested interactively, unconditionally (without looking up in the keyring) on the first backup: https:/
This effectively means that the pre-populated password is not used.
$ lsb_release -d
Description: Debian GNU/Linux 10 (buster)
deja-dup 38.3
$ dconf dump /org/gnome/
[/]
periodic=true
last-run=
backend='remote'
nag-check=
prompt-
exclude-
last-backup=
periodic-period=1
[s3]
folder='butla'
[openstack]
container='butla'
[gcs]
folder='butla'
[local]
folder=
[remote]
uri='sftp://
folder=''
[gdrive]
folder=
[goa]
folder='butla'
[rackspace]
container='butla'
[file]
path='/
migrated=true
Changed in deja-dup: | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
Interesting. There is a philosophical discussion about the merits of a default encryption password, but let’s leave that aside for now.
One reason we don’t accept a password sitting there already is that the user might be making a new backup and might want an opportunity to change the password or not use one. And if we silently just back up with an old saved password (from theoretically a long time ago), the user is going to eventually file a bug like “I never set a password, how do I get my files back?”.
But maybe there’s room for checking a key that is designed to be set by administrators like you, to peer-seed their first backup. Needs some thought.