use the saved passphrase even on first backup

[Marcin Owsiany]

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://gitlab.gnome.org/World/deja-dup/-/blob/main/libdeja/Operation.vala#L254

However (at least in my version) the password is requested interactively, unconditionally (without looking up in the keyring) on the first backup: https://gitlab.gnome.org/World/deja-dup/-/blob/38.3/deja-dup/AssistantBackup.vala#L62

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/deja-dup/
[/]
periodic=true
last-run='2020-11-24T08:48:39.949563Z'
backend='remote'
nag-check='2020-11-10T15:17:10.837501Z'
prompt-check='2020-10-31T20:16:25.858712Z'
exclude-list=['$TRASH', '$DOWNLOAD', '$HOME/tmp', '$HOME/.cache']
last-backup='2020-11-24T08:48:39.949563Z'
periodic-period=1

[s3]
folder='butla'

[openstack]
container='butla'

[gcs]
folder='butla'

[local]
folder='/home/redacted/deja-dup'

[remote]
uri='sftp://redacted/srv/backup/dejadup-butla-redacted'
folder=''

[gdrive]
folder='/deja-dup/butla'

[goa]
folder='butla'

[rackspace]
container='butla'

[file]
path='/home/redacted/deja-dup'
migrated=true

[Michael Terry (mterry)]

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.

[Marcin Owsiany (marcin-owsiany-pl)]

Michael, thank you for the detailed explanation.

Here's my idea: how about still showing the dialog unconditionally on first backup, but populating it with the passphrase from the secret store, if one is present? The user would be able to view it by selecting the "Show password" checkbox.
The experience could be made a little richer in this case by additionally showing in the same dialog some of the passphrase metadata retrieved from the secret store: creation timestamp and/or last modification timestamp. "Oooh, right, this is the password I entered in 2014!"

This would be an acceptable compromise from the PoV of my use case.
And also in the use case you described, it could be seen as beneficial if the user is not forced to re-type the passphrase.