3

I use duplicity to create symmetrically encrypted backups to some server space I get from my ISP. When creating the backups I of course set a password and when I want to restore my files, duplicity asks for that password.

What I don't understand is that when I want to see which files are backed up and I run

duplicity list-current-files ftp://user@host/BACKUP

duplicity doesn't ask for the password, but just gives my the file list.

However, when I look at the files that are in that remote location, they all end in .gpg and thus seem to be encrypted. When I download one of those files and want to open them with tar tvf it fails. I can however decrypt the file with gpg and then look at it with tar.

Why doesn't duplicity list-current-files ask for the password? Couldn't this be considered a weakness?

EDIT: I did some more testing and it seems that duplicity asks me for the password only the first time I try to list-current-files

I downloaded the archive/backup files created by duplicity on the remote server to my local machine. When I ran duplicity list-current-files file:///path/to/directory, it asked for the password. When I ran the command again, it didn't ask. When restoring the files duplicity always asks for the password.

I did the same with a newly created (local) backup and the result was the same.

Improve this question
2
  • Archives usually work like this. Similarly, you can view file list of encrypted zip archive, but to extract file, you need to give password.
    – Aria
    Jan 27, 2018 at 13:51
  • I realise zip and other archivers implement encryption this way, but if I'm not mistaken this should not apply to a tar archive which gets encrypted by gpg. I thought first the archive was created and then the resulting file gets encrypted with gpg... There should be no way to see what's inside the archive. Obviously something is going on though, where my knowledge of any of these tools seems to fail.
    – voyager
    Jan 28, 2018 at 12:23

1 Answer 1

Reset to default
4

It turns out duplicity keeps data around in ~/.cache/duplicity. These files are unencrypted manifest and signature files, but not the actual data.

I found something about this in the man page, but it only became clear to me after some further testing and looking at the cache. (See my EDIT of the question.)

So, it seems to me this doesn't represent a weakness like I originally thought.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .