backup without private key

[edso]

Read more here

http://thread.gmane.org/gmane.comp.sysutils.backup.duplicity.general/4245

Summary is:

currently this works only on english systems by silently ignoring the absence of the secret key for archive-dir comparision.

short term Solution might be:

a language independent (gpg --status-fd) catching of the error
a parameter switch (e.g. --no-secret-key) with proper documentation about the pros & cons

long term Solution should be:

a hashing comparision of remote and local archive-dir circumventing the need for decryption

more info is found on the thread linked above
[Duplicity-talk] duplicity incr - private key missing

..ede/duply.net

[Dirk (f-launchpad-20-dirk-eschbach)]

It is correct INC backup without the private key is not working for me as well.

This makes me wonder why bother to have the --encrypt-key and --sign-key option.
Thsi would be an excellent setup to protect the encryption of the backup making sure backup private key is never exposed and haveing a second signing key which in worst will be compromised.
The Privacy of the Backup however would be granted.

I would be thrilled if the above discribed solution (hashing) could be implemented.

[Tim Ruffing (8-public)]

As I'm also affected, I'd be happy to contribute a patch for the solution with the hash. However, I'm not totally sure if I understand everything correctly on the mailing list.
 - I assume that it suffices to store a hash of the manifest file locally. Am I right?
 - Is adding a LOCAL file with the hash in the cache directory really invasive, i.e., would it involve changes in other parts of the code or break backwards compatibility? If the local file is not there, we could easily fall back to the current implementation.
 - If adding a local file is invasive, maybe adding the hash value to the local filename could be a neat trick (might be simpler than a hash neutral line).

btw, the link above is broken. This is the discussion on the list: https://lists.nongnu.org/archive/html/duplicity-talk/2010-12/msg00004.html

[edso (ed.so)]

On 14.09.2013 11:56, Tim Ruffing wrote:
> As I'm also affected, I'd be happy to contribute a patch for the solution with the hash. However, I'm not totally sure if I understand everything correctly on the mailing list.
> - I assume that it suffices to store a hash of the manifest file locally. Am I right?

actually we would need a relation of two hashes, as Ken wrote:

>> A a hash of an encrypted form of the local manifest compared to a hash of
>> the remote manifest might be the way to go on this.

> - Is adding a LOCAL file with the hash in the cache directory really invasive, i.e., would it involve changes in other parts of the code or break backwards compatibility? If the local file is not there, we could easily fall back to the current implementation.

works for me.. maybe one text file per backup chain (full,inc0,inc1....) with lines per file

> - If adding a local file is invasive, maybe adding the hash value to the local filename could be a neat trick (might be simpler than a hash neutral line).

too much hassle and not backward compatible

eventually not only the manifest, but also the other remote files should be compared to ensure the integrity of the remote/local files to be used as basis of the new incremental.

..ede/duply.net

[Martin Nowak (dawgfoto)]

Related merge proposal https://code.launchpad.net/~dawgfoto/duplicity/fixup1252.

[Martin Nowak (dawgfoto)]

https://code.launchpad.net/~dawgfoto/duplicity/fixup1252/+merge/343816

[edso (ed.so)]

hey Ken,

can you explain in a few words, how this is fixed now? i am not sure i read the code correctly.

is the manifest now compared or only sometimes or ?

thx.. ede/duply.net

[Kenneth Loafman (kenneth-loafman)]

The code bypasses the check if encryption is on, regardless of the
availability of the private key. Not a good fix, but it really won't
matter. Version 0.8.0 will have a separate file with a list of file hashes
for both local and remote, so it won't matter. Right now, we check the
manifest and the difftar. I plan to check everything.

On Tue, May 1, 2018 at 11:30 AM, edso <email address hidden> wrote:

> hey Ken,
>
> can you explain in a few words, how this is fixed now? i am not sure i
> read the code correctly.
>
> is the manifest now compared or only sometimes or ?
>
> thx.. ede/duply.net
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/687295
>
> Title:
> backup without private key
>
> Status in Duplicity:
> Fix Committed
>
> Bug description:
> Read more here
>
> http://thread.gmane.org/gmane.comp.sysutils.backup.
> duplicity.general/4245
>
> Summary is:
>
> currently this works only on english systems by silently ignoring the
> absence of the secret key for archive-dir comparision.
>
> short term Solution might be:
>
> a language independent (gpg --status-fd) catching of the error
> a parameter switch (e.g. --no-secret-key) with proper documentation
> about the pros & cons
>
> long term Solution should be:
>
> a hashing comparision of remote and local archive-dir circumventing
> the need for decryption
>
> more info is found on the thread linked above
> [Duplicity-talk] duplicity incr - private key missing
>
> ..ede/duply.net
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/687295/+subscriptions
>

[edso (ed.so)]

Ken,

On 01.05.2018 20:35, Kenneth Loafman wrote:
> Version 0.8.0 will have a separate file with a list of file hashes
> for both local and remote, so it won't matter. Right now, we check the
> manifest and the difftar. I plan to check everything.

how do you plan to protect said hash list against corruption/modification ? signing?

..ede/duply.net

[Kenneth Loafman (kenneth-loafman)]

Not sure yet. Looks like our users want to do everything without a private
key, so I'll probably just put it in the manifest db and be done with it.
Without the private key it will just have to be in plain text. They
probably don't even want the private sign key to be available.

On Wed, May 2, 2018 at 8:45 AM, edso <email address hidden> wrote:

> Ken,
>
> On 01.05.2018 20:35, Kenneth Loafman wrote:
> > Version 0.8.0 will have a separate file with a list of file hashes
> > for both local and remote, so it won't matter. Right now, we check the
> > manifest and the difftar. I plan to check everything.
>
> how do you plan to protect said hash list against
> corruption/modification ? signing?
>
> ..ede/duply.net
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/687295
>
> Title:
> backup without private key
>
> Status in Duplicity:
> Fix Committed
>
> Bug description:
> Read more here
>
> http://thread.gmane.org/gmane.comp.sysutils.backup.
> duplicity.general/4245
>
> Summary is:
>
> currently this works only on english systems by silently ignoring the
> absence of the secret key for archive-dir comparision.
>
> short term Solution might be:
>
> a language independent (gpg --status-fd) catching of the error
> a parameter switch (e.g. --no-secret-key) with proper documentation
> about the pros & cons
>
> long term Solution should be:
>
> a hashing comparision of remote and local archive-dir circumventing
> the need for decryption
>
> more info is found on the thread linked above
> [Duplicity-talk] duplicity incr - private key missing
>
> ..ede/duply.net
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/687295/+subscriptions
>

[edso (ed.so)]

On 02.05.2018 16:58, Kenneth Loafman wrote:
> Not sure yet. Looks like our users want to do everything without a private
> key, so I'll probably just put it in the manifest db and be done with it.
> Without the private key it will just have to be in plain text. They
> probably don't even want the private sign key to be available.
>

ok, what the check was for is to check if the current local manifest is still the latest before doing an incremental on that. earlier in thread there is the suggestion to keep a local hash of the uploaded (possibly encrypted) manifest file.

comparing this hash against a freshly fetched (possibly encrypted) manifest from the backend would show if there is difference or not signaling the ok to go for a new incremental.

hash comparisons of other files would need the download of those, so i'd say let's not do so (bandwidth efficiency). if users want to find out the health of the chain they can verify it as well.

..ede/duply.net

[Kenneth Loafman (kenneth-loafman)]

OK, I was too general.

Like the difftar files, they would not be verified unless they were
downloaded normally.

On Wed, May 2, 2018 at 10:45 AM, edso <email address hidden> wrote:

> On 02.05.2018 16:58, Kenneth Loafman wrote:
> > Not sure yet. Looks like our users want to do everything without a
> private
> > key, so I'll probably just put it in the manifest db and be done with it.
> > Without the private key it will just have to be in plain text. They
> > probably don't even want the private sign key to be available.
> >
>
> ok, what the check was for is to check if the current local manifest is
> still the latest before doing an incremental on that. earlier in thread
> there is the suggestion to keep a local hash of the uploaded (possibly
> encrypted) manifest file.
>
> comparing this hash against a freshly fetched (possibly encrypted)
> manifest from the backend would show if there is difference or not
> signaling the ok to go for a new incremental.
>
> hash comparisons of other files would need the download of those, so i'd
> say let's not do so (bandwidth efficiency). if users want to find out
> the health of the chain they can verify it as well.
>
> ..ede/duply.net
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/687295
>
> Title:
> backup without private key
>
> Status in Duplicity:
> Fix Committed
>
> Bug description:
> Read more here
>
> http://thread.gmane.org/gmane.comp.sysutils.backup.
> duplicity.general/4245
>
> Summary is:
>
> currently this works only on english systems by silently ignoring the
> absence of the secret key for archive-dir comparision.
>
> short term Solution might be:
>
> a language independent (gpg --status-fd) catching of the error
> a parameter switch (e.g. --no-secret-key) with proper documentation
> about the pros & cons
>
> long term Solution should be:
>
> a hashing comparision of remote and local archive-dir circumventing
> the need for decryption
>
> more info is found on the thread linked above
> [Duplicity-talk] duplicity incr - private key missing
>
> ..ede/duply.net
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/687295/+subscriptions
>