* CHANGE behaviour so that `gnupg.GPG.binary_version` is set in
`gnupg._meta.GPGBase.__init__()`, instead of `gnupg.GPG.__init__()`.
* ADD new `gnupg._meta.GPGBase._check_sane_and_get_gpg_version()`
method, and move logic for doing a sanity check on the binary and
getting the binary's version, which was previously in
`gnupg.GPG.__init__()`, into this new method.
* ADD an additional field for the `binary_version` to the logger call
which displays initialisation settings when `gnupg.GPG.__init__()`
is run.
They are only effective if the binary is GnuPG>=2.0.x anyway, and the
extra code to change the method names depending on the underlying
binary will cause clutter for anyone using python-gnupg.
This change is backwards compatible with python-gnupg<=1.3.1, since the
private methods (e.g. `gnupg.GPG._create_trusttb`) are kept intact.
This bug caused some extra behaviours which should only be invoked if
the user is using a gpg2 binary. It was caused by checking:
if _util._is_gpg2:
which is always true, since `_util._is_gpg2` is a function which isn't
being called in this case, i.e.:
>>> def foo(): return False
>>> bool(foo)
True
So instead this should be changed to actually call `_util._is_gpg2()`,
by using `gnupg.GPG.is_gpg2()` which will automatically pass in the
detected binary version number.
In the method `gnupg.GPG.verify_file()`, the `writer` was improperly
initialised: `_util._threaded_copy_data` was being given a filename when
it expects an open `file` object which it can read() from. Additionally,
the `writer` parameter was missing from the call to
`gnupg.GPG._collect_output()`, so even if it had been properly
initialised, the output would not have been written to the stdin of the
thread GnuPG was being called within.
We should only add these methods (or rather, link them to their corresponding
functions in the gnupg._trust module) if using GnuPG>=2.x.
* ADD --export-ownertrust and --import-ownertrust functionality.
* ADD patch by Mikael Nordfeldth to file python3 syntax compatibility due to
the 'file' builtin being removed.
isinstance(foo, file) → hasattr(foo, 'read'), or,
file = _io._IOBase
* CLOSES issue #13.
https://github.com/isislovecruft/python-gnupg/pull/13
* CHANGE default key type to RSA for older GnuPG versions, since they seems
to not understand using a 'default' key type.
* UPDATE docstring for GPG.gen_key_input().
* ADD functions _util._match_version_string(), _util._is_gpg2(), and
_util._is_gpg1() for determining whether to set the default Key-Type to
'default' (for GnuPG v2.x) or to 'RSA' (for GnuPG v1.x).
* ADD class attribute GPG.binary_version, which stores the GnuPG executable's
version string, which should be in the form x.x.x, where 'x' is an integer.
* ADD docs/change-license-emails.txt, which includes email exchanges between
myself and intrigeri, including links to Debian and LEAP mailing lists with
arguments for and against using AGPL for a library.
* CHANGE license header for all files.
* CHANGE LICENSE file and gnupg/copyright.py to use GPLv3+ text.
* 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
* 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
Ruben Pollan
drebs
Thomas Tanner
Matt Behrens
Kali Kaneko
Garrett Robinson
Mikael Nordfeldth