* At some point, as mentioned in an earlier commit, we should actually make
some sort of helper function for adding extra keyring, so that their keys
can be used/imported/exported/whatever the user wants to do with them,
without changing the normal main keyrings.
* To import, the same 'import gnupg; gpg=gnupg.GPG' is still used, so this
changes nothing for applications which have started using this fork.
* This name appears to be untaken on PyPI, the changes I've made thus far are
significant, and, I believe, are not entirely backwards compatible with
upstream, do to various keyword argument and method renamings and such.
* Upstream is unresponsive, their development is private, and the only way to
get their code is to download an entire tarball and do a diff, since no
public CVS is available. Also, looking at their recent releases in the past
five months, they appear to be fixing bugs I've already fixed, albeit in
different ways -- and not all of the bugs I've fixed, as the shell escape
trick still works in upstream's 0.3.4 version -- which leads me to believe
that they are generally oblivious to this fork, though I have tried to
contact them several times.
* At first, I merely bumped the major version number up to indicate the
incompatibility, but in order to upload to PyPI it would need a different
name, and so I might as well pick a new one and just go with it, in order
to avoid the general confusion which might result from keeping the name
'python-gnupg'.
* 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".
* The proper way to do this is to upgrade globally with the get_pip.py script
and the distribute_setup.py script, and then create the virtualenv with:
$ . $(which virtualenvwrapper.sh)
$ WORKON_HOME=~/.virtualenvs && export WORKON_HOME
$ mkvirtualenv -a $PWD -r requirements.txt --unzip-setuptools \
--distribute --no-site-packages gnupg
Isis Lovecruft
Tom Galloway