Open MarSoft opened 7 years ago
Hi! Any further developments on this issue, or work-around or monkey patches figured out?
My app currently works on a server running gpg 2.0, but I am expecting the server to be upgraded any time now...
There is already support for using passphrases for other io calls so a quick work-around is straightforward:
- def import_keys(self, key_data):
+ def import_keys(self, key_data, passphrase=False):
result = self._result_map['import'](self)
log.info('Importing: %r', key_data[:256])
data = _make_binary_stream(key_data, self._encoding)
- self._handle_io(['--import'], data, result, binary=True)
+ self._handle_io(['--import'], data, result, passphrase=passphrase, binary=True)
data.close()
return result
This quickly solved my issue for importing secret keys with gpg >= 2.1
. You can still omit the passphrase for public key importing.
Note that there may still be issues with other key functionality like delete_keys, though list_keys is fine. A similar fix should be applicable.
Steps to reproduce:
/tmp/gh
gpg = gnupg.GPG(homedir='/tmp/gh')
gpg.import_keys("""my secret key data""")
Expected result: key should be import Actual result: key is not imported. Debug logs:
The
import_keys
call itself returns a successful result with all zeroes, as if there was no key in the data block passed.Background: According to this topic on gnupg site, since
gpg 2.1
it requires the user to either provide passphrase when importing secret key or to use--batch
mode. See the topic for details.So there could be two possible fixes:
--batch
mode when importing, like it is seemingly done inpython-gnupg
packagegpg.import_keys
, with some way to specify which of the should belong to which key.