It seems that more modern versions of Python (e.g. 2.7.8), doing:
from __future__ import print_function
print("SIG=%s" % sig)
with some binary data doesn't actually produce a UnicodeDecodeError,
which means that Python2 is slowly getting less retarded. :D
On the downside, we probably shouldn't have been testing for things
which are Python2.x mis-design issues (and not really our fault, nor a
bug in python-gnupg) anyway.
Existing code gives up searching for a GnuPG executable (returning None --
contrary to the docstring indicating that a RuntimeError will be thrown in all
cases where no binary can be found) if the first item found is a symlink or is
not accessed via an absolute path.
This refactored version moves the filtering logic down into the _which helper
-- and thus continues to search past unacceptable results -- even if the first
item found is not acceptable.
Parsing such messages would change documented behavior (which specifies a
limited set of messages, not conforming with the given status codes). Ignoring
them is thus the safer change.
* FIXES and issue discovered by ttanner (https://github.com/ttanner)
in `gnupg._meta.GPGBase._check_sane_and_get_gpg_version()` where the
GnuPG process wasn't closed and its file descriptors were left
hanging.
* FIXES part of Issue #63.
https://github.com/isislovecruft/python-gnupg/issues/63
There were so many hanging FD issues when I started patching
upstream python-gnupg ― I doubt I found all of them. I probably even
introduced some along the way. And, as ttanner pointed out, this
patch doesn't fix the issue fully, so there are likely more.
* ADD new `gnupg._meta.GPGBase._set_verbose()` method, which will set
`'basic'` as the default `--debug-level` for GnuPG, if the user did
something weird like specifying `verbose=True` or typoing one of the
string levels (e.g. `verbose='guruu'`).
* 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.
They aren't required to be ≤ 9, as the previous check in
`gnupg._meta.GPGBase._make_args()` ensured. That is, calling GnuPG from
the commandline, doing:
$ gpg --debug-level=100000 …
is valid, so we should also accept 10000 (even though everything > 8
means the same debug level anyway).
for some reason, the count was accessed as if it was a Storage
instance, and it's not, it behaves as a dictionnary
includes test case that will fail with the original code
* ADD test_encryption_to_filename which checks that encrypt(...,
output='somefilename.gpg') works correctly (when `output` is a string
containing the filename).
This tests for the bug reported in Issue #24.
https://github.com/isislovecruft/python-gnupg/issues/24
* FIXES Issue#24, which prevented python-gnupg from encrypting to a
filename given as a string to the `output` parameter of
`gnupg.GPGMeta._encrypt()`.
* THANKS TO by Bill Buddington of SecureDrop and Yan Zhu of the
Electronic Frontier Foundation (EFF) for finding and reporting the
bug. The ticket for this bug can be viewed at:
https://github.com/isislovecruft/python-gnupg/issues/24
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.
Isis Lovecruft
Charles Duffy
Kali Kaneko
Antoine Beaupré
drebs
Les Aker
Thomas Tanner
Matt Behrens