`GPG.encrypt_file` was refactored into `GPG.encrypt` in 295d98f, which
broke the functionality of `GPG.encrypt_file` for encrypting file-like
stream objects such as StringIO, BytesIO, etc.
The main difference between `GPG.encrypt_file` and `GPG.encrypt` is that
`GPG.encrypt` first converts its `data` argument into a binary stream
via `_make_binary_stream`. This is unnecessary when the argument is
already a stream, as was often the case in calls to `GPG.encrypt_file`.
Additionally, `_make_binary_stream` typically fails when it attempts
to encode a stream object, which means it is no longer possible to
achieve the functionality of `GPG.encrypt_file` with `GPG.encrypt` after
the refactor.
This commit only converts `data` to a binary stream if it is not already
a stream, re-using `_util._is_stream` to make that determination.
* 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
Isis Lovecruft
Thomas Tanner
Garrett Robinson
Charles Duffy
Ruben Pollan
drebs
Matt Behrens
Kali Kaneko
Garrett Robinson
Mikael Nordfeldth