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

[Michael Gardner]

How does duplicity handle passphrases when doing multi-key encryption?

On 10/27/2017 02:43 AM, edgar.soldin--- via Duplicity-talk 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?
> >
> > _______________________________________________
> > Duplicity-talk mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk