different behaviour according to LC_ALL value

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

different behaviour according to LC_ALL value

duplicity-talk mailing list
Hi,

I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
Is there an explanation of this behaviour?

[root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Mar  8 09:50:38 2017
--------------[ Backup Statistics ]--------------
StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
ElapsedTime 4.84 (4.84 seconds)
SourceFiles 13568
SourceFileSize 13623047487 (12.7 GB)
NewFiles 0
NewFileSize 0 (0 bytes)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 0
RawDeltaSize 0 (0 bytes)
TotalDestinationSizeChange 372 (372 bytes)
Errors 0
-------------------------------------------------

[root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
« ci (ci encryption key) <""> »
gpg: échec du déchiffrement : Pas de clef secrète
===== End GnuPG log =====

The french output says:

"
gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
gpg: decryption failed, no secret key.
"

BDABF623 is the id of the subkey with id F747CAB9.

This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
   /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/

but it failed (not finding the secret key, which it should not need). After some changing the environment to have
the output in english, I was surprised to see it work fine.

Here is some more info:

# duplicity --version
duplicity 0.7.11

# gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.


Thanks

Rb

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.

There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.

...Thanks,
...Ken


On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email]> wrote:
Hi,

I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
Is there an explanation of this behaviour?

[root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Mar  8 09:50:38 2017
--------------[ Backup Statistics ]--------------
StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
ElapsedTime 4.84 (4.84 seconds)
SourceFiles 13568
SourceFileSize 13623047487 (12.7 GB)
NewFiles 0
NewFileSize 0 (0 bytes)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 0
RawDeltaSize 0 (0 bytes)
TotalDestinationSizeChange 372 (372 bytes)
Errors 0
-------------------------------------------------

[root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
« ci (ci encryption key) <""> »
gpg: échec du déchiffrement : Pas de clef secrète
===== End GnuPG log =====

The french output says:

"
gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
gpg: decryption failed, no secret key.
"

BDABF623 is the id of the subkey with id F747CAB9.

This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
   /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/

but it failed (not finding the secret key, which it should not need). After some changing the environment to have
the output in english, I was surprised to see it work fine.

Here is some more info:

# duplicity --version
duplicity 0.7.11

# gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.


Thanks

Rb

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk



_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
good guess, but to me it looks like exactly this long standing issue
 https://bugs.launchpad.net/duplicity/+bug/687295

..ede/duply.net

On 08.03.2017 16:04, Kenneth Loafman via Duplicity-talk wrote:

> Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.
>
> There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.
>
> ...Thanks,
> ...Ken
>
>
> On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
>     Is there an explanation of this behaviour?
>
>     [root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     Local and Remote metadata are synchronized, no sync needed.
>     Last full backup date: Wed Mar  8 09:50:38 2017
>     --------------[ Backup Statistics ]--------------
>     StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
>     EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
>     ElapsedTime 4.84 (4.84 seconds)
>     SourceFiles 13568
>     SourceFileSize 13623047487 (12.7 GB)
>     NewFiles 0
>     NewFileSize 0 (0 bytes)
>     DeletedFiles 0
>     ChangedFiles 0
>     ChangedFileSize 0 (0 bytes)
>     ChangedDeltaSize 0 (0 bytes)
>     DeltaEntries 0
>     RawDeltaSize 0 (0 bytes)
>     TotalDestinationSizeChange 372 (372 bytes)
>     Errors 0
>     -------------------------------------------------
>
>     [root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
>     Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
>     GPGError: GPG Failed, see log below:
>     ===== Begin GnuPG log =====
>     gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
>     « ci (ci encryption key) <""> »
>     gpg: échec du déchiffrement : Pas de clef secrète
>     ===== End GnuPG log =====
>
>     The french output says:
>
>     "
>     gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
>     gpg: decryption failed, no secret key.
>     "
>
>     BDABF623 is the id of the subkey with id F747CAB9.
>
>     This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
>        /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>
>     but it failed (not finding the secret key, which it should not need). After some changing the environment to have
>     the output in english, I was surprised to see it work fine.
>
>     Here is some more info:
>
>     # duplicity --version
>     duplicity 0.7.11
>
>     # gpg --version
>     gpg (GnuPG) 2.0.22
>     libgcrypt 1.5.3
>     Copyright (C) 2013 Free Software Foundation, Inc.
>
>
>     Thanks
>
>     Rb
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
The last sentence, "After some changing the environment to have the output in english, I was surprised to see it work fine." is what triggered me.

Nowhere does he mention having removed the secret key.

@Raphael, is your keyring intact?

...Ken


On Wed, Mar 8, 2017 at 9:08 AM, edgar.soldin--- via Duplicity-talk <[hidden email]> wrote:
good guess, but to me it looks like exactly this long standing issue
 https://bugs.launchpad.net/duplicity/+bug/687295

..ede/duply.net

On 08.03.2017 16:04, Kenneth Loafman via Duplicity-talk wrote:
> Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.
>
> There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.
>
> ...Thanks,
> ...Ken
>
>
> On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
>     Is there an explanation of this behaviour?
>
>     [root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     Local and Remote metadata are synchronized, no sync needed.
>     Last full backup date: Wed Mar  8 09:50:38 2017
>     --------------[ Backup Statistics ]--------------
>     StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
>     EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
>     ElapsedTime 4.84 (4.84 seconds)
>     SourceFiles 13568
>     SourceFileSize 13623047487 (12.7 GB)
>     NewFiles 0
>     NewFileSize 0 (0 bytes)
>     DeletedFiles 0
>     ChangedFiles 0
>     ChangedFileSize 0 (0 bytes)
>     ChangedDeltaSize 0 (0 bytes)
>     DeltaEntries 0
>     RawDeltaSize 0 (0 bytes)
>     TotalDestinationSizeChange 372 (372 bytes)
>     Errors 0
>     -------------------------------------------------
>
>     [root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
>     Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
>     GPGError: GPG Failed, see log below:
>     ===== Begin GnuPG log =====
>     gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
>     « ci (ci encryption key) <""> »
>     gpg: échec du déchiffrement : Pas de clef secrète
>     ===== End GnuPG log =====
>
>     The french output says:
>
>     "
>     gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
>     gpg: decryption failed, no secret key.
>     "
>
>     BDABF623 is the id of the subkey with id F747CAB9.
>
>     This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
>        /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>
>     but it failed (not finding the secret key, which it should not need). After some changing the environment to have
>     the output in english, I was surprised to see it work fine.
>
>     Here is some more info:
>
>     # duplicity --version
>     duplicity 0.7.11
>
>     # gpg --version
>     gpg (GnuPG) 2.0.22
>     libgcrypt 1.5.3
>     Copyright (C) 2013 Free Software Foundation, Inc.
>
>
>     Thanks
>
>     Rb
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
well, he probably never needed the secret key until there was something in the archive dir to synchronize ;)

..ede

On 08.03.2017 16:55, Kenneth Loafman wrote:

> The last sentence, "After some changing the environment to have the output in english, I was surprised to see it work fine." is what triggered me.
>
> Nowhere does he mention having removed the secret key.
>
> @Raphael, is your keyring intact?
>
> ...Ken
>
>
> On Wed, Mar 8, 2017 at 9:08 AM, edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     good guess, but to me it looks like exactly this long standing issue
>      https://bugs.launchpad.net/duplicity/+bug/687295 <https://bugs.launchpad.net/duplicity/+bug/687295>
>
>     ..ede/duply.net <http://duply.net>
>
>     On 08.03.2017 16:04, Kenneth Loafman via Duplicity-talk wrote:
>     > Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.
>     >
>     > There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.
>     >
>     > ...Thanks,
>     > ...Ken
>     >
>     >
>     > On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi,
>     >
>     >     I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
>     >     Is there an explanation of this behaviour?
>     >
>     >     [root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >     Local and Remote metadata are synchronized, no sync needed.
>     >     Last full backup date: Wed Mar  8 09:50:38 2017
>     >     --------------[ Backup Statistics ]--------------
>     >     StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
>     >     EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
>     >     ElapsedTime 4.84 (4.84 seconds)
>     >     SourceFiles 13568
>     >     SourceFileSize 13623047487 (12.7 GB)
>     >     NewFiles 0
>     >     NewFileSize 0 (0 bytes)
>     >     DeletedFiles 0
>     >     ChangedFiles 0
>     >     ChangedFileSize 0 (0 bytes)
>     >     ChangedDeltaSize 0 (0 bytes)
>     >     DeltaEntries 0
>     >     RawDeltaSize 0 (0 bytes)
>     >     TotalDestinationSizeChange 372 (372 bytes)
>     >     Errors 0
>     >     -------------------------------------------------
>     >
>     >     [root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >     Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
>     >     Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
>     >     GPGError: GPG Failed, see log below:
>     >     ===== Begin GnuPG log =====
>     >     gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
>     >     « ci (ci encryption key) <""> »
>     >     gpg: échec du déchiffrement : Pas de clef secrète
>     >     ===== End GnuPG log =====
>     >
>     >     The french output says:
>     >
>     >     "
>     >     gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
>     >     gpg: decryption failed, no secret key.
>     >     "
>     >
>     >     BDABF623 is the id of the subkey with id F747CAB9.
>     >
>     >     This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
>     >        /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >
>     >     but it failed (not finding the secret key, which it should not need). After some changing the environment to have
>     >     the output in english, I was surprised to see it work fine.
>     >
>     >     Here is some more info:
>     >
>     >     # duplicity --version
>     >     duplicity 0.7.11
>     >
>     >     # gpg --version
>     >     gpg (GnuPG) 2.0.22
>     >     libgcrypt 1.5.3
>     >     Copyright (C) 2013 Free Software Foundation, Inc.
>     >
>     >
>     >     Thanks
>     >
>     >     Rb
>     >
>     >     _______________________________________________
>     >     Duplicity-talk mailing list
>     >     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Duplicity-talk mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>     >
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
Normally the secret key is genned in the same dir as the public key.  It would have to be manually removed, and most people don't bother.

Either way, we need more data.

...Ken


On Wed, Mar 8, 2017 at 10:08 AM, <[hidden email]> wrote:
well, he probably never needed the secret key until there was something in the archive dir to synchronize ;)

..ede

On 08.03.2017 16:55, Kenneth Loafman wrote:
> The last sentence, "After some changing the environment to have the output in english, I was surprised to see it work fine." is what triggered me.
>
> Nowhere does he mention having removed the secret key.
>
> @Raphael, is your keyring intact?
>
> ...Ken
>
>
> On Wed, Mar 8, 2017 at 9:08 AM, edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     good guess, but to me it looks like exactly this long standing issue
>      https://bugs.launchpad.net/duplicity/+bug/687295 <https://bugs.launchpad.net/duplicity/+bug/687295>
>
>     ..ede/duply.net <http://duply.net>
>
>     On 08.03.2017 16:04, Kenneth Loafman via Duplicity-talk wrote:
>     > Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.
>     >
>     > There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.
>     >
>     > ...Thanks,
>     > ...Ken
>     >
>     >
>     > On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi,
>     >
>     >     I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
>     >     Is there an explanation of this behaviour?
>     >
>     >     [root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >     Local and Remote metadata are synchronized, no sync needed.
>     >     Last full backup date: Wed Mar  8 09:50:38 2017
>     >     --------------[ Backup Statistics ]--------------
>     >     StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
>     >     EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
>     >     ElapsedTime 4.84 (4.84 seconds)
>     >     SourceFiles 13568
>     >     SourceFileSize 13623047487 (12.7 GB)
>     >     NewFiles 0
>     >     NewFileSize 0 (0 bytes)
>     >     DeletedFiles 0
>     >     ChangedFiles 0
>     >     ChangedFileSize 0 (0 bytes)
>     >     ChangedDeltaSize 0 (0 bytes)
>     >     DeltaEntries 0
>     >     RawDeltaSize 0 (0 bytes)
>     >     TotalDestinationSizeChange 372 (372 bytes)
>     >     Errors 0
>     >     -------------------------------------------------
>     >
>     >     [root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >     Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
>     >     Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
>     >     GPGError: GPG Failed, see log below:
>     >     ===== Begin GnuPG log =====
>     >     gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
>     >     « ci (ci encryption key) <""> »
>     >     gpg: échec du déchiffrement : Pas de clef secrète
>     >     ===== End GnuPG log =====
>     >
>     >     The french output says:
>     >
>     >     "
>     >     gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
>     >     gpg: decryption failed, no secret key.
>     >     "
>     >
>     >     BDABF623 is the id of the subkey with id F747CAB9.
>     >
>     >     This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
>     >        /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >
>     >     but it failed (not finding the secret key, which it should not need). After some changing the environment to have
>     >     the output in english, I was surprised to see it work fine.
>     >
>     >     Here is some more info:
>     >
>     >     # duplicity --version
>     >     duplicity 0.7.11
>     >
>     >     # gpg --version
>     >     gpg (GnuPG) 2.0.22
>     >     libgcrypt 1.5.3
>     >     Copyright (C) 2013 Free Software Foundation, Inc.
>     >
>     >
>     >     Thanks
>     >
>     >     Rb
>     >
>     >     _______________________________________________
>     >     Duplicity-talk mailing list
>     >     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Duplicity-talk mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>     >
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
Hi,

Here is some more info:

the private key for the encryption of the backup was never on the server. I've generated the encryption key on my desktop, exported the public key, and imported that one on the server. there might have been a secret key for signing, but I've never passed it to the duplicity command. As I had problems I've also started from scratch, deleting cache and checking the gpg keys present on the server. I've then done the first full backup in the french locale, but then I couldn't do a incremental in the same locale. Switching to en_US worked fine though.

I've just done an additional test, where you see there's no secret key, the full backup works, but the incremental after that not (though switching to en_US does):

[root@dev ~]# gpg --list-secret-keys
[root@dev ~]# LC_ALL=fr_FR /bin/duplicity full --encrypt-key 'F747CAB9' /etc rsync://rsync/duplicity-test
Synchronisation des métadonnées distantes vers le cache local...
Supprime le /root/.cache/duplicity/26e389a229cace43c44e0eb5df8543ae/duplicity-full-signatures.20170309T074245Z.sigtar.gz local (ne fait pas autorité au niveau du serveur).
Supprime le /root/.cache/duplicity/26e389a229cace43c44e0eb5df8543ae/duplicity-full.20170309T074245Z.manifest local (ne fait pas autorité au niveau du serveur).
Date de la dernière sauvegarde complète : aucune
--------------[ Statistiques de sauvegarde ]--------------
StartTime 1489045497.96 (Thu Mar  9 08:44:57 2017)
EndTime 1489045499.30 (Thu Mar  9 08:44:59 2017)
ElapsedTime 1.34 (1.34 seconds)
SourceFiles 1189
SourceFileSize 20723857 (19.8 MB)
NewFiles 1189
NewFileSize 20723857 (19.8 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 1189
RawDeltaSize 20580423 (19.6 MB)
TotalDestinationSizeChange 7207998 (6.87 MB)
Errors 0
----------------------------------------------------------

[root@dev ~]# LC_ALL=fr_FR /bin/duplicity inc --encrypt-key 'F747CAB9' /etc rsync://rsync/duplicity-test
Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
Date de la dernière sauvegarde complète : Thu Mar  9 08:44:56 2017
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
« ci (ci encryption key) <""> »
gpg: échec du déchiffrement : Pas de clef secrète
===== End GnuPG log =====


Thanks all for your responses,

Rb

On Wed, Mar 8, 2017 at 5:17 PM, Kenneth Loafman via Duplicity-talk <[hidden email]> wrote:
Normally the secret key is genned in the same dir as the public key.  It would have to be manually removed, and most people don't bother.

Either way, we need more data.

...Ken


On Wed, Mar 8, 2017 at 10:08 AM, <[hidden email]> wrote:
well, he probably never needed the secret key until there was something in the archive dir to synchronize ;)

..ede

On 08.03.2017 16:55, Kenneth Loafman wrote:
> The last sentence, "After some changing the environment to have the output in english, I was surprised to see it work fine." is what triggered me.
>
> Nowhere does he mention having removed the secret key.
>
> @Raphael, is your keyring intact?
>
> ...Ken
>
>
> On Wed, Mar 8, 2017 at 9:08 AM, edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     good guess, but to me it looks like exactly this long standing issue
>      https://bugs.launchpad.net/duplicity/+bug/687295 <https://bugs.launchpad.net/duplicity/+bug/687295>
>
>     ..ede/duply.net <http://duply.net>
>
>     On 08.03.2017 16:04, Kenneth Loafman via Duplicity-talk wrote:
>     > Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.
>     >
>     > There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.
>     >
>     > ...Thanks,
>     > ...Ken
>     >
>     >
>     > On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi,
>     >
>     >     I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
>     >     Is there an explanation of this behaviour?
>     >
>     >     [root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >     Local and Remote metadata are synchronized, no sync needed.
>     >     Last full backup date: Wed Mar  8 09:50:38 2017
>     >     --------------[ Backup Statistics ]--------------
>     >     StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
>     >     EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
>     >     ElapsedTime 4.84 (4.84 seconds)
>     >     SourceFiles 13568
>     >     SourceFileSize 13623047487 (12.7 GB)
>     >     NewFiles 0
>     >     NewFileSize 0 (0 bytes)
>     >     DeletedFiles 0
>     >     ChangedFiles 0
>     >     ChangedFileSize 0 (0 bytes)
>     >     ChangedDeltaSize 0 (0 bytes)
>     >     DeltaEntries 0
>     >     RawDeltaSize 0 (0 bytes)
>     >     TotalDestinationSizeChange 372 (372 bytes)
>     >     Errors 0
>     >     -------------------------------------------------
>     >
>     >     [root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >     Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
>     >     Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
>     >     GPGError: GPG Failed, see log below:
>     >     ===== Begin GnuPG log =====
>     >     gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
>     >     « ci (ci encryption key) <""> »
>     >     gpg: échec du déchiffrement : Pas de clef secrète
>     >     ===== End GnuPG log =====
>     >
>     >     The french output says:
>     >
>     >     "
>     >     gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
>     >     gpg: decryption failed, no secret key.
>     >     "
>     >
>     >     BDABF623 is the id of the subkey with id F747CAB9.
>     >
>     >     This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
>     >        /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>     >
>     >     but it failed (not finding the secret key, which it should not need). After some changing the environment to have
>     >     the output in english, I was surprised to see it work fine.
>     >
>     >     Here is some more info:
>     >
>     >     # duplicity --version
>     >     duplicity 0.7.11
>     >
>     >     # gpg --version
>     >     gpg (GnuPG) 2.0.22
>     >     libgcrypt 1.5.3
>     >     Copyright (C) 2013 Free Software Foundation, Inc.
>     >
>     >
>     >     Thanks
>     >
>     >     Rb
>     >
>     >     _______________________________________________
>     >     Duplicity-talk mailing list
>     >     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>     >     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Duplicity-talk mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>     >
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk




--
Web database: http://www.myowndb.com
Free Software Developers Meeting: http://www.fosdem.org

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: different behaviour according to LC_ALL value

duplicity-talk mailing list
Raphael,

now it sounds to me exactly like the bug linked below
  https://bugs.launchpad.net/duplicity/+bug/687295

if you want to know what and why it happens, you should read the ticket and linked ml thread. what you describe is a known "feature", allbeit it only works when the locale is english or not set, defaulting to english.

..ede/duply.net


On 09.03.2017 08:46, Raphael Bauduin via Duplicity-talk wrote:

> Hi,
>
> Here is some more info:
>
> the private key for the encryption of the backup was never on the server. I've generated the encryption key on my desktop, exported the public key, and imported that one on the server. there might have been a secret key for signing, but I've never passed it to the duplicity command. As I had problems I've also started from scratch, deleting cache and checking the gpg keys present on the server. I've then done the first full backup in the french locale, but then I couldn't do a incremental in the same locale. Switching to en_US worked fine though.
>
> I've just done an additional test, where you see there's no secret key, the full backup works, but the incremental after that not (though switching to en_US does):
>
> [root@dev ~]# gpg --list-secret-keys
> [root@dev ~]# LC_ALL=fr_FR /bin/duplicity full --encrypt-key 'F747CAB9' /etc rsync://rsync/duplicity-test
> Synchronisation des métadonnées distantes vers le cache local...
> Supprime le /root/.cache/duplicity/26e389a229cace43c44e0eb5df8543ae/duplicity-full-signatures.20170309T074245Z.sigtar.gz local (ne fait pas autorité au niveau du serveur).
> Supprime le /root/.cache/duplicity/26e389a229cace43c44e0eb5df8543ae/duplicity-full.20170309T074245Z.manifest local (ne fait pas autorité au niveau du serveur).
> Date de la dernière sauvegarde complète : aucune
> --------------[ Statistiques de sauvegarde ]--------------
> StartTime 1489045497.96 (Thu Mar  9 08:44:57 2017)
> EndTime 1489045499.30 (Thu Mar  9 08:44:59 2017)
> ElapsedTime 1.34 (1.34 seconds)
> SourceFiles 1189
> SourceFileSize 20723857 (19.8 MB)
> NewFiles 1189
> NewFileSize 20723857 (19.8 MB)
> DeletedFiles 0
> ChangedFiles 0
> ChangedFileSize 0 (0 bytes)
> ChangedDeltaSize 0 (0 bytes)
> DeltaEntries 1189
> RawDeltaSize 20580423 (19.6 MB)
> TotalDestinationSizeChange 7207998 (6.87 MB)
> Errors 0
> ----------------------------------------------------------
>
> [root@dev ~]# LC_ALL=fr_FR /bin/duplicity inc --encrypt-key 'F747CAB9' /etc rsync://rsync/duplicity-test
> Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
> Date de la dernière sauvegarde complète : Thu Mar  9 08:44:56 2017
> GPGError: GPG Failed, see log below:
> ===== Begin GnuPG log =====
> gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
> « ci (ci encryption key) <""> »
> gpg: échec du déchiffrement : Pas de clef secrète
> ===== End GnuPG log =====
>
>
> Thanks all for your responses,
>
> Rb
>
> On Wed, Mar 8, 2017 at 5:17 PM, Kenneth Loafman via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Normally the secret key is genned in the same dir as the public key.  It would have to be manually removed, and most people don't bother.
>
>     Either way, we need more data.
>
>     ...Ken
>
>
>     On Wed, Mar 8, 2017 at 10:08 AM, <[hidden email] <mailto:[hidden email]>> wrote:
>
>         well, he probably never needed the secret key until there was something in the archive dir to synchronize ;)
>
>         ..ede
>
>         On 08.03.2017 16:55, Kenneth Loafman wrote:
>         > The last sentence, "After some changing the environment to have the output in english, I was surprised to see it work fine." is what triggered me.
>         >
>         > Nowhere does he mention having removed the secret key.
>         >
>         > @Raphael, is your keyring intact?
>         >
>         > ...Ken
>         >
>         >
>         > On Wed, Mar 8, 2017 at 9:08 AM, edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>         >
>         >     good guess, but to me it looks like exactly this long standing issue
>         >      https://bugs.launchpad.net/duplicity/+bug/687295 <https://bugs.launchpad.net/duplicity/+bug/687295> <https://bugs.launchpad.net/duplicity/+bug/687295 <https://bugs.launchpad.net/duplicity/+bug/687295>>
>         >
>         >     ..ede/duply.net <http://duply.net> <http://duply.net>
>         >
>         >     On 08.03.2017 16:04, Kenneth Loafman via Duplicity-talk wrote:
>         >     > Yes, the translations are either not complete or have issues with spelling, so matching against gpg responses is wrong.
>         >     >
>         >     > There is a bug to replace the use of text responses with numeric responses that we have not addressed yet.
>         >     >
>         >     > ...Thanks,
>         >     > ...Ken
>         >     >
>         >     >
>         >     > On Wed, Mar 8, 2017 at 8:08 AM, Raphael Bauduin via Duplicity-talk <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>> wrote:
>         >     >
>         >     >     Hi,
>         >     >
>         >     >     I have a very strange behaviour of duplicity. When LC_ALL=en_US, it works fine, when LC_ALL=fr_FR, it doesn't.
>         >     >     Is there an explanation of this behaviour?
>         >     >
>         >     >     [root@dev .cache]# LC_ALL="en_US" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>         >     >     Local and Remote metadata are synchronized, no sync needed.
>         >     >     Last full backup date: Wed Mar  8 09:50:38 2017
>         >     >     --------------[ Backup Statistics ]--------------
>         >     >     StartTime 1488981015.77 (Wed Mar  8 14:50:15 2017)
>         >     >     EndTime 1488981020.62 (Wed Mar  8 14:50:20 2017)
>         >     >     ElapsedTime 4.84 (4.84 seconds)
>         >     >     SourceFiles 13568
>         >     >     SourceFileSize 13623047487 (12.7 GB)
>         >     >     NewFiles 0
>         >     >     NewFileSize 0 (0 bytes)
>         >     >     DeletedFiles 0
>         >     >     ChangedFiles 0
>         >     >     ChangedFileSize 0 (0 bytes)
>         >     >     ChangedDeltaSize 0 (0 bytes)
>         >     >     DeltaEntries 0
>         >     >     RawDeltaSize 0 (0 bytes)
>         >     >     TotalDestinationSizeChange 372 (372 bytes)
>         >     >     Errors 0
>         >     >     -------------------------------------------------
>         >     >
>         >     >     [root@dev .cache]# LC_ALL="fr_BE" /bin/duplicity inc --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>         >     >     Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
>         >     >     Date de la dernière sauvegarde complète : Wed Mar  8 09:50:38 2017
>         >     >     GPGError: GPG Failed, see log below:
>         >     >     ===== Begin GnuPG log =====
>         >     >     gpg: chiffré avec une clef RSA de 2048 bits, identifiant BDABF623, créée le 2017-03-02
>         >     >     « ci (ci encryption key) <""> »
>         >     >     gpg: échec du déchiffrement : Pas de clef secrète
>         >     >     ===== End GnuPG log =====
>         >     >
>         >     >     The french output says:
>         >     >
>         >     >     "
>         >     >     gpg: encrypted with an RSA key of 2048 bits, id BDABF623, created on 2017-03-02 (march)
>         >     >     gpg: decryption failed, no secret key.
>         >     >     "
>         >     >
>         >     >     BDABF623 is the id of the subkey with id F747CAB9.
>         >     >
>         >     >     This is a server on which I just installed duplicity. I managed to do a full backup, then I tried
>         >     >        /bin/duplicity --full-if-older-than 15D  --encrypt-key 'F747CAB9' /backups rsync://rsync/duplicity/
>         >     >
>         >     >     but it failed (not finding the secret key, which it should not need). After some changing the environment to have
>         >     >     the output in english, I was surprised to see it work fine.
>         >     >
>         >     >     Here is some more info:
>         >     >
>         >     >     # duplicity --version
>         >     >     duplicity 0.7.11
>         >     >
>         >     >     # gpg --version
>         >     >     gpg (GnuPG) 2.0.22
>         >     >     libgcrypt 1.5.3
>         >     >     Copyright (C) 2013 Free Software Foundation, Inc.
>         >     >
>         >     >
>         >     >     Thanks
>         >     >
>         >     >     Rb
>         >     >
>         >     >     _______________________________________________
>         >     >     Duplicity-talk mailing list
>         >     >     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>> <mailto:[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>         >     >     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>>>
>         >     >
>         >     >
>         >     >
>         >     >
>         >     > _______________________________________________
>         >     > Duplicity-talk mailing list
>         >     > [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>         >     > https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>>
>         >     >
>         >
>         >     _______________________________________________
>         >     Duplicity-talk mailing list
>         >     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>         >     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk> <https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>>
>         >
>         >
>
>
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>
>
>
> --
> Web database: http://www.myowndb.com
> Free Software Developers Meeting: http://www.fosdem.org
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk