Make --sign-key less picky; about case, length and 0x marker

[Andreas Olsson]

Currently duplicity is a lot more picky about the key format it accepts for --sign-key compared to --encrypt-key, or gpg in general. The eight character long key id can only include upper case A-F, and may not include the hexadecimal marker 0x.

The check is performed by this this method, in ./duplicity/commandline.py

def set_sign_key(sign_key):
    """Set globals.sign_key assuming proper key given"""
    if not len(sign_key) == 8 or not re.search("^[0-9A-F]*$", sign_key):
 log.FatalError(_("Sign key should be an 8 character hex string, like "
                         "'AA0E73D2'.\nReceived '%s' instead.") % (sign_key,),
                       log.ErrorCode.bad_sign_key)
    globals.gpg_profile.sign_key = sign_key

The --encrypt-key on the other hand doesn't seem to do any such syntax checking.

Unless there is a specific reason to only allow the key id in upper case, and disallowing the 0x marker, would it be possible to make the set_sign_key method a bit less picky? Perhaps by changing the if line to one of the following alternatives?

    if not len(sign_key) == 8 or not re.search("^[0-9A-Fa-f]*$", sign_key):
or
    if not re.search("^(0x)?[0-9A-Fa-f]{8}$", sign_key):

In neither case can I see it breaking the existing format, nor introducing any additional disambiguity.

[Tim Ruffing (8-public)]

Note also my additional comments in #1215031.

[Lars Kellogg-Stedman (larsks)]

I just ran into this because my GPG is configured to use long format keys, which look like:

  0x7BF065CD97112F06

This is rejected by duplicity due to to check described in the original comment. Duplicity should probably accept long format key ids.

[Andreas Olsson (andol)]

Yeah, I agree regarding long format as well as fingerprint.

Here is a suggested fix which allows for case insensitive short format, long format alt full fingerprint; with or without the 0x prefix.

https://bazaar.launchpad.net/~andol/duplicity/signkeyformat/revision/1012#duplicity/commandline.py

No, the regex isn't as elegant as I would have liked, but still better than any alternative I could see.