Re: [Duplicity-talk] Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

[Felix Fontein]

Hi Edgar,

thanks a lot for your reply! I guess I'll use the double key approach
then.

Cheers,
Felix




On Fri, 27 Oct 2017 11:43:05 +0200
"edgar.soldin--- via Duplicity-talk" <address@hidden> wrote:

> 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?