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.
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
For some reason, in GnuPG>=2.x, a missing/corrupted trustdb is a fatal
error. This means that if the homedir was just changed, and any command which
utilizes keys is called (e.g. sign, encrypt, decrypt, etc.) GnuPG dies without
executing the command because we can't find a valid trustdb.
What's even more is that there is a new command in GnuPG>=2.x:
'--fix-trustdb'. You'd think it would, you know, *fix the trustdb*. Hah! Think
again! It prints out a series of shell commands (incorrect ones, at that, as
they don't respect the relevant env variables such as $GNUPGHOME) in a format
which is *not* exec'able (i.e. you can't do something similar to how
$ exec `ssh-agent`
is used). Software engineering, motherfuckers. #FML.
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 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.
* FIX Python3 error where a :class:`collections.OrderedDict` instance,
including it's keys() method, is not iterable.
* CLOSES PR#7 In Python 3 OrderedDict.keys() are not indexable
We could always cast counts.keys() to a list, from the dictionary view they
are but a more efficient way of doing this is to simply pop the items from
our result list as we traverse the returned iterable dictionary view.