* Change the returned _parsers.GenKey from gnupg.GPG.gen_key() to store the
location of the renamed temporary keyrings as attributes. This way, one can
do something like:
>>> key = gpg.gen_key(key_input)
>>> key.keyring
'./generated-keys/328A5C6C1B2F0891125ECBE4624276B5A2296478.pubring.gpg'
* Generated keys in separate keyring would not be available after switching
back to the normal keyrings (not the ones set up for key generation), so at
first in the unittests I imported them back into the main keyrings… this,
however, is would be stupid, as in nullifies half the reasons for using
separate keyrings in the first place, thus the code was commented out. Now
that the temporary keyrings are placed in the gnupg.GPG._generated_keys
directory, it would be nice to eventually either extend GPG.import_keys()
or add a new helper function for doing:
$ gpg --no-default-keyring --keyring pubring.gpg \
--keyring ./generated-keys/<some_fingerprint>.gpg
* Add GPG._generated_keys as an _utils.InheritableProperty class for storing
a configurable (even by subclasses of GPGBase, without property overrides)
subdirectory of whichever directory gnupg.GPG.homedir is set to. This
subdirectory can be used via the 'separate_keyring=True' option to
gnupg.GPG.gen_key_input(), which will switch temporarily to new pubring.gpg
and secring.gpg keyrings during key creation, and upon finishing creation
of the new key, will ask for the new key's fingerprint, and move the
keyrings into this GPG._generated_keys directory, renamed in the format
"<GPG.homedir>/<GPG._generated_keys>/<fingerprint>.[pub|sec]ring.gpg".
* Rename gpghome to homedir.
* Rename gpgbinary to binary.
* Add setting to append '--no-use-agent' to the command string in an attempt
to overcome bugs resulting on systems where the user has gpg-agent running
in the background (with some configurations, this is run before X is
started, and killing the agent can result in X dying) and GnuPG tries to
call the program specified by the symlink at /usr/bin/pinentry, result in
encryption and decryption failing due to the '--batch' option blasting
through pinentry without input. This results in a complaint from GnuPG:
gpg: Sorry, no terminal at all requested - can't get input
This bug also prevents symmetric encryption/decryption from working in a
similar manner.
Daniel Kahn Gilmor's monkeysphere, if I am recalling correctly, has a
hack to remove the $DISPLAY variable from the users environment, and then
add it back in, but frankly this option frightens me, as unsetting the
display could result in all X applications failing.
Werner Koch's suggestions, from the gnupg-devel mailing list are:
http://lists.gnupg.org/pipermail/gnupg-users/2007-April/030927.html
And, for the record, '--no-use-agent' doesn't disable pinentry.
* This should only be used in the unittests, as the PRNG it uses in GnuPG does
not create strong keypairs (though it's faster, thus why we're using it for
testing).
Isis Lovecruft