Re: [Duplicity-talk] Duplicity asking encrypt-key passphrase?

[edgar . soldin]

On 08.07.2012 20:20, Etienne Perot wrote:
> On July 8, 2012 10:49:46 address@hidden wrote:
>> On 08.07.2012 07:00, Etienne Perot wrote:
>>> Hi,
>>>
>>> I have generated 2 PGP keys, one for encryption and one for signing.
>>> Both of them are RSA/RSA keypairs, with different passphrases, different
>>> names, and different email addresses attached to them.
>>>
>>> I am running duplicity using:
>>>
>>> export SIGN_PASSPHRASE="(passphrase of signing key)"
>>> duplicity full \
>>>
>>>   --encrypt-key (key id of encryption key) \
>>>   --sign-key (key id of signing key) \
>>>   /home file:///media/home-server/backup
>>>
>>> unset SIGN_PASSPHRASE
>>>
>>> This works fine and the full bakcup is performed. No problems here.
>>>
>>> However, when I do an incremental backup using the exact same command but
>>> replacing "full" by "incremental", duplicity first says:
>>>
>>> Local and Remote metadata are synchronized, no sync needed.
>>> Last full backup date: Sat Jul  7 21:01:14 2012
>>>
>>> But duplicity doesn't exit; it then asks for a passphrase. It prompts for
>>> "GnuPG passphrase:" (as opposed to "GnuPG passphrase for signing key:"),
>>> so it is asking for the *encryption* key passphrase, not the signing key
>>> passphrase. If I give it the signing key passphrase, it fails with the
>>> error:
>>>
>>> GPGError: GPG Failed, see log below:
>>> ===== Begin GnuPG log =====
>>> gpg-agent[9188]: enabled debug flags: assuan
>>> random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
>>> outmix=0 getlvl1=0/0 getlvl2=0/0
>>> secmem usage: 384/32768 bytes in 2 blocks
>>> ===== End GnuPG log =====
>>>
>>> If on the other hand I give it the encryption key passphrase, the
>>> incremental backup works and everything goes through.
>>>
>>> My question is: why do I need to provide my encryption key passphrase?
>>> Does
>>> duplicity need to decrypt anything? I would like those backups to be
>>> unattended, and obviously I wouldn't want to store the encryption key
>>> passphrase here.
>>>
>>> I have tried the same process but using PASSPHRASE instead of
>>> SIGN_PASSPHRASE, and I have tried using both variables set. I have found
>>> the the incremental only works when PASSPHRASE is set to the encryption
>>> key's passphrase (and in those cases, it doesn't prompt for a
>>> passphrase).
>>>
>>> I am using duplicity 0.6.19 from the Arch repositories.
>>>
>>> Thanks in advance.
>>
>> hi Etienne,
>>
>> the password for the encryption key is of course always needed when a
>> decryption occurs. this is e.g. the case when
>>
>> - archive dir (local unencrypted metadata cache) needs to be updated
>> - you want to restore
>>
>> none of which "seems" to be the case here.
>>
>> but you probably stumbled over this long standing issue regarding syncing
>> the archive dir, make sure you read the mailing list thread for more
>> details. https://bugs.launchpad.net/duplicity/+bug/687295
>>
>>
> 
> Okay, so if I'm reading this right, it asks for the passphrase because it 
> needs to decrypt the manifest file so that it can check if the two 
> directories 
> are in sync. But then, why does duplicity say
> "Local and Remote metadata are synchronized, no sync needed."
> before asking for the passphrase? It seems it already knows that there's 
> nothing to do, so why ask for a passphrase after that?

can't say for sure. you would have to dig into the code to find that out.

> 
> Additionally, with this issue present, how can I achieve my initial goal 
> (unattended backups)? Do I have to store the private encryption key and its 
> passphrase on the box?

if it is really this issue try setting LANG to english as described here 
http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4251

alternatively you could of course still
a. use a specific encryption key not your private one (you could actually add 
your private one as second encryption key) and yes store the password on the 
machine. rationale is: whoever can read the password can actually fiddle with 
your data to be backed up as well as access your backup repository with the 
credentials/keys on the machine. so not having the key there actually /only/ 
prevents a hacker from finding out what data /was/ on that machine at one time 
in the past.
b. use symmetric encryption with a really strong password

..ede/duply.net