Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
On Aug 1, 2017, at 11:17, edgar . soldin wrote:
> when you are doing an incremental, there is a chance that decryption is needed
> (updating the archive dir cache, resuming ...) so it will ask for the
> passphrase.

I'm running duplicity incr as a cron job, and don't want to store the encryption passphrase. I can set a bogus value for PASSPHRASE, but then duplicity spits out an error message which triggers a cron mail, flooding my mailbox and obscuring real errors. Is there a way to make duplicity not prompt for a passphrase, and instead fail with an error message if it runs into a situation that would require one? Failing that, can I somehow suppress the "GPG Failed" error message without tossing everything from stderr into /dev/null?
_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
Any ideas? Does everyone who runs duplicity incr as a cron job just
store the passphrase on disk?

On 10/03/2017 03:11 PM, Michael Gardner wrote:
> On Aug 1, 2017, at 11:17, edgar . soldin wrote:
>> when you are doing an incremental, there is a chance that decryption is needed
>> (updating the archive dir cache, resuming ...) so it will ask for the
>> passphrase.
>
> I'm running duplicity incr as a cron job, and don't want to store the encryption passphrase. I can set a bogus value for PASSPHRASE, but then duplicity spits out an error message which triggers a cron mail, flooding my mailbox and obscuring real errors. Is there a way to make duplicity not prompt for a passphrase, and instead fail with an error message if it runs into a situation that would require one? Failing that, can I somehow suppress the "GPG Failed" error message without tossing everything from stderr into /dev/null?
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
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 <[hidden email]> wrote:
>
> Any ideas? Does everyone who runs duplicity incr as a cron job just store the passphrase on disk?
>
> On 10/03/2017 03:11 PM, Michael Gardner wrote:
>> On Aug 1, 2017, at 11:17, edgar . soldin wrote:
>>> when you are doing an incremental, there is a chance that decryption is needed
>>> (updating the archive dir cache, resuming ...) so it will ask for the
>>> passphrase.
>> I'm running duplicity incr as a cron job, and don't want to store the encryption passphrase. I can set a bogus value for PASSPHRASE, but then duplicity spits out an error message which triggers a cron mail, flooding my mailbox and obscuring real errors. Is there a way to make duplicity not prompt for a passphrase, and instead fail with an error message if it runs into a situation that would require one? Failing that, can I somehow suppress the "GPG Failed" error message without tossing everything from stderr into /dev/null?
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
As mentioned earlier in the thread, the problem is that duplicity always
prompts for a passphrase even when doing incremental backups with a
valid local manifest. This makes running duplicity as a cron job very
awkward. I was hoping there was a way to force duplicity not to ask for
a passphrase, and instead die with an error if the private key would be
required.

On 10/26/2017 02:16 PM, Scott Hannahs via Duplicity-talk 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 <[hidden email]> wrote:
>>
>> Any ideas? Does everyone who runs duplicity incr as a cron job just store the passphrase on disk?
>>
>> On 10/03/2017 03:11 PM, Michael Gardner wrote:
>>> On Aug 1, 2017, at 11:17, edgar . soldin wrote:
>>>> when you are doing an incremental, there is a chance that decryption is needed
>>>> (updating the archive dir cache, resuming ...) so it will ask for the
>>>> passphrase.
>>> I'm running duplicity incr as a cron job, and don't want to store the encryption passphrase. I can set a bogus value for PASSPHRASE, but then duplicity spits out an error message which triggers a cron mail, flooding my mailbox and obscuring real errors. Is there a way to make duplicity not prompt for a passphrase, and instead fail with an error message if it runs into a situation that would require one? Failing that, can I somehow suppress the "GPG Failed" error message without tossing everything from stderr into /dev/null?
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
In reply to this post by duplicity-talk mailing list
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 <[hidden email]>"
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 <[hidden email]> 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
> > <[hidden email]> wrote:
> >
> > Any ideas? Does everyone who runs duplicity incr as a cron job just
> > store the passphrase on disk?

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
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 <[hidden email]>"
> 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 <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>
>>> Any ideas? Does everyone who runs duplicity incr as a cron job just
>>> store the passphrase on disk?
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
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" <[hidden email]> 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 <[hidden email]>" 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 <[hidden email]> 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
> >>> <[hidden email]> wrote:
> >>>
> >>> Any ideas? Does everyone who runs duplicity incr as a cron job
> >>> just store the passphrase on disk?  

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Why is duplicity asking for decryption passphrase on --encrypt-sign-key?

duplicity-talk mailing list
In reply to this post by duplicity-talk mailing list
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 <[hidden email]>"
>> 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 <[hidden email]> 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
>>>> <[hidden email]> wrote:
>>>>
>>>> Any ideas? Does everyone who runs duplicity incr as a cron job just
>>>> store the passphrase on disk?
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk