|
From: | Kenneth Loafman |
Subject: | Re: [Duplicity-talk] gpg key password asked for backup after verify |
Date: | Wed, 24 May 2017 10:34:47 -0500 |
Ken,
how is the state wrt. librsync patch, didn't see it in the repo so far?
*and*, below is once again somebody complaining that suddenly a private key / passphrase is needed. would you agree that we should remove the dirty workaround described in
https://bugs.launchpad.net/duplicity/+bug/687295
for duplicity 0.8?
it really only "works" with english locale and a backup that does not try to resume. still users risk to do backups where archive dir is not synchronized, which is bad for their data.
..ede
-------- Forwarded Message --------
Subject: Re: [Duplicity-talk] gpg key password asked for backup after verify
Date: Wed, 24 May 2017 16:14:31 +0200
From: Raphael Bauduin <address@hidden>
To: address@hidden
On Wed, May 24, 2017 at 1:49 PM, <address@hidden <mailto:address@hidden>> wrote:
whoops, hit send too fast. read on below.
On 24.05.2017 13 <tel:24.05.2017%2013>:17, Raphael Bauduin wrote:
>
>
> On Wed, May 24, 2017 at 12:19 PM, edgar.soldin--- via Duplicity-talk <address@hidden <mailto:address@hiddenorg > <mailto:address@hiddenorg <mailto:address@hiddenorg >>> wrote:
Just confirm that's what I had. Making a full successful backup makes it run fine without password prompt on subsequent runs.>
> On 24.05.2017 11 <tel:24.05.2017%2011> <tel:24.05.2017%2011>:28, Raphael Bauduin via Duplicity-talk wrote:
> > Hi,
> >
> > I had encrypted backups working fine for weeks on a server. As the encryption uses the public key, it doesn't ask for a password.
> >
> > Then I did a duplicity verify, which requires the gpg private key, and asks for a password.
> > The verify went fine, but since then the gpg key password is also asked for backups, preventing the automation.... I'm nearly sure this is linked
> >
> > I have removed the duplicity cache in ~/.cache/duplicity, but to no avail....
> >
> > Any suggestion?
> >
>
> 1.
> are you using duply?
>
>
> no
>
>
>
> 2.
> what is your backup command line?
>
>
> LC_ALL=en_US /bin/duplicity inc --encrypt-key 'XXXX' --exclude /root/.cache/duplicity --exclude /home/backups --exclude /home/restore --exclude /backups --include /home/sftp --include /etc --include /home --include /root --exclude '**' / par2+rsync://rsync/duplicity/ --verbosity debug
>
>
>
>
> 3.
> what's the language locale of your os?
>
>
> I'm forcing it to en_US, which worked fine.
>
> Investigating further, I think I might have deleted the cache before I did the verify. So not sure which one causes what.
> I took a look at the code. Here is the code in question asking for the password when the cache was empty, where I added a print:
> if local_missing and (rem_needpass or loc_needpass):
> if decrypt:
> # password for the --encrypt-key
> print "local_missing = %s,-- %s, -- %s" % (local_missing, rem_needpass, loc_needpass)
> globals.gpg_profile.passphrase = get_passphrase(1, "sync")
>
> local_missing was a set of .sigtar.gpg files, rem_needpass was True and loc_needpass was False.
>
> Now I have done a backup manually (providing the key password), I have the else clause below asking for the password although the action is inc:
>
> elif (action == "inc" and
> (globals.gpg_profile.recipients or globals.gpg_profile.hidden_ recipients) and not
> globals.gpg_profile.sign_key and not globals.restart):
> return ""
>
> # Finally, ask the user for the passphrase
> else:
> print "action = "" % action
> log.Info(_("PASSPHRASE variable not set, asking user."))
> use_cache = True
>
>
> globals.gpg_profile.recipients is my encryption key id, globals.gpg_profile.sign_key is None, but globals.restart= <__main__.Restart instance at 0x13a8518>
>
> So it seems that the globals.restart is set and makes the code skip the action == "inc" part.
>
> Any idea what the problem might be?
>
> Thanks
>
ok, your backup is restarting. restarting happens when a backup was interrupted. restarting _needs_ to decrypt some information from the backend, which can only be done w/ priv key and passphrase of course.
Thanks a lot for your help!
what you ran into here is essentially this bug
https://bugs.launchpad.net/duplicity/+bug/687295 <https://bugs.launchpad.net/duplicity/+bug/687295 >
consider using two key pairs in the future. duplicity using gpg can encrypt to multiple keys. place
A. a sec/pub key for the box
B. your own pub key
in your keyring. then backup against both keys and optionally use the machine key to sign your backups. this way the box can decrypt when needed w/o needing your very secret personal private key.
..ede/duply.net <http://duply.net>
[Prev in Thread] | Current Thread | [Next in Thread] |