Merge lp:~mturquette/duplicity/duplicity into lp:~duplicity-team/duplicity/0.7-series

[Michael Turquette]

I ran into a problem while using duplicity on my laptop, where I store my public gpg key, but not my private key. This is because my laptop may be stolen, lost or otherwise detained.

I still want to encrypt backups, which I can do sufficiently with a public key and Duplicity does this just fine. But things fall apart when Duplicity tries to decrypt the first volume of the backup in validate_encryption_settings() and fails on my laptop due to the lack of private key.

To handle this case I have introduced the --no-secret-key option, which was first proposed on the list in 2010:
http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299

This option simply skips the encryption settings validation if set. The responsibility is on the user to periodically sanity check backups.

[edso (ed.so)]

On 26.08.2014 03:28, Mike Turquette wrote:
> Mike Turquette has proposed merging lp:~mturquette/duplicity/duplicity into lp:duplicity.
>
> Requested reviews:
> duplicity-team (duplicity-team)
>
> For more details, see:
> https://code.launchpad.net/~mturquette/duplicity/duplicity/+merge/232153
>
> I ran into a problem while using duplicity on my laptop, where I store my public gpg key, but not my private key. This is because my laptop may be stolen, lost or otherwise detained.
>
> I still want to encrypt backups, which I can do sufficiently with a public key and Duplicity does this just fine. But things fall apart when Duplicity tries to decrypt the first volume of the backup in validate_encryption_settings() and fails on my laptop due to the lack of private key.
>
> To handle this case I have introduced the --no-secret-key option, which was first proposed on the list in 2010:
> http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299

if you read the thread more thorough you'll see that the switch was meant for a totally different point in the code. the sanity decode routine was not introduced at that time.

>
> This option simply skips the encryption settings validation if set. The responsibility is on the user to periodically sanity check backups.
>

it also seems to disable the "was backup (un)encrypted before and is still check" in line 330

so i see these problems:

- collections.py must be patched as well, as drafted in the ml thread above
- the manpage bin/duplicity.1 has to be updated with a proper explanation of the parameter and it's dangers
- only disable the decryption trial in validate_encryption_settings()

make sure that you deliver a patch for lp:duplicity , which is the new current developing branch for an upcoming duplicity 0.7

..ede/duply.net

[edso (ed.so)]

review: Needs Fixing

[Michael Turquette (mturquette)]

On Tue, Aug 26, 2014 at 2:33 AM, edso <email address hidden> wrote:
> On 26.08.2014 03:28, Mike Turquette wrote:
>> Mike Turquette has proposed merging lp:~mturquette/duplicity/duplicity into lp:duplicity.
>>
>> Requested reviews:
>> duplicity-team (duplicity-team)
>>
>> For more details, see:
>> https://code.launchpad.net/~mturquette/duplicity/duplicity/+merge/232153
>>
>> I ran into a problem while using duplicity on my laptop, where I store my public gpg key, but not my private key. This is because my laptop may be stolen, lost or otherwise detained.
>>
>> I still want to encrypt backups, which I can do sufficiently with a public key and Duplicity does this just fine. But things fall apart when Duplicity tries to decrypt the first volume of the backup in validate_encryption_settings() and fails on my laptop due to the lack of private key.
>>
>> To handle this case I have introduced the --no-secret-key option, which was first proposed on the list in 2010:
>> http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299
>
>
> if you read the thread more thorough you'll see that the switch was meant for a totally different point in the code. the sanity decode routine was not introduced at that time.
>
>>
>> This option simply skips the encryption settings validation if set. The responsibility is on the user to periodically sanity check backups.
>>
>
> it also seems to disable the "was backup (un)encrypted before and is still check" in line 330
>
> so i see these problems:
>
> - collections.py must be patched as well, as drafted in the ml thread above
> - the manpage bin/duplicity.1 has to be updated with a proper explanation of the parameter and it's dangers
> - only disable the decryption trial in validate_encryption_settings()

Edgar,

Thanks for reviewing and for providing more context and pointers.

>
> make sure that you deliver a patch for lp:duplicity , which is the new current developing branch for an upcoming duplicity 0.7

My itch is scratched so I likely won't be revisiting this code any
time soon, if ever. However if I do decide to refresh this fix (e.g.
after my distro pulls a new, unpatched version of duplicity and I hit
this bug agin) then I will address your points and resubmit.

Thanks!
Mike

>
> ..ede/duply.net
>
> --
> https://code.launchpad.net/~mturquette/duplicity/duplicity/+merge/232153
> You are the owner of lp:~mturquette/duplicity/duplicity.

[edso (ed.so)]

On 26.08.2014 22:42, Mike Turquette wrote:
> On Tue, Aug 26, 2014 at 2:33 AM, edso <email address hidden> wrote:
>> On 26.08.2014 03:28, Mike Turquette wrote:
>>> Mike Turquette has proposed merging lp:~mturquette/duplicity/duplicity into lp:duplicity.
>>>
>>> Requested reviews:
>>> duplicity-team (duplicity-team)
>>>
>>> For more details, see:
>>> https://code.launchpad.net/~mturquette/duplicity/duplicity/+merge/232153
>>>
>>> I ran into a problem while using duplicity on my laptop, where I store my public gpg key, but not my private key. This is because my laptop may be stolen, lost or otherwise detained.
>>>
>>> I still want to encrypt backups, which I can do sufficiently with a public key and Duplicity does this just fine. But things fall apart when Duplicity tries to decrypt the first volume of the backup in validate_encryption_settings() and fails on my laptop due to the lack of private key.
>>>
>>> To handle this case I have introduced the --no-secret-key option, which was first proposed on the list in 2010:
>>> http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299
>>
>>
>> if you read the thread more thorough you'll see that the switch was meant for a totally different point in the code. the sanity decode routine was not introduced at that time.
>>
>>>
>>> This option simply skips the encryption settings validation if set. The responsibility is on the user to periodically sanity check backups.
>>>
>>
>> it also seems to disable the "was backup (un)encrypted before and is still check" in line 330
>>
>> so i see these problems:
>>
>> - collections.py must be patched as well, as drafted in the ml thread above
>> - the manpage bin/duplicity.1 has to be updated with a proper explanation of the parameter and it's dangers
>> - only disable the decryption trial in validate_encryption_settings()
>
> Edgar,
>
> Thanks for reviewing and for providing more context and pointers.
>
>>
>> make sure that you deliver a patch for lp:duplicity , which is the new current developing branch for an upcoming duplicity 0.7
>
> My itch is scratched so I likely won't be revisiting this code any
> time soon, if ever. However if I do decide to refresh this fix (e.g.
> after my distro pulls a new, unpatched version of duplicity and I hit
> this bug agin) then I will address your points and resubmit.
>

up to you. hope you will as dev time on duplicity is rather sparse these days. ..ede/duply.net

[edso (ed.so)]

On 26.08.2014 22:42, Mike Turquette wrote:
> On Tue, Aug 26, 2014 at 2:33 AM, edso <email address hidden> wrote:
>> On 26.08.2014 03:28, Mike Turquette wrote:
>>> Mike Turquette has proposed merging lp:~mturquette/duplicity/duplicity into lp:duplicity.
>>>
>>> Requested reviews:
>>> duplicity-team (duplicity-team)
>>>
>>> For more details, see:
>>> https://code.launchpad.net/~mturquette/duplicity/duplicity/+merge/232153
>>>
>>> I ran into a problem while using duplicity on my laptop, where I store my public gpg key, but not my private key. This is because my laptop may be stolen, lost or otherwise detained.
>>>
>>> I still want to encrypt backups, which I can do sufficiently with a public key and Duplicity does this just fine. But things fall apart when Duplicity tries to decrypt the first volume of the backup in validate_encryption_settings() and fails on my laptop due to the lack of private key.
>>>
>>> To handle this case I have introduced the --no-secret-key option, which was first proposed on the list in 2010:
>>> http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299
>>
>>
>> if you read the thread more thorough you'll see that the switch was meant for a totally different point in the code. the sanity decode routine was not introduced at that time.
>>
>>>
>>> This option simply skips the encryption settings validation if set. The responsibility is on the user to periodically sanity check backups.
>>>
>>
>> it also seems to disable the "was backup (un)encrypted before and is still check" in line 330
>>
>> so i see these problems:
>>
>> - collections.py must be patched as well, as drafted in the ml thread above
>> - the manpage bin/duplicity.1 has to be updated with a proper explanation of the parameter and it's dangers
>> - only disable the decryption trial in validate_encryption_settings()
>
> Edgar,
>
> Thanks for reviewing and for providing more context and pointers.
>
>>
>> make sure that you deliver a patch for lp:duplicity , which is the new current developing branch for an upcoming duplicity 0.7
>
> My itch is scratched so I likely won't be revisiting this code any
> time soon, if ever. However if I do decide to refresh this fix (e.g.
> after my distro pulls a new, unpatched version of duplicity and I hit
> this bug agin) then I will address your points and resubmit.
>

btw. current suggested method to protect your private key is to use a machine specific keypair plus your own public key. encrypt against the machine and your public key, sign with the passwordless machine secret key.

..ede/duply.net

[Michael Turquette (mturquette)]

Quoting edso (2014-08-27 01:54:20)
> On 26.08.2014 22:42, Mike Turquette wrote:
> > On Tue, Aug 26, 2014 at 2:33 AM, edso <email address hidden> wrote:
> >> On 26.08.2014 03:28, Mike Turquette wrote:
> >>> Mike Turquette has proposed merging lp:~mturquette/duplicity/duplicity into lp:duplicity.
> >>>
> >>> Requested reviews:
> >>> duplicity-team (duplicity-team)
> >>>
> >>> For more details, see:
> >>> https://code.launchpad.net/~mturquette/duplicity/duplicity/+merge/232153
> >>>
> >>> I ran into a problem while using duplicity on my laptop, where I store my public gpg key, but not my private key. This is because my laptop may be stolen, lost or otherwise detained.
> >>>
> >>> I still want to encrypt backups, which I can do sufficiently with a public key and Duplicity does this just fine. But things fall apart when Duplicity tries to decrypt the first volume of the backup in validate_encryption_settings() and fails on my laptop due to the lack of private key.
> >>>
> >>> To handle this case I have introduced the --no-secret-key option, which was first proposed on the list in 2010:
> >>> http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299
> >>
> >>
> >> if you read the thread more thorough you'll see that the switch was meant for a totally different point in the code. the sanity decode routine was not introduced at that time.
> >>
> >>>
> >>> This option simply skips the encryption settings validation if set. The responsibility is on the user to periodically sanity check backups.
> >>>
> >>
> >> it also seems to disable the "was backup (un)encrypted before and is still check" in line 330
> >>
> >> so i see these problems:
> >>
> >> - collections.py must be patched as well, as drafted in the ml thread above
> >> - the manpage bin/duplicity.1 has to be updated with a proper explanation of the parameter and it's dangers
> >> - only disable the decryption trial in validate_encryption_settings()
> >
> > Edgar,
> >
> > Thanks for reviewing and for providing more context and pointers.
> >
> >>
> >> make sure that you deliver a patch for lp:duplicity , which is the new current developing branch for an upcoming duplicity 0.7
> >
> > My itch is scratched so I likely won't be revisiting this code any
> > time soon, if ever. However if I do decide to refresh this fix (e.g.
> > after my distro pulls a new, unpatched version of duplicity and I hit
> > this bug agin) then I will address your points and resubmit.
> >
>
> btw. current suggested method to protect your private key is to use a machine specific keypair plus your own public key. encrypt against the machine and your public key, sign with the passwordless machine secret key.

Thanks for the info. In fact I have settled on something similar to
this, which is another reason why reworking the --no-secret-key fix is
low priority for me.

In the course of this problem I became educated on the proper use of
subkeys and so now my laptop has the public/private subkey, but only the
public keys for my primary signing key and my other subkeys which I do
not plan to use while traveling, so I'm not even using this feature
myself right now, though it did work for me at the time that I...

[Kenneth Loafman (kenneth-loafman)]

Going to mark this as rejected due to the discussion above.

review: Disapprove

[Michael Turquette (mturquette)]

Fine by me.

Unmerged revisions

990. By Michael Turquette on 2014-05-21

Introduce --no-secret-key option for the purpose of encrypting backups
with only a public key. Without this change duplicity begins a backup,
but then fails subsequent backups while trying to decrypt the first
volume. This scheme is most useful for laptops and other mobile devices
where the user does not wish to keep the secret key on disk.

This concept was first published to the list in 2010:
http://article.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4299

Signed-off-by: Mike Turquette <email address hidden>

=== modified file 'bin/duplicity'
--- bin/duplicity	2014-05-11 11:50:12 +0000
+++ bin/duplicity	2014-08-26 01:27:30 +0000
@@ -323,20 +323,22 @@
         that we're using the same encryption settings (i.e. we don't switch
         from encrypted to non in the middle of a backup chain), so we check
         that the vol1 filename on the server matches the settings of this run.
+        Skip this check if the --no-secret-key option is set.
         """
-        vol1_filename = file_naming.get(backup_type, 1,
-                                        encrypted=globals.encryption,
-                                        gzipped=globals.compression)
-        if vol1_filename != backup_set.volume_name_dict[1]:
-            log.FatalError(_("Restarting backup, but current encryption "
-                             "settings do not match original settings"),
-                           log.ErrorCode.enryption_mismatch)
+        if not globals.no_secret_key:
+            vol1_filename = file_naming.get(backup_type, 1,
+                                            encrypted=globals.encryption,
+                                            gzipped=globals.compression)
+            if vol1_filename != backup_set.volume_name_dict[1]:
+                log.FatalError(_("Restarting backup, but current encryption "
+                                 "settings do not match original settings"),
+                               log.ErrorCode.enryption_mismatch)
 
-        # Settings are same, let's check passphrase itself if we are encrypted
-        if globals.encryption:
-            fileobj = restore_get_enc_fileobj(globals.backend, vol1_filename,
-                                              manifest.volume_info_dict[1])
-            fileobj.close()
+            # Settings are same, let's check passphrase itself if we are encrypted
+            if globals.encryption:
+                fileobj = restore_get_enc_fileobj(globals.backend, vol1_filename,
+                                                  manifest.volume_info_dict[1])
+                fileobj.close()
 
     if not globals.restart:
         # normal backup start