| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
The two main reasons are
- to run `python3 -m unittest discover` without specifying a custom
`--pattern *_test.py`
- to include the test files automatically when generating the MANIFEST
file.
|
|
|
|
|
|
|
|
|
| |
Some distro (notably debian and derived distros like ubuntu) still
package the obsolete gpg 1.x series as "gpg", and provide the modern
gpg 2.x tool as "gpg2". Other distros don't package gpg 1.x anymore, but
most seem to provide a gpg2 symlink, so this should be safe for them.
This is verified working on Archlinux, and is required to make these two
tests work on Ubuntu 16.04 Xenial.
|
|
|
|
| |
They are not needed for python >= 3.0.
|
| |
|
|
|
|
|
| |
Commands running in a subprocess should return the terminal encoding so
we don't need to guess their encoding.
|
|
|
|
|
|
|
|
| |
The crypto code shouldn't use unicode strings, it should use byte
strings. The problem with using unicode strings (and doing the
conversion internally), is that the crypto code doesn't know what the
encoding should be. We can guess but it's better to just do bytes in
bytes out, and let the calling code deal with encoding and decoding.
|
|
|
|
|
|
| |
This makes me a little nervous. I wonder if we're better off leaving the
bits that gpg works with as bytes while gpg is working with them and do
the string transformation later.
|
|
|
|
|
|
| |
This function is always passed a key to sign with, and not passing one
leads to the first available signing key in the keyring being selected
otherwise, which is problematic if one has two signing keys.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This converts from the now abandoned pygpgme project for wrapping gpgme,
to the upstream gpgme python bindings (which are descended from the pyme
project, before they became official).
Largely this change should not be user visible, but there are a couple
cases where the new bindings provide slightly more detailed error
messages, and alot directly presents those messages to users.
This patch has been significantly revised and updated by Dylan Baker,
but was originally authored by Daniel Kahn Gillmor.
Fixes #1069
|
|
|
|
|
|
|
|
|
|
|
| |
'z', the value currently passed to get_key isn't a valid value, so it
raises GPGMEError with a code of INV_VALUE. However, if an actual email
is passed a KeyNotFound exception is raised instead.
The existing test is valid and should remain, since it catches a
potential bug, but it doesn't test for a missing key, it tests for an
invalid key. This patch renames the existing test and adds a new test to
cover an actual missing key.
|
|
|
|
|
| |
This adds two new tests for the list_keys function that assert that the
private flag is honored.
|
| |
|
|
|
|
|
|
| |
This covers mosts of the functions in the crypto module, but doesn't
bother with the hash_key function, which is slated for deletion in the
port to python-gpg. It also doesn't cover re-raising errors.
|
|
|
|
|
|
|
|
|
|
| |
gpgme.Context.verify doesn't raise an exception, instead it attaches the
error as an attribute of the return value. This means that we've been
returning that a signature is valid even when it isn't.
This patch checks the attribute instead of try/excepting. Because there
is a second bug (fixed in the next patch) signature verification will
always fail with this patch.
|
|
|
|
|
|
|
|
| |
This adds a couple of basic tests for the signing and verification of
signatures code in the crypto module. This relies on the utilities
module introduced in the last patch.
One of the tests in here is expected to fail
|
|
|