Comment 0 for bug 1714663

Example:

valentin@computer:~/tmp$ duplicity --encrypt-sign-key 0CED0054 data file:///tmp/backup
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase:
GnuPG passphrase for signing key:
No signatures found, switching to full backup.
--------------[ Backup Statistics ]--------------
StartTime 1504351535.91 (Sat Sep 2 14:25:35 2017)
EndTime 1504351536.11 (Sat Sep 2 14:25:36 2017)
ElapsedTime 0.20 (0.20 seconds)
SourceFiles 5
SourceFileSize 2202713 (2.10 MB)
NewFiles 5
NewFileSize 2202713 (2.10 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 5
RawDeltaSize 2202707 (2.10 MB)
TotalDestinationSizeChange 2207511 (2.11 MB)
Errors 0
-------------------------------------------------

valentin@computer:~/tmp$ mv data data.2
valentin@computer:~/tmp$ mkdir data
valentin@computer:~/tmp$ duplicity --encrypt-sign-key 0CED0054 file:///tmp/backup data
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sat Sep 2 14:25:32 2017
GnuPG passphrase:
Volume was signed by key FC7C18370CED0054, not 0CED0054
valentin@computer:~/tmp$

Another example:

valentin@computer:~/tmp$ duplicity --encrypt-sign-key 0CED0054 verify file:///tmp/backup data --compare-data
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sat Sep 2 14:25:32 2017
GnuPG passphrase:
Difference found: File . has mtime Sat Sep 2 14:25:53 2017, expected Sat Sep 2 14:03:07 2017
Volume was signed by key FC7C18370CED0054, not 0CED0054
valentin@computer:~/tmp$

It is not clear that the duplicity is actually verifying signatures with the same key (FC7C18370CED0054 is just a long name of the same key - 0CED0054) or giving up on this.

The user is not informed properly what duplicity is doing when it encounter this error.

Also, this can be prevented by using the full fingerprint of the key (when user enter the short name the duplicity can find the long fingerprint and use it).