Bad parsing of GnuPG output, expecting english output, which doesn't work if locales different than english.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
Fix Released
|
High
|
Unassigned | ||
duplicity (Debian) |
Fix Released
|
Unknown
|
|||
duplicity (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
this is a forward/extract of debian bug #565398, which lives over there: http://
summary: when using gpg and --encrypt-key, and only if LANG is set to de_AT
and LC_CTYPE is set to de_AT (or POSIX or C, but not iso-8859-1 or utf-8),
then incremental backups fail completely. somehow or other duplicity
mis-interprets gnupg output and errors out: i assume it would be
the 8-bit nature of certain phrases like "Schlüssel" (german for "key")
which causes the mess, but i can't identify the code in question.
reproducible: always. needs only an empty backup dir (source), an empty
target dir (target), a gpg key and locale de_AT available.
duplicity --encrypt-key KEYID source file://target
works fine, creates a (minuscule) full backup
running it again, with LANG unset (or to something purely 7bit like en_US)
works perfect again, no problems.
but running it with LANG=de_AT and LC_CTYPE=de_AT causes duplicity to attempt
some gnupg decryption (of what? the cache and archive are in sync), and
it dies with a gpg failure (with the gpg message being the german equivalent
of "encryption failed: bad passphrase", not surprising as no passphrase was
given, nor should one be necessary).
i'm attaching the relevant -v9 logs, first of the successful full run,
then of a failed inc run (LANG and LC_CTYPE=de_AT) and then of the
successful inc run (LANG="", LC_CTYPE=de_AT). no changes were made to
the source dir between runs.
regards,
az
Changed in debian: | |
status: | Unknown → Confirmed |
affects: | ubuntu → duplicity (Ubuntu) |
affects: | debian → duplicity (Debian) |
summary: |
- 0.6.06: all incremental backends with --encrypt-key and LANG=de_AT + Bad parsing of GnuPG output, expecting english output, which doesn't + work if locales different than english. |
Changed in duplicity: | |
importance: | Undecided → High |
Changed in duplicity: | |
milestone: | none → 0.8.24 |
status: | Confirmed → Fix Committed |
Changed in duplicity: | |
status: | Fix Committed → Fix Released |
Changed in duplicity (Debian): | |
status: | Confirmed → Fix Released |
Similar problem here (failure if LANG=fr_FR.UTF-8, success if LANG is empty)