* lang/qt/src/threadedjobmixin.cpp (fromEncoding)
(stringFromGpgOutput): New helpers.
(markupDiagnostics): Use it.
--
The Problem is that on my western windows system GnuPG
gets CP 437 as GetConsoleOutputCP and prints in that codepage.
In a W32 GUI Application we get 0 as GetConsoleOutputCP and 1252
with GetACP.
The only thing that seemed to somehow match was GetOEMCP but
that might just be luck and it might still be broken in
other windows languages.
This code is also used in Kleopatra so it might make sense
to make it public once it is demonstrated that it works on
most systems.
* Complete typographic overhaul.
* Removed all section level indentation since it does not affect
output formatting, but might affect source code examples.
* In text-mode stripped out all tabs which had crept in and replaced
them with four spaces.
* Updated all code examples (again) to conform with Python-mode.
* Bumped version number in preparation for next release of GPG 2.2.9
and corresponding GPGME release.
* Apparently I am wrong and Scheme is the new Python after all.
* Non-import related PEP8 compliance must wait for another day, though
the other PEP8 fixes remain.
* Changed id/else statements to a more pythonic form from scheme
masquerading as python - sorry Justus, it had to go ;).
* With the added bonus of enabling PEP8 compliance in those sections.
* Fixed remaining PEP8 compliance issues with the exception of the
imports at the beginning of the file (changing those will break the
entire module, so we'll cope with it as it is).
* Bindings confirmed to work with the newly released 3.7.0.
* Updated M4 file to reflect this change and correct the Python binary
search order (3.7 is not yet given priority, but will still be found
first via the more generic python3 executable).
* Updated setup.py.in, bindings documentation and README to reflect this.
* Added a secret key export variant which saves output as both GPG
binary and ASCII armoured, plus saves in $GNUPGHOME and uses
multiple methods of determining what that location is.
* Example of default exporting keys.
* Example of exporting minimised keys.
* Example of exporting secret keys to a file with correct permissions.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* The holy grail: a function to export secret keys.
* GPGME will still invoke pinentry and gpg-agent as usual to authorise
the export.
* Mostly similar to the two previous export functions for public keys
except that it will return None if the result had a length of zero
bytes. Meaning that the difference between the specified pattern
(if any) not matching available keys and an incorrect passphrase is
not able to be determined from this function (or the underlying one
for that matter).
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Updated key_export and key_export_minimal to return None where a
pattern matched no keys in a manner simnilar to the possible result
of key_export_secret.
* Added functions for exporting public keys to gpg.core in both
complete form and in minimised form.
* Rather than letting people need to worry about the export modes we
are simply separating the functions as people would be more familiar
with from the command line usage anyway.
* Functions added for Context are: ctx.key_export_minimal and
ctx.key_export as the default or full export.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Fixed most of the PEP8 errors in core.py
* Those remaining may need more than little edits and are a bit
strange (too clearly the result of a programmer who has spent far
too much time dealing with Lisp so that for Python it looks
... strange).
* Wrapped the key import function in the try/exception statements
needed to catch at least the most likely unsuccessful import attempt
errors.
* Mostly draws on the file error and no data import statuses for
errors, with a couple of exceptions.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* The foundation of a pythonic key import function authored by Jacob
Adams.
* A unit testing script for the same function originally authored by
Tobias Mueller
* Added DCO reference for Jacob Adams to the GPGME AUTHORS file.
* Additional details regarding this patch are available here:
https://dev.gnupg.org/T4001
Signed-off-by: Ben McGinnes <ben@adversary.org>
* lang/cpp/src/context.cpp, lang/cpp/src/context.h
(Context::createKeyEx): New.
--
The createKeyEx function follows the usual pattern that the
synchronous call returns a result directly while for the
async an extra call is neccessary.
* Uses the groups module to prepare a list of recipients and encrypt
to those.
* The main version (encrypt-to-group.py) tries to check for invalid
recipients, but still falls back to always trust for the second
encryption attempt.
* The gullible version doesn't try pruning the recipient list at all,
it just tries to encrypt and if it fails, switches straight to
always trust.
* The trustno1 version doesn't use the always trust model at all and
only attempts pruning the list of invalid recipients.
* Another attempt at fixing the org-mode version.
* A proof reader ascertained there were tabs in it instead of whitespace.
* Stripped the lot out and replaced with standard 4 spaces, fixed
every incorrect example ... and it still breaks upon save and/or export.
* Added the reference to the mutt-groups.py script to demonstrate the
groups.py module/code.
* lang/cpp/src/data.h, lang/cpp/src/data.cpp (Data::rewind): New.
* lang/qt/tests/t-various.cpp (testDataRewind): Test it.
--
The advantage of this convieniance function in GPGME is that
it avoids the messiness that are declarations with off_t.
GnuPG-Bug-Id: T3996
* Added a script which demonstrates how the groups module works.
* Script generates Mutt/Neomutt crypt-hooks for every group entry in
gpg.conf, including those entries for multiple keys (Mutt handles
that differently).
* Fixed the groups.py script so it really does what is described (the
old code had the same result for groups, group_lines and
group_lists).
* Updated the corresponding example in the doc to match.
* Updated the decryption example code in the HOWTO and the
corresponding decrypt-file.py script to gracefully handle a
decryption failure. This error will always be triggered when GPGME
is used to try to decrypt an old, MDC-less encrypted message or
file.
* Changed the expiration date for the generated test key to NYE this
century, rather than the NYE this millennium as originally suggested
in job #3815.
* This covers the lifetimes of current users (except, maybe, some very
healthy millennials) as well as the 32-bit clock end date in 2038;
without falling foul of OpenPGP's 2106 expiration.
* src/qgpgmenewcryptoconfig.cpp (QGpgMENewCryptoConfigEntry::urlValue):
Build url from local file.
(QGpgMENewCryptoConfigEntry::setURLValue): Set native seperated
path.
--
This fixes setting files through cryptoconfig on Windows.
GnuPG-Bug-Id: T3939
* lang/python/setup.py.in: Copy gpgme.h instead of parsing it.
--
The python bindings tried to parse deprecated functions
out of gpgme.h. This fails for the current gpgme.h in
that it removes an entire field in the key sig struct (_obsolete_class).
Hence, the fields were off by an int and the bindings accessed struct
members via the wrong offset. That caused python program to crash.
At least on 32bit platforms, the crash can be easily triggered by
accessing key.uids[0].signatures. On 64bit platforms the compiler
probably aligns the struct so that the missing 4 bytes are not noticed.
With this change, the python bindings will expose all functions
that gpgme exposes, including the deprecated ones.
Credits go to Justus Winter for debugging and identying the issue.
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
GnuPG-bug-id: 3892
