Discussion:
remove-all-inc-of-but-n-full <num> and decryption
(too old to reply)
Dirk-Willem van Gulik
2015-10-28 17:06:57 UTC
Permalink
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup require the decryption key (while the basic info needed seems accessible to flags like collection-status without such key) ?

Much appreciated,

Dw
Kenneth Loafman
2015-10-29 11:41:10 UTC
Permalink
The newest versions do not. What version are you running?

...Ken


On Wed, Oct 28, 2015 at 12:06 PM, Dirk-Willem van Gulik <
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’
et.al. flags of a pub-key-ed backup require the decryption key (while the
basic info needed seems accessible to flags like collection-status without
such key) ?
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Dirk-Willem van Gulik
2015-10-29 11:57:24 UTC
Permalink
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to the 7.05 — nothing springs out in the release messages.

Dw
Post by Kenneth Loafman
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup require the decryption key (while the basic info needed seems accessible to flags like collection-status without such key) ?
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Dirk-Willem van Gulik
2015-10-29 12:02:37 UTC
Permalink
Post by Dirk-Willem van Gulik
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to the 7.05 — nothing springs out in the release messages.
No joy on 7.05

$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
pexpect+sftp://***@xxx.xxx.xxx
Synchronizing remote metadata to local cache..
GnuPG passphrase: …
ctrl-C
$

which version should I go to ?
Post by Dirk-Willem van Gulik
Dw
Post by Kenneth Loafman
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup require the decryption key (while the basic info needed seems accessible to flags like collection-status without such key) ?
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Kenneth Loafman
2015-10-29 13:26:20 UTC
Permalink
Is backup-xs-key set up without a passphrase?

Can you ssh into the target manually?
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to
the 7.05 — nothing springs out in the release messages.
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
Synchronizing remote metadata to local cache..
GnuPG passphrase: 

ctrl-C
$
which version should I go to ?
Dw
Post by Kenneth Loafman
On Wed, Oct 28, 2015 at 12:06 PM, Dirk-Willem van Gulik <
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’
et.al. flags of a pub-key-ed backup require the decryption key (while the
basic info needed seems accessible to flags like collection-status without
such key) ?
Post by Kenneth Loafman
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Dirk-Willem van Gulik
2015-10-29 15:31:26 UTC
Permalink
Yes, absolutely. This is in a long fuctioning tower of Hanoi incr/full dump setup.

To which we now want to add auto cleanup of ancient dumps/superseded incrementals. With as little credentials as possible.

Note the prompt for a gpg password.

Dw.
Post by Kenneth Loafman
Is backup-xs-key set up without a passphrase?
Can you ssh into the target manually?
Post by Dirk-Willem van Gulik
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to the 7.05 — nothing springs out in the release messages.
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
Synchronizing remote metadata to local cache..
GnuPG passphrase: 

ctrl-C
$
which version should I go to ?
Dw
Post by Kenneth Loafman
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup require the decryption key (while the basic info needed seems accessible to flags like collection-status without such key) ?
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Kenneth Loafman
2015-10-30 15:27:14 UTC
Permalink
Being dense, sorry!

Whenever you see *Synchronizing remote metadata to local cache*, duplicity
is going to need your passphrase in order to decrypt the manifest. It's
encrypted on the remote, but not on local, so the local copy has to be
decrypted.

...Ken




On Thu, Oct 29, 2015 at 10:31 AM, Dirk-Willem van Gulik <
Post by Dirk-Willem van Gulik
Yes, absolutely. This is in a long fuctioning tower of Hanoi incr/full dump setup.
To which we now want to add auto cleanup of ancient dumps/superseded
incrementals. With as little credentials as possible.
Note the prompt for a gpg password.
Dw.
Is backup-xs-key set up without a passphrase?
Can you ssh into the target manually?
On Thu, Oct 29, 2015 at 7:02 AM, Dirk-Willem van Gulik <
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to
the 7.05 — nothing springs out in the release messages.
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
Synchronizing remote metadata to local cache..
GnuPG passphrase: 

ctrl-C
$
which version should I go to ?
Dw
Post by Kenneth Loafman
On Wed, Oct 28, 2015 at 12:06 PM, Dirk-Willem van Gulik <
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’
et.al. flags of a pub-key-ed backup require the decryption key (while
the basic info needed seems accessible to flags like collection-status
without such key) ?
Post by Kenneth Loafman
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Scott Hannahs
2015-10-30 19:07:04 UTC
Permalink
The REMOTE copy has to be decrypted. Right?

That is the encrypted copy to compare in an unencrypted state with the local copy. Or am I really confused.

Or could the local copy be encrypted (without password using public key) and then compare local encrypted copy with remote encrypted copy and only need the key if the local did not match the remote and the remote needs to be decrypted?

-Scott
Post by Kenneth Loafman
Being dense, sorry!
Whenever you see Synchronizing remote metadata to local cache, duplicity is going to need your passphrase in order to decrypt the manifest. It's encrypted on the remote, but not on local, so the local copy has to be decrypted.
...Ken
Dirk-Willem van Gulik
2015-10-31 17:36:57 UTC
Permalink
Right - I assume you mean this the other way round ? Remote encrypted, local copy not.

What I am trying to understand — I am trying to clean up the all-inc-but-n “from” the local. And was sort of hoping that would not require access to the private key used (which is in fact kept off-line).

I noted that if I do a normal "collection-status” — one gets pretty much exactly the info you need to do such a cleanup.

So i am a bit confused as to why this needs access to the GPG private key.

Thanks,

Dw.
Post by Kenneth Loafman
Being dense, sorry!
Whenever you see Synchronizing remote metadata to local cache, duplicity is going to need your passphrase in order to decrypt the manifest. It's encrypted on the remote, but not on local, so the local copy has to be decrypted.
...Ken
Yes, absolutely. This is in a long fuctioning tower of Hanoi incr/full dump setup.
To which we now want to add auto cleanup of ancient dumps/superseded incrementals. With as little credentials as possible.
Note the prompt for a gpg password.
Dw.
Post by Kenneth Loafman
Is backup-xs-key set up without a passphrase?
Can you ssh into the target manually?
Post by Dirk-Willem van Gulik
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to the 7.05 — nothing springs out in the release messages.
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
Synchronizing remote metadata to local cache..
GnuPG passphrase: …
ctrl-C
$
which version should I go to ?
Post by Dirk-Willem van Gulik
Dw
Post by Kenneth Loafman
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup require the decryption key (while the basic info needed seems accessible to flags like collection-status without such key) ?
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Kenneth Loafman
2015-11-01 12:12:21 UTC
Permalink
Collection-status does not make any changes to the collection. Right now,
any command that changes the collection causes a sync of local and remote
metadata, which causes a need for the key to unlock the remote metadata for
comparison.

At some point that will be fixed, but not soon.


On Sat, Oct 31, 2015 at 12:36 PM, Dirk-Willem van Gulik <
Post by Dirk-Willem van Gulik
Right - I assume you mean this the other way round ? Remote encrypted, local copy not.
What I am trying to understand — I am trying to clean up the all-inc-but-n
“from” the local. And was sort of hoping that would not require access to
the private key used (which is in fact kept off-line).
I noted that if I do a normal "collection-status” — one gets pretty much
exactly the info you need to do such a cleanup.
So i am a bit confused as to why this needs access to the GPG private key.
Thanks,
Dw.
Post by Kenneth Loafman
Being dense, sorry!
Whenever you see Synchronizing remote metadata to local cache, duplicity
is going to need your passphrase in order to decrypt the manifest. It's
encrypted on the remote, but not on local, so the local copy has to be
decrypted.
Post by Kenneth Loafman
...Ken
On Thu, Oct 29, 2015 at 10:31 AM, Dirk-Willem van Gulik <
Yes, absolutely. This is in a long fuctioning tower of Hanoi incr/full
dump setup.
Post by Kenneth Loafman
To which we now want to add auto cleanup of ancient dumps/superseded
incrementals. With as little credentials as possible.
Post by Kenneth Loafman
Note the prompt for a gpg password.
Dw.
Post by Kenneth Loafman
Is backup-xs-key set up without a passphrase?
Can you ssh into the target manually?
On Thu, Oct 29, 2015 at 7:02 AM, Dirk-Willem van Gulik <
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going
to the 7.05 — nothing springs out in the release messages.
Post by Kenneth Loafman
Post by Kenneth Loafman
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
Synchronizing remote metadata to local cache..
GnuPG passphrase: 

ctrl-C
$
which version should I go to ?
Dw
Post by Kenneth Loafman
On Wed, Oct 28, 2015 at 12:06 PM, Dirk-Willem van Gulik <
Can someone help me understand why the
‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup
require the decryption key (while the basic info needed seems accessible to
flags like collection-status without such key) ?
Post by Kenneth Loafman
Post by Kenneth Loafman
Post by Kenneth Loafman
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Dirk-Willem van Gulik
2015-11-08 13:24:37 UTC
Permalink
Ok - clear. I was sort of hoping the comparison to the accuracy of the collection data would by by something like a signed signature (so you know source and destination are in sync) — after which you can do it from the source side its ‘in the clear copy' ‘safely’ without needing to have a private key involved in the safe purging of (old) backups. (As I sort of need to give duplicity credentials that on sftp level already allow that environment to ‘corrupt’ my backups).

Dw.
Collection-status does not make any changes to the collection. Right now, any command that changes the collection causes a sync of local and remote metadata, which causes a need for the key to unlock the remote metadata for comparison.
At some point that will be fixed, but not soon.
Right - I assume you mean this the other way round ? Remote encrypted, local copy not.
What I am trying to understand — I am trying to clean up the all-inc-but-n “from” the local. And was sort of hoping that would not require access to the private key used (which is in fact kept off-line).
I noted that if I do a normal "collection-status” — one gets pretty much exactly the info you need to do such a cleanup.
So i am a bit confused as to why this needs access to the GPG private key.
Thanks,
Dw.
Post by Kenneth Loafman
Being dense, sorry!
Whenever you see Synchronizing remote metadata to local cache, duplicity is going to need your passphrase in order to decrypt the manifest. It's encrypted on the remote, but not on local, so the local copy has to be decrypted.
...Ken
Yes, absolutely. This is in a long fuctioning tower of Hanoi incr/full dump setup.
To which we now want to add auto cleanup of ancient dumps/superseded incrementals. With as little credentials as possible.
Note the prompt for a gpg password.
Dw.
Post by Kenneth Loafman
Is backup-xs-key set up without a passphrase?
Can you ssh into the target manually?
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going to the 7.05 — nothing springs out in the release messages.
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key” \
Synchronizing remote metadata to local cache..
GnuPG passphrase: 

ctrl-C
$
which version should I go to ?
Dw
Post by Kenneth Loafman
Can someone help me understand why the ‘remove-all-inc-of-but-n-full’ et.al <http://et.al/>. flags of a pub-key-ed backup require the decryption key (while the basic info needed seems accessible to flags like collection-status without such key) ?
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Kenneth Loafman
2015-11-08 16:21:38 UTC
Permalink
Could you explain "*As I sort of need to give duplicity credentials that on
sftp level already allow that environment to ‘corrupt’ my backups.*"? I
seem to be dense today.

...Ken
Post by Dirk-Willem van Gulik
Ok - clear. I was sort of hoping the comparison to the accuracy of the
collection data would by by something like a signed signature (so you know
source and destination are in sync) — after which you can do it from the
source side its ‘in the clear copy' ‘safely’ without needing to have a
private key involved in the safe purging of (old) backups. (As I sort of
need to give duplicity credentials that on sftp level already allow that
environment to ‘corrupt’ my backups).
Dw.
Collection-status does not make any changes to the collection. Right now,
any command that changes the collection causes a sync of local and remote
metadata, which causes a need for the key to unlock the remote metadata for
comparison.
At some point that will be fixed, but not soon.
On Sat, Oct 31, 2015 at 12:36 PM, Dirk-Willem van Gulik <
Post by Dirk-Willem van Gulik
Right - I assume you mean this the other way round ? Remote encrypted, local copy not.
What I am trying to understand — I am trying to clean up the
all-inc-but-n “from” the local. And was sort of hoping that would not
require access to the private key used (which is in fact kept off-line).
I noted that if I do a normal "collection-status” — one gets pretty much
exactly the info you need to do such a cleanup.
So i am a bit confused as to why this needs access to the GPG private key.
Thanks,
Dw.
Post by Kenneth Loafman
Being dense, sorry!
Whenever you see Synchronizing remote metadata to local cache,
duplicity is going to need your passphrase in order to decrypt the
manifest. It's encrypted on the remote, but not on local, so the local
copy has to be decrypted.
Post by Kenneth Loafman
...Ken
On Thu, Oct 29, 2015 at 10:31 AM, Dirk-Willem van Gulik <
Yes, absolutely. This is in a long fuctioning tower of Hanoi incr/full
dump setup.
Post by Kenneth Loafman
To which we now want to add auto cleanup of ancient dumps/superseded
incrementals. With as little credentials as possible.
Post by Kenneth Loafman
Note the prompt for a gpg password.
Dw.
Post by Kenneth Loafman
Is backup-xs-key set up without a passphrase?
Can you ssh into the target manually?
On Thu, Oct 29, 2015 at 7:02 AM, Dirk-Willem van Gulik <
On 29 Oct 2015, at 12:57, Dirk-Willem van Gulik <
Post by Kenneth Loafman
The newest versions do not. What version are you running?
the ‘un’stable branch: duplicity 0.7.02 under python 7. Worth going
to the 7.05 — nothing springs out in the release messages.
Post by Kenneth Loafman
Post by Kenneth Loafman
No joy on 7.05
$/usr/local/bin/python2.7 /usr/local/bin/duplicity-7.05 \
remove-all-inc-of-but-n-full 2 \
--ssh-options "-oIdentityFile=/home/backup-xxx/backup-xs-key”
\
Post by Kenneth Loafman
Post by Kenneth Loafman
Synchronizing remote metadata to local cache..
GnuPG passphrase: 

ctrl-C
$
which version should I go to ?
Dw
Post by Kenneth Loafman
On Wed, Oct 28, 2015 at 12:06 PM, Dirk-Willem van Gulik <
Can someone help me understand why the
‘remove-all-inc-of-but-n-full’ et.al. flags of a pub-key-ed backup
require the decryption key (while the basic info needed seems accessible to
flags like collection-status without such key) ?
Post by Kenneth Loafman
Post by Kenneth Loafman
Post by Kenneth Loafman
Much appreciated,
Dw
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Dirk-Willem van Gulik
2015-11-08 18:13:35 UTC
Permalink
Could you explain "As I sort of need to give duplicity credentials that on sftp level already allow that environment to ‘corrupt’ my backups."? I seem to be dense today.
So a nice property of duplicity is that it can (largely) operate with just a public key for backups.

That means you can keep the corresponding private key ‘offline’ and only break into it during a restore. This significantly reduces the footprint & risks around backups. And makes a lot of threatmodel around remote servers & cloud/hosted situations simpler.

Now obviously duplicity will need a fair bit of credentials on the servers it is backing up - at the very least enough to read (though not modify) the files & directories it is backing up. And it will need some credentials sufficient to ’sftp’ (or similar) to the storage systems that allow the creation & writing of files.

In actual practice that means that in a lot of situations duplicity can also ‘corrupt’ its own backup. Because of a adversary has gotten sufficient control over it or its environment -or- because of a simple bug in the code.

Hence allowing duplicity to delete (old) backups with just the public key is not that much of a weakening of the security situation; and will not change the risk- and threatmodel much, if at all.

Does that help ?

Dw

Loading...