Duplicity

Attempting to sign with a non-existent key silently defaults to an existing key?

Asked by Jake Herrmann

It seems that attempting to sign a symmetrically encrypted backup using a non-existent secret key results in duplicity silently defaulting to an existing secret key. For example, the command:

duplicity --sign-key=aaaaaaaa src file://dest

works exactly as if I had specified an existing secret key (I think it defaults to the earliest-created key); it prompts for passphrases, accepts the passphrase for the existing key, and then when restoring from the backup, duplicity indicates that the backup was signed with the existing key.

I increased the verbosity to the highest level (debug) and ran the backup command again, but did not see any log messages to indicate that duplicity was intentionally defaulting to an existing key. Therefore this seems like a bug, but I thought I would ask before filing a bug report, in case this is intended behavior.

I'm running duplicity 0.7.11 on Debian GNU/Linux 9 (stretch), so I apologize if this has been fixed in a later release.

Note that this issue does not occur if attempting asymmetric encryption with --encrypt-sign-key, because gpg will simply fail with "No public key".

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
Jake Herrmann
Solved:
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Jake Herrmann (jtherrmann-deactivatedaccount) said : 		#2

Still wondering about this.

Revision history for this message
edso (ed.so) said : 		#3

duplicity is merely using the gpg command line binary.

would you mind to test what gpg does when given a non existent key? ..ede/duply.net

Revision history for this message
Jake Herrmann (jtherrmann-deactivatedaccount) said : 		#4

Thank you for the reply. I'm guessing the --default-key option for gpg is responsible for this behavior. From the man page:

"If there is no secret key available for any of the specified values, GnuPG will not emit an error message but continue as if this option wasn't given."

I tested this with the command:

gpg --default-key foobar --sign filename.txt

and confirmed that it defaults to an existing key. I didn't actually check whether duplicity uses gpg's --default-key option, but it seems very likely that this is the cause. Seems like odd behavior to me, but not duplicity's fault.

Revision history for this message
edso (ed.so) said : 		#5

as far as i can see your cmd line matches the parameters used by duplicity as well as the duply frontend. while checking i saw tat duply tests if te given secret is available in the keyring first, so using duply might be an option here.

..ede/duply.net

Revision history for this message
Jake Herrmann (jtherrmann-deactivatedaccount) said : 		#6

This isn't a critical issue for me, now that I'm aware of how it works. Thanks for the suggestion, though.