Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270488 > unrolled thread

Bug#1120839: New Upstream Version

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1120839: New Upstream Version "Barak A. Pearlmutter" <barak@cs.nuim.ie> - 2025-11-17 11:50 +0100
    Bug#1120839: New Upstream Version Alexander Zangerl <az@snafu.priv.at> - 2025-11-18 10:50 +0100
      Bug#1120839: New Upstream Version "Barak A. Pearlmutter" <barak@cs.nuim.ie> - 2025-11-22 21:20 +0100
        Bug#1120839: New Upstream Version Kenneth Loafman <kenneth@loafman.com> - 2025-11-23 13:00 +0100
          Bug#1120839: New Upstream Version "Barak A. Pearlmutter" <barak@cs.nuim.ie> - 2025-11-24 09:50 +0100
          Bug#1120839: New Upstream Version Alexander Zangerl <az@snafu.priv.at> - 2025-11-29 06:50 +0100
    Bug#1120839: New Upstream Version Alexander Zangerl <az@snafu.priv.at> - 2025-11-30 01:50 +0100
    Bug#1120839: New Upstream Version Kenneth Loafman <kenneth@loafman.com> - 2025-12-28 19:00 +0100
    Bug#1120839: New Upstream Version Dominique Dumont <dod@debian.org> - 2025-12-28 19:00 +0100
    Bug#1120839: Crypto Credentials Passthrough "Barak A. Pearlmutter" <barak@cs.nuim.ie> - 2025-12-31 20:00 +0100
      Bug#1120839: Crypto Credentials Passthrough "Barak A. Pearlmutter" <barak@cs.nuim.ie> - 2025-12-31 20:30 +0100
      Bug#1120839: Crypto Credentials Passthrough Alexander Zangerl <az@snafu.priv.at> - 2026-01-01 04:00 +0100
        Bug#1120839: Crypto Credentials Passthrough "Barak A. Pearlmutter" <barak@cs.nuim.ie> - 2026-01-01 14:10 +0100

#1270488 — Bug#1120839: New Upstream Version

Package: duplicity
Version: 3.0.5.1-2

There is a new upstream version released, 3.0.6.1, which claims to
address my own favourite bug, #977546.

I've packaged the new version as a test, in a fork of your packaging
repo on github

https://github.com/barak/duplicity

I've also done some minor packaging updates. One thing I'm not sure
about is if I got the changed dependencies, like properly adjusting
for python3-socks aka pysocks. Also upstream tweaked the test suite,
not sure if I correctly merged your test suite patch with upstream's
changes.

Anyway, we'll see if this new version works properly when I run out of
space and have a partial full backup that needs to be cleaned!

Cheers,

--Barak.

[toc] | [next] | [standalone]

#1270630

[Multipart message — attachments visible in raw view] — view raw

On Mon, 17 Nov 2025 10:33:16 +0000, "Barak A. Pearlmutter" writes:
>Anyway, we'll see if this new version works properly when I run out of
>space and have a partial full backup that needs to be cleaned!

thanks for the heads-up and the tinkering; i hope to find a little time
for duplicity this weekend.


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
"SPARC" is "CRAPS" backwards -- Rob Pike

[toc] | [prev] | [next] | [standalone]

#1271223

Well, one issue with the new version is that it wants a GPG passphrase
*EVERY RUN*, and also doesn't know how to ask for it properly: you
need to do shenanigans with an agent and such. The following:

    --gpg-options="--pinentry-mode=loopback
--passphrase-file=${passphrase_file}"

does NOT work, because duplicity has its own way of doing things and
still wants a passphrase. It recommends putting the phrase in an
*environment variable* which is an awful security problem.

The old version (a) only needed the passphrase rarely, and (b) when it
did need it, you could run it in a terminal and it would just ask for
it.

[toc] | [prev] | [next] | [standalone]

#1271272

[Multipart message — attachments visible in raw view] — view raw

Version 3.0.6.2 was just released.  It goes back to the old passphrase
handling and fixes other problems, so skip the 3.0.6.1 version and go to
3.0.6.2.

...Thanks,
...Ken


On Sat, Nov 22, 2025 at 2:13 PM Barak A. Pearlmutter <barak@cs.nuim.ie>
wrote:

> Well, one issue with the new version is that it wants a GPG passphrase
> *EVERY RUN*, and also doesn't know how to ask for it properly: you
> need to do shenanigans with an agent and such. The following:
>
>     --gpg-options="--pinentry-mode=loopback
> --passphrase-file=${passphrase_file}"
>
> does NOT work, because duplicity has its own way of doing things and
> still wants a passphrase. It recommends putting the phrase in an
> *environment variable* which is an awful security problem.
>
> The old version (a) only needed the passphrase rarely, and (b) when it
> did need it, you could run it in a terminal and it would just ask for
> it.
>

[toc] | [prev] | [next] | [standalone]

#1271397

Packaged 3.0.6.2 in github.com/barak/duplicity branch debian, seems to
work okay! Not sure if due to my fixing option passing vs changes to
duplicity GPG stuff, but in any case my stuff is being backed up,
phew.

[toc] | [prev] | [next] | [standalone]

#1272046

[Multipart message — attachments visible in raw view] — view raw

On Sun, 23 Nov 2025 05:57:38 -0600, Kenneth Loafman writes:
>Version 3.0.6.2 was just released.  It goes back to the old passphrase
>handling and fixes other problems, so skip the 3.0.6.1 version and go to
>3.0.6.2.

unfortunately version 3.0.6.2 is broken wrt. incremental backups with asymmetric encryption.
it tells me that the metadata is in sync, followed immediately by a kaboom when
it attempts to decrypt a remote manifest file

example invocation (which has worked fine up to and including 3.0.5.1):

 duplicity backup --exclude-other-filesystems --volsize 250 --encrypt-key 2FCCF66BB963BD5F --archive-dir /var/lib/duplicity \
 --name boot --full-if-older-than 7D /boot rsync://backup@REDACTED::/backup/REDACTED/boot
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Nov 26 01:04:01 2025
Error processing remote file (duplicity-inc.20251127T150401Z.to.20251128T150401Z.manifest.gpg): GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 4096-bit RSA key, ID 0x360EEB3F4F780821, created 2013-11-03
"Alexander Zangerl <az@snafu.priv.at>"
gpg: decryption failed: secret key not available
===== End GnuPG log =====

Traceback (innermost last):
  File "/usr/lib/python3/dist-packages/duplicity/__main__.py", line 76, in dup_run
    with_tempdir(main)
  File "/usr/lib/python3/dist-packages/duplicity/__main__.py", line 60, in with_tempdir
    fn()
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1646, in main
    do_backup(action)
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1799, in do_backup
    check_last_manifest(col_stats)  # not needed for full backups
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1460, in check_last_manifest
    last_backup_set.check_manifests(check_remote=config.check_remote)
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 271, in check_manifests
    remote_manifest = self.get_remote_manifest() if check_remote else None
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 316, in get_remote_manifest
    manifest_buffer = self.get_remote_file(self.remote_manifest_name)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 329, in get_remote_file
    log.Info(_(f"Processing remote file {os.fsdecode(remote_file)} ({len(remote_file_buffer)})"))
                                                                         ^^^^^^^^^^^^^^^^^^
 UnboundLocalError: cannot access local variable 'remote_file_buffer' where it is not associated with a value


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
Our OS who art in CPU, UNIX be thy name.
Thy programs run, thy syscalls done, in kernel as it is in user!
 -- BSD fortune file

[toc] | [prev] | [next] | [standalone]

#1272161

[Multipart message — attachments visible in raw view] — view raw

On Sat, 29 Nov 2025 07:59:18 -0600, Kenneth Loafman writes:
>I have a possible fix for this, see attached patch.  Would you mind trying
>it?
>Seems there was a line deleted that should not have been.  AArgh!

with the patch i get different but still broken behaviour.

same invocation as last time:

duplicity backup --exclude-other-filesystems --volsize 250 \
--encrypt-key 2FCCF66BB963BD5F --archive-dir /var/lib/duplicity \
--name boot --full-if-older-than 7D /boot \
rsync://backup@REDACTED::/backup/REDACTED/boot

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Nov 26 01:04:01 2025
Error processing remote file (duplicity-inc.20251129T053415Z.to.20251129T150401Z.manifest.gpg): GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 4096-bit RSA key, ID 0x360EEB3F4F780821, created 2013-11-03
"Alexander Zangerl <az@snafu.priv.at>"
gpg: decryption failed: secret key not available
===== End GnuPG log =====

Manifests not equal because different volume numbers
Fatal Error: Remote manifest does not match local one.
Either the remote backup set or the local archive directory has been corrupted.



-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
Hal, open the file Hal, open the damn file, Hal open the, please Hal

[toc] | [prev] | [next] | [standalone]

#1276112

[Multipart message — attachments visible in raw view] — view raw

The fix is already done and will be out in `3.0.7` by the end of the year.

...Thanks,
...Ken

On Sun, Dec 28, 2025 at 11:49 AM Dominique Dumont <dod@debian.org> wrote:

> On Sat, 29 Nov 2025 07:59:18 -0600 Kenneth Loafman <kenneth@loafman.com>
> wrote:
> > I have a possible fix for this, see attached patch.  Would you mind
> trying
> > it?
>
> I have similar issues with 3.0.6.3-1.
>
> With --no-check-remote and --encrypt-key options, duplicity still asks for
> a passphrase.
>
> I believe the line
>
> https://gitlab.com/duplicity/duplicity/-/blob/dev/duplicity/dup_main.py?ref_type=heads#L160
> is wrong and that need_passphrase should be set to False there.
>
> HTH
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#1276114

On Sat, 29 Nov 2025 07:59:18 -0600 Kenneth Loafman <kenneth@loafman.com> wrote:
> I have a possible fix for this, see attached patch.  Would you mind trying
> it?

I have similar issues with 3.0.6.3-1. 

With --no-check-remote and --encrypt-key options, duplicity still asks for a passphrase.

I believe the line 
https://gitlab.com/duplicity/duplicity/-/blob/dev/duplicity/dup_main.py?ref_type=heads#L160
is wrong and that need_passphrase should be set to False there.

HTH

[toc] | [prev] | [next] | [standalone]

#1276535 — Bug#1120839: Crypto Credentials Passthrough

Version 3.6.0.3-1 still has an issue with credentials being passed
through to gpg. I generated a package 3.6.0.3-1.1 in
https://github.com/barak/duplicity branch debian commit e838d638 which
includes post-3.6.0.3 development, in particular commit ac163d5e which
fixes the problem. It also has a few other minor tweaks, like an
updated debian/watch file.

[toc] | [prev] | [next] | [standalone]

#1276536 — Bug#1120839: Crypto Credentials Passthrough

Never mind, upstream 3.0.7 is out.

[toc] | [prev] | [next] | [standalone]

#1276575 — Bug#1120839: Crypto Credentials Passthrough

[Multipart message — attachments visible in raw view] — view raw

On Wed, 31 Dec 2025 18:48:50 +0000, "Barak A. Pearlmutter" writes:
>Version 3.6.0.3-1 still has an issue with credentials being passed
>through to gpg.

yes, and it doesn't work without any encryption at all either.

>I generated a package 3.6.0.3-1.1 in

thanks for your efforts. we clearly duplicated some of that
in the last two days: i pushed out 3.6.0.3-2 yesterday,
which...

>includes post-3.6.0.3 development, in particular commit ac163d5e which
>fixes the problem.

...also includes that commit but not unchanged. upstream doesn't seem to
understand public key encryption and insists on passphrase-checking
*public* keys without reason.

while that commit fixes some/most gpg2 use with agent and gpgsm and
other special cases, it absolutely breaks
public-key-only/no-private-key-in-sight encryption.

(in the orginal commit, line 150 in dup_main.py makes
public key encryption strictly depend on check remote.
with --no-check-remote you get no public key encryption
at all and it falls through to symmetric.)

>It also has a few other minor tweaks, like an
>updated debian/watch file.

i'll have a look at these when i prep the next release, but
that won't be for a while: 3.0.6 broke much more than it fixed,
and i want 3.0.7 to mature some before i spend time on it.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
:q :q! :wq :w :w! :wq! :quit :quit! :help help helpquit quit quithelp
 :quitplease :quitnow :leave :shit ^X^C ^C ^D ^Z ^Q QUITDAMMIT ^]:wq

[toc] | [prev] | [next] | [standalone]

#1276624 — Bug#1120839: Crypto Credentials Passthrough

Yes, the big advantage of duplicity when I first started using it long
ago was that it used public key encryption, so the remote backup was
encrypted but couldn't be decrypted without information not present on
the being-backed-up machine. I thought that was a pretty fine idea.
And that property is now broken.

I was sort of assuming the issue would be dealt with in the fullness
of time, and in the meantime at least I'd have backups, even if I
needed to open up a private key during the backup process which seems
like a pretty bad idea.

Of course, the shorter this window of
not-properly-using-asymmetric-encryption is open the happier I'll be.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web