These issues were introduced in f8ccdc50. Because we no longer convert
everything to an io.BytesIO in _encrypt() with _make_binary_stream(),
all io.StringIO()s which are passed through must take encoded strings
and io.BytesIO()s must take bytes (and there is actually a difference
with Python3).
Additionally, there appears to be an issue where the `outstream` passed
to _copy_data() is sometimes a _io.BufferedWriter and other times an
encodings.utf_8.StreamWriter. I am not sure yet where this problem was
introduced. For now, the workaround for dealing with the Python3
bytes/str io.BytesIO/io.StringIO problem also provides a workaround for
this issue.
* FIXES#88.
* FIXES#89 for Python3.
* FIXES#93.
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
Isis Lovecruft
Thomas Tanner
Garrett Robinson
Viral Bajaria