Adds additional commonly used stream classes from the standard library
to `_util._is_stream`. This means these classes can be used successfully
wherever `_is_stream` is used to decide whether or not to encode data
throughout the codebase, including in `_encrypt`.
`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.
This fixes an issue reported by @adulau on Github where importing KeyA
and asking for the ``ImportResult.fingerprints`` would list KeyA's
fingerprints, and then importing KeyB and asking for the
``ImportResult.fingerprints`` would list both KeyA and KeyB's
fingerprints.
This was caused by a side effect resulting from the
``ImportResult.fingerprints`` being a class-level attribute, which gets
modified by the first call to ``gnupg.GPG.import_key()``, causing later
instances of ``ImportResult`` to retain the side effect. This commit
causes the ``ImportResult`` class to be indempotent under sequential
composition calls to ``gnupg.GPG.import_keys()``, ultimately resulting
in listing, upon each key import attempt, only the fingerprints of the
keys which were listed *that* time.
* FIXES Issue #81https://github.com/isislovecruft/python-gnupg/issues/81
Windows doesn't have EUIDs, so instead we'll check that the usernames
match. This doesn't seem the least bit secure to me, but it's Windows so
they're probably owned anyway. If anyone knows one of the "proper" ways
to determine if another process has the same owner on Windows, I'd love
to know about it.
* FIXES Issue #58 but I don't have a Windows machine to test so maybe
it's still broken.
https://github.com/isislovecruft/python-gnupg/issues/58
This code was broken: Half of it required `options` to be a string, and the
other half required `options` to be a list (which the tests enforced, but the
constructor would silently drop for normal-path initialization).
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'`).
Isis Lovecruft
Thomas Tanner
Garrett Robinson
Viral Bajaria
Charles Duffy
Tom Galloway
Ruben Pollan