#66 Duply hangs in verify when signing key is not specified

[Robert Buchholz]

We have a duply configuration that encrypts and signs with the same key (well, actually two keys, but one is the subkey of the other):

pub  4096R/31111111  created: 2013-08-14  expires: never       usage: SCEA
                     trust: unknown       validity: unknown
sub  4096R/81111111  created: 2013-08-14  expires: never       usage: SEA

Usually, when dealing with GnuPG, it handles this situation just fine and chooses encryption or signing key as needed. This also happens when performing a backup using duply. We only specified GPG_KEY="31111111".

However, during purge (after a backup is created), it hangs with a warning saying that the wrong key is used.
There's two issues here:

• First, as a cron job, it should never hang
• Second, it should handle pub/sub keys consistently. Ideally, simply always accept the public key.

A log output, unfortunately localized:

--- Start running command VERIFY at 13:14:49.523 ---
Lese ausdruckbasierte Dateiliste /etc/duply/testvm/exclude
Lokale und entfernte Metadaten sind bereits synchron, keine Synchronisierung benötigt.
Letzte vollständige Sicherung: Mon Aug 19 13:12:10 2013
Volume wurde von Schlüssel 81111111, anstatt von 31111111 unterschrieben



^CException KeyboardInterrupt in <module 'threading' from '/usr/lib64/python2.6/threading.pyc'> ignored

^ hangs here

[Robert Buchholz]

Hello ede,

can you elaborate on why this bug report is invalid?

Cheers,

Robert

[ede]

On 27.12.2013 12:12, Robert Buchholz wrote:

Hello ede,

can you elaborate on why this bug report is invalid?

sure. answered it yesterday, but does not seem to have made it through. i'll resend.

..ede

[ede]

On 19.08.2013 15:36, Robert Buchholz wrote:

---

[bugs:#66] http://sourceforge.net/p/ftplicity/bugs/66/ Duply hangs in verify when signing key is not specified

Status: open
Created: Mon Aug 19, 2013 01:36 PM UTC by Robert Buchholz
Last Updated: Mon Aug 19, 2013 01:36 PM UTC
Owner: nobody

We have a duply configuration that encrypts and signs with the same key (well, actually two keys, but one is the subkey of the other):

pub 4096R/31111111 created: 2013-08-14 expires: never usage: SCEA
trust: unknown validity: unknown
sub 4096R/81111111 created: 2013-08-14 expires: never usage: SEA

Usually, when dealing with GnuPG, it handles this situation just fine and chooses encryption or signing key as needed. This also happens when performing a backup using duply. We only specified GPG_KEY="31111111".

However, during purge (after a backup is created), it /hangs/ with a warning saying that the wrong key is used.
There's two issues here:
- First, as a cron job, it should never hang

this is duplicity hanging.. not duply

• Second, it should handle pub/sub keys consistently. Ideally, simply always accept the public key.

A log output, unfortunately localized:

--- Start running command VERIFY at 13:14:49.523 ---
Lese ausdruckbasierte Dateiliste /etc/duply/testvm/exclude
Lokale und entfernte Metadaten sind bereits synchron, keine Synchronisierung benötigt.
Letzte vollständige Sicherung: Mon Aug 19 13:12:10 2013
Volume wurde von Schlüssel 81111111, anstatt von 31111111 unterschrieben

^CException KeyboardInterrupt in <module 'threading'="" from="" '="" usr="" lib64="" python2.6="" threading.pyc'=""> ignored</module>

^ hangs here

can you replicate the issue all the time? actually it is not complaining about encryption but signing keys.

duplicity does never hang because of unmatching signatures it merely states the fact and goes on. exit status is failed though. just checked with a test backup run twice with different signing keys and a verify afterwards.

if the issue persists please consider joining the duplicity mailing list where i also answer on issues about duply.

regards ..ede/duply.net