| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
A few new flags were added to gpg 2.3.8+, and the new "R"
flag(Restricted encryption) broke tests.
See also gnupg commit 0988e49c45.
|
| |
|
|
|
|
|
|
|
| |
Before, if you set the GPG executable using call(), and the
version was different from the version used in the constructor,
GnuPG::Interface would pass the wrong options to the program.
This patch makes sure the executable and the version number
are always in sync.
|
| |
|
|
|
|
|
| |
At least as of gpg 2.1.11, gpg --list-secret-keys did not include the
key fingerprint by default. This change adds a new secret key list to
compare against in the test. It also migrates the key list versioning to
a numbering scheme instead of using GnuPG branch names, like 'modern'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The modern GnuPG suite encourages the use of gpg-agent to control
access to secret key material. In this use case, we avoid setting an
explicit passphrase in code, and rely on either a correctly-configured
and primed gpg-agent or a dedicated pinentry program to supply the
passphrase.
This additional test verifies that the passphrase can be handled by
the agent. Note that the passphrase for this additional test key is
*not* the default passphrase, so this test should fail in the event
that gpg can't use the agent and the pinentry for this task.
Unfortunately, this all assumes that we're using GnuPG "Modern". I've
noted concerns about writing forward- and backward-compatible bindings
for GnuPG here:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031800.html
|
| |
|
|
|
|
| |
Adding a new secret key with a different passphrase should allow us to
differentiate between passing the passphrase explicitly and relying on
the agent + pinentry.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The human-readable version of --list-keys is *not* expected to be
static over time or as the user's environment changes (e.g. LANG or
LC_MESSAGES), so expecting it to be machine-parseable is probably a
mistake.
That said, some users might want to pull textual information about
specific keys to display directly to the user, so it's not a terrible
idea to have it in the test suite.
Modern GnuPG (2.1 or later) changes the default structure of the
human-readable output in a few significant ways:
* it writes the path to the keyring as an absolute path, even if
$GNUPGHOME is set to a non-absolute path.
* it shows the calculated user id validity by default (see
show-uid-validity in gpg's --list-options). (note that this is a
translated string, so that "unknown" (in the default C locale)
becomes "inconnue" when LANG or LC_MESSAGES is set to fr_CH.UTF-8,
for example.
* it writes the key algorithm names differently (e.g. rsa2048 instead
of 2048R)
* it does not display the key ID at all by default
* it displays the full fingerprint in compact form by default
This changeset fixes the test suite so that it can do a rough
verification of the human-readable text output by list_secret_keys in
the C locale in modern versions of GnuPG, while leaving it working for
older GnuPG suites.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test suite currently assumes it knows something about the internal
state of GnuPG's homedir.
It's safer and less brittle to rely explicitly on the public interface
that GnuPG has committed to, such as --import-keys and --list-keys,
rather than assuming that certain files are in certain places in the
GnuPG homedir.
It's also better to create a fresh homedir and allow GnuPG to populate
it during the test suite, cleaning it up at the end, rather than hope
that GnuPG will leave a pre-existing homedir untouched.
With this change, many more of the tests pass when /usr/bin/gpg is
provided by GnuPG 2.1.
|
| | |
|
| | |
|
| |
|
|
|
| |
but some tests still fails
|
|
|
from the source forge only
|
