Re: [Duplicity-talk] gpg key password asked for backup after verify

[Kenneth Loafman]

1) This was from the README for 0.7.05:

* Fix bug #1494228 CygWin: TypeError: basis_file must be a (true) file

  - The problem that caused the change to tempfile.TemporaryFile was due

    to the fact that os.tmpfile always creates its file in the system

    temp directory, not in the directory specified.  The fix applied was

    to use os.tmpfile in cygwin/windows and tempfile.TemporaryFile in all

    the rest.  This means that cygwin is now broken with respect to temp

    file placement of this one file (deleted automatically on close).

2) I'm not seeing that we ignore errors in the sync between local and remote.  That would produce bad backups if we did.

...Ken

On Mon, May 29, 2017 at 4:15 AM, edgar.soldin--- via Duplicity-talk <address@hidden> wrote:

hey Ken,

On 28.05.2017 18:48, Kenneth Loafman wrote:
> OK, let me try again:

:)

> 1) the TemporaryFile() problems in windows and cygwin have been with us for a long while and it has not been fixed in Python, yet.  The first patch that Howie suggested added darwin to that list, and that was removed by the next commit when he found the problem in _librsyncmodule.c.  I don't know how to fix the problem in Windows, so that issue should probably be handled in the man page and README.  People don't normally partition Windows the same way as Linux, so I doubt it's a real problem for most users.

can you be more specific what the issue/bug is on windows? do you have a link, bug report or such?

> 2) In my response, I outlined why we have problems when we don't have the private key.  Perhaps a solution would be to add a file in the cache called /duplicity-md5sums.txt/ that would contain the md5sum of each file in the cache.  As long as that matched, and the cache was unencrypted, we would not need to hit the remote, except to list filenames.  Thoughts?  As to ignoring errors in the sync between local and remote, I can't even imagine the number of ways we'd get into troubles.

backups w/o private key currently only work because they _actually do_ "ignoring errors in the sync between local and remote", that's why i want to remove that "functionality"!
as explained, until we implement unencrypted but signed file hashes(or lists) for backend files, users will not miss any functionality as they can already today switch from

bad) backup w/o private key (archive sync decrypt errors are ignored)
  to
good) backup w/o private key by encrypting against a public personal key _and_ a machine specific full key pair

. ..ede

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk