Specifying a key by UID instead of key ID does not work when signing

Issue #1 resolved
Elena Grandi
created an issue

I'm not sure it is meant to be supported, but I've seen it used by a program and gnupg itself supports it: this is what I've done

import gnupg
gpg = gnupg.GPG(verbose=True)
k = gpg.list_keys(True)[-1] # this is a dummy key that I've created for some tests
# k['uids'] is  [u'Noname <valhalla@genesis>']
with open('some_file','rb') as signfile:
      signed_data = gpg.sign_file(signfile, keyid=k['uids'][0], detach=True)

signed_data.data ends up being empty; the command line as printed by the verbose option is:

gpg --status-fd 2 --no-tty -sa --detach-sign --default-key 'Noname valhalla@genesis'

with the following errors:

gpg: no default secret key: secret key not available gpg: signing failed: secret key not available

but when copypasted on the shell actually works and signs the data.

See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739907

Comments (6)

  1. Vinay Sajip repo owner

    It appears that quoting the keyid is what's causing the problem. Removing the shell_quote() call on the keyid seems to sort it out.

    Note that from 0.3.6 onwards, subprocess.Popen is called with shell=False, so it should be safe to not quote the keyid.

    However, using a uid is not a good idea (as it can be ambiguous), so should this really be fixed / supported?

  2. Elena Grandi reporter

    using a uid is not a good idea (as it can be ambiguous)

    That's what I wrote in the debian bug, and in this case I too believe that the proper fix should be in pyspread. I don't know if there is any other usecase when this behaviour could be useful and "safe" (I can't think of any).

  3. Log in to comment