duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Why is duplicity asking for decryption passphrase o


From: edgar . soldin
Subject: Re: [Duplicity-talk] Why is duplicity asking for decryption passphrase on --encrypt-sign-key?
Date: Fri, 27 Oct 2017 11:43:05 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

hey Felix,

two issues here.

1.
the previously possible way to "blindly" do incrementals to a backend w/o 
synchronizing first is dangerous. see
  https://lists.launchpad.net/duplicity-team/msg02374.html

2.
use the double key approach (as mentioned in the ml post above) to set up a 
safe and secure duplicity key encrypted backup w/o having to keep your personal 
key's passphrase lingering on the machine.

have fun ..ede/duply.net

PS: it should still be possible to do fulls w/o private key, but there should 
be an (non-fatal) error logged at least in recent versions of duplicity
  http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252

On 27.10.2017 07:45, Felix Fontein via Duplicity-talk wrote:
> Hi,
> 
> I've set up two GPG keys for duplicity, one is just a public key for
> encryption, and the other a public+private key pair (without password)
> for signing. This worked fine for a long time, until I upgraded
> duplicity to 0.7.14: since this version, incremental update always
> spits out error messages:
> 
> Error processing remote manifest 
> (duplicity-inc.20171025T020003Z.to.20171026T020004Z.manifest.gpg): GPG 
> Failed, see log below:
> ===== Begin GnuPG log =====
> gpg: encrypted with 4096-bit RSA key, ID xxxxxxxxxxxxx, created 20xx-xx-xx
> "XXXXX <address@hidden>"
> gpg: decryption failed: No secret key
> ===== End GnuPG log =====
> 
> (I think this is because of commit 1252:
> https://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py)
> 
> It looks like duplicity tries to compare the remote and local manifest
> (by calling check_last_manifest(), which calls
> BackupSet.check_manifests, which in turn calls
> BackupSet.get_remote_manifest(), which was modified by the above
> change). The code calling check_last_manifest():
> 
>   if not globals.restart:
>     # only ask for a passphrase if there was a previous backup
>     if col_stats.all_backup_chains:
>       globals.gpg_profile.passphrase = get_passphrase(1, action)
>     check_last_manifest(col_stats)  # not needed for full backup
>   incremental_backup(sig_chain)
> 
> This seems to be the same place which also asks for the passphrase. And
> also for me, getting this error (which results in an email by cron) for
> every incremental backup is really annoying.
> 
> Why does duplicity actually try to compare the latest local manifest to
> its remote version? If it wouldn't do that, neither the passphrase nor
> a private encryption key would be necessary.
> 
> Cheers,
> Felix
> 
> 
> 
> On Thu, 26 Oct 2017 17:16:07 -0400
> Scott Hannahs via Duplicity-talk <address@hidden> wrote:
> 
>> No there is no need to store a passphrase on the disk.  Make a key
>> specifically for encrypting  duplicity backups.  Then the public key
>> can be used for encrypting the backups without need of a passphrase.
>> Unless the local manifest gets corrupted and a new manifest has to be
>> downloaded and decrypted you should not need the private key for
>> backups either incremental or full.
>>> On Oct 26, 2017, at 3:30 PM, Michael Gardner via Duplicity-talk
>>> <address@hidden> wrote:
>>>
>>> Any ideas? Does everyone who runs duplicity incr as a cron job just
>>> store the passphrase on disk?
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]