* lang/python/docs/GPGMEpythonHOWTOen.org: Added corresponding GPGME
version number to table at the start and cut the shortcut from the
groups.py example.
* doc/gpgme-python-howto.texi: New export of Texinfo file for docs
build.
* gpgme.spec.in: Added gpgme-python-howto.info build on the grounds
that it now deals with certain possible installation issues and end
users encountering them would want the docs to hand.
* doc/gpgme.texi: updated the copyright year to this year.
* Added doc/gpgme-python-howto.texi: generated from
GPGMEpythonHOWTOen.org and then slightly modified so the generated
Info file doesn't use camelCase.
* doc/Makefile.am: Updated makefile to include the Python HOWTO with
gpgme_TEXINFOS and to export the generated files to the webserver
along with the main GPGME one.
* lang/python/docs/GPGMEpythonHOWTOen.org: Fixed a few errors in the
newer sections.
* Updated code in the examples using secret key exporting and group
lines to reflect the Python 2.7 compatibility fixes added.
* lang/python/examples/howto/export-secret-keys.py and groups.py:
Updated the backwards compatibility adjustments to account for
unicode differences between python 2 and 3.
* lang/python/examples/howto/groups.py: subprocess update
* lang/python/examples/howto/export-secret-keys.py: subprocess update
Both of these try the nice and easy method of getting the subprocess
output available in Python 3, but will fall back to the older Popen
method if it doesn't work. Essentially this is to be a little nicer
to Python 2.7.15 (even though the examples are filled with warnings
that py2 support is not guaranteed with the examples).
* Egon Spengler was right, crossing the streams is bad.
* Restored both src/gpgme.def and src/libgpgme.vers to use the
estreams symbols without the leading underscore.
* The new_from_estream() function added to lang/python/src/core.py and
set to alias the new_from_stream() function remains.
* Opted for the solution favouring Linux onthree main grounds:
1. Andre reported major problems with Windows as well, so the number
of potentially affected systems would vastly increase.
2. All the BSDs and OS X have spent far more time and development
work in order to accommodate the eccentricities of both Microsoft
and the GNU Project (ref. GCC), so they're more likely to be able
to cope with doing so again than the other way around.
3. If I really have to I can write a custom installer for OS X to
try this and, if it fails, to then patch the two symbol entries and
recompile from scratch. That said, I may not have to since it
actually behaved during the most recent tests for this
commit; into ten separate CPython installations and all five
supported versions (standard source installs and OS X Framework
installs for each version).
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
--
* src/Helpers.js: GPGME_Keys were not parsed as valid, as their
fingerprint getter is not a fingerprint 'property'.
* BrowserTestExtension: fixed a dsplay typo in counting of tests.
* It turns out that even though some platforms detect differing
symbols for estreams, the two types do not appear to be in
conflict. At least they don't from the BSD/OS X side of things.
As a consequence both versions are now included.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
--
* BrowsertestExtension/tests/decryptTest.js: There were cases in which
file names returned in a wrong encoding from decryption. The test
cases here are a 'Hello World' in a text file with different names,
then being encrypted with cli gnupg.
--
* src/Helpers.js: This additional escape should 'repair' special
characters like spaces in filenames. In the strange world of
encoding there is little hope that this captures all cases, or
that it will never fail to return some value, let alone meaningful.
In my test cases it worked.
--
* BrowserTestExtension/tests:
- decryptTest.js: Check Decryption and return values of binary data
- encryptTest.js: Return data type of armored/non-armored encryption
- added a small encoded input png for testing
* DemoExtension/maindemo.js: Fixed unexpected usage of the Demo encrypt
(non-armored)
--
* src/gpgme.js: In case the encryption was done unarmored, the result
is binary data. Added an option to either return the binary data as
base64-encoded string or as Uint8Array, similar to return values of
decrypt
--
* src/Connection.js; src/permittedOperations.js: To avoid further
encoding problems, data sent by gpgme is now sorted as either
'payload' or 'info'. Payload data may come in any encoding, and here
the 'expected' and 'format' options are used, 'info' data may
contain text created by gnupg which may need re-encoding, but this
should not be affected by 'expected' and 'format'
* lang/python/src/core.py: Adjusted new_from_estream function to alias
new_from_stream instead of fd.
* fixed the _gpgme import errors introduced in commit
08cd34afb7 by changing the exported
functions/types to match the inner module where all the work is
done, rather than the outer one(s).
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
--
* src/gpgmejs.js/encrypt: the encrypted data were converted back to a
(incorrect) string, whereas they should be data with no encoding
specified. Returning base64 data is the expected way.
* DemoExtension: caught yet another usage of old syntax.
* src/gpgme-json.c (op_verify): Only create output and
use it for clearsigned and opaque signed.
--
Just passing output to gpgme_op_verify changes the behavior to
no longer do a verify of the signature.
* lang/python/docs/GPGMEpythonHOWTOen.org: Updated links to the
ProtonMail keyserver import scripts and added a warning regarding
being unable to update third party keys.
* lang/python/examples/howto/pmkey-import-alt.py: added usage.
* lang/python/examples/howto/pmkey-import.py: added usage.
* src/gpgme-json.c (op_delete): Delete primary key on
subkey gen error.
--
This can happen for example if the user cancels the
pinentry to unlock the primary key when adding the
subkey. To avoid an artifact of a pimary key without
an encryption capable subkey we delete the created
key and treat the whole operation as failed.
* src/gpgme-json.c (encode_and_chunk): Don't error on NULL
request.
--
This fixes the error that is passed when parthing the json
object failed and request would be NULL.
Instead of the JSON parser error it would otherwise report
that encode and chunk failed.
--
* src/Helpers.js: As non-payload data might come in different
encodings, a conversion has been introduced that worked in most
cases. Data like the userid might come in different encodings,
which we don't know of. For now, a try..catch returns the data
as they are if the utf-8 decoding fails. Sometimes this yields the
correct result, sometimes it may not work, but it won't stop the
whole operation anymore.
--
* destructuring just takes the input argument and treats it as object.
In cases like in src/Keyring/generateKey, where I forgot to change
the old syntax, the fingerprint as string was destructured into an
object without "pattern", which caused all Keys to be retrieved.
So, methods with a destructuring now check if the first argument is
an object and get a default empty object if no parameter is
submitted. This allows the further use of destructured parameters,
while still ensuring nothing vastly incorrect is used.
* src/Kering.js, unittsets.js: fixed old syntax in method usage
* src/gpgme-json.c (verify_result_to_json): Remove "file_name".
--
Having the file name in the verify result may lead developers to
assume that the file name is covered by the signature. This is not
the case and can easily be checked by hex-editing a signed message.
We better don't output it at all.
The same is true for the is_mime flag but that is anyway only an
advisory and I can't see damage from a faulty one.
Note that we keep file_name in gpgme's output for ABI stability and
because some tools want to display meta information even if they are
subject to tampering. This is similar to the non-encrypted subject in
mails.
Signed-off-by: Werner Koch <wk@gnupg.org>
--
* src/Connection.js: resulting data, if not pure ascii, is base64
encoded in the result message. A further decoding attempt into
javascript 'string' will be attempted by default, unless specified
at the decrypt() method. The return value 'format' now shows which
of the possibilities has been applied. The old boolean 'base64'
now turns into format:'base64' if the returned payload is a base64
string after decryption.
--
* reflecting the new optional strings accepted by the backend.
'file_name' and 'sender' can be used via the 'additional'
parameter in encrypt operations
--
* recent changes in parameter calling led to a forgotten internal call
in getDefaultKey using old syntax (and failing in case a default key
is configured)
--
* src/gpgmejs.js: Setting the default to 'always trust' assumes that
most api users will already have made their internal checks, but may
not have the gnupg web-of-trust model implemented, thus trusting the
key themselves, without gnupg having full or even any information.
Still it should stay an option to have gnupg decide.
--
* src/Keyring.js: Adapted Keyring.getDefaultKey() to my current
understanding of a default signing key: either the default key set
in the gpg config, or 'the first usable private key' - usability
meaning 'not invalid, expired, revoked, and can be used for
signing'. It should be the same key used as in command line when
doing a --sign operation.
In case the user has a smartcard plugged in, we currently
won't know of this here, so our choice may differ. But as we do all
javascript-binding sign operations with the key fingerprint
explicitly set, this should not be a real problem. This method is
seen more as a convenience to tell using librarys which key
represents the main user.
