* Include _ansistrm.py, which was released under new BSD license separately in
a github gist as well as in the Python logutils module. Instead of setting
up a src/includes/ directory, I have included this file in the currently
flat module directory, because dealing with submodule imports in Python2.x
is a pain. I'm not sure if this will cause problems for Debian packaging,
but it could be changed later if so. The full text of the original license
and copyright has been retained at the head of _ansistrm.py, clearly
demarcated from python-gnupg's license and copyright info. The author of
_ansistrm.py is the same as the current upstream maintainer for
python-gnupg, Vinay Sajip, and I don't see why this person doesn't include
_ansistrm.py in all of their packages, because it is making skimming the
test logs for errors much faster.
* Add _logger.py, which contains a class decorator:
@wraps(logging.Logger)
def create_logger(level=logging.NOTSET)
[...]
which autoconfigures logging functionality. By default, logging.NullHandler
is still used, so there are no logs (neither logfiles nor piped to
stdout). If _logger.create_logger() is called with either a LEVEL attribute
from the logging module, or the integer equivalent, it will initialise
logging to stdout only. In the unittest suite, extra log handling
functionality is added to also write to a datetime-stamped logfile in the
tests/ directory.
* Change all "logger.<level>" statements to "log.<level>" and add new ones for
debugging and user information purposes.
* Remove the import of the python standard utilities logging module from:
src/gnupg.py
src/parsers.py
src/util.py
and switch to setting a top-level attribute, util.log, which is the returned
class from _logger.create_logger(). Everything else now does "from util
import log".
* Github has these rather nasty tracking mechanisms through pixel cookies, as
well as hardware fingerprinting (potentially deanonymising) through HTML5
canvases.
* I suck at configuring gitweb + lighttpd. I cannot get pretty URLs for the
repos, but it's still better than the pixel cookies. If anyone can point me
at something for fixing this, much obliged. I wasn't sure if I should point
explicitly to a LEAP server.
* Previously, it was:
In [1]: import gnupg
In [2]: gnupg.
gnupg.GPG gnupg.copyright gnupg.logger gnupg.util
gnupg.copyleft gnupg.gnupg gnupg.parsers
So I've started cleaning up the API so the only thing visible on module import
is the class you probably need: gnupg.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