js: decoding of information

--

* 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.

js: add tests

--

* 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)

js: add encoding parameter for encrypt return

--

* 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

js: separate gpgme answer by type of data

--

* 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'

python bindings: estreams fix

* 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
  08cd34afb762975b0273575035dacf69449ef241 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>

js: return base64 after encrypt with armor=false

--

* 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.

python bindings: core

* lang/python/src/core.py: expanded gpgme_error check lists.

python bindings: core

* lang/python/src/core.py: added gpgme_data_set_flag to the errorcheck
  funtion.

python bindings: core

* lang/python/src/core.py: added new function new_from_estream to wrap
  new_from_fd just like new_from_stream does and for the same reason.

json: Fix detached verify

* 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.

docs: python bindings - protonmail examples

* 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.

Merge branch 'master' of ssh+git://playfair.gnupg.org/git/gpgme

docs: python bindings HOWTO

* Finished CFFI vs SWIG bit in known issues.
* tidied up some of the structure.
* Fixed some minor errors and links.

docs: python bindings

* Added section on why no CFFI.

docs: python howto

* Added another key import example using ProtonMail's new keyserver.

json: Delete primary key if subkey gen fails

* 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.

json: Allow NULL request in encode and chunk

* 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.

docs: python bindings

* Added details on installation troubleshooting.

js: small documentation update

--

js: make non-payload data more encoding-tolerant

--

* 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.

js: typecheck destructured parameters

--

* 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

json: Do not put FILE_NAME into the verify result.

* 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>

doc: Add warning that FILE_NAME is not part of the signed data.

--

js: extend information on decoding in decrypt

--

* 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.

js: fix file_name return on decrypt

--
* src/gpgmejs: Line 228 checked the wrong variable. To avoid further
  confusion, _result was renamed to returnValue in the whole file

core: Export gpgme_data_new_from_estream function.

Signed-off-by: Werner Koch <wk@gnupg.org>

js: add new options to permittedOperations

--

* reflecting the new optional strings accepted by the backend.
  'file_name' and 'sender' can be  used via the 'additional'
  parameter in encrypt operations

json: Add sender and file name to encrypt

* src/gpgme-json.c (hlp_encrypt, op_encrypt): Support sender
and file_name.

js: fix syntax inside Keyring methods

--

* 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)

js: offer an always-trust parameter on encrypt

--

* 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.

js: use destructured option parameters

--
* Adds to f0409bbdafcbd4f8b0be099a6b3ce0d5352c9bcd and makes use of
  destructuring, allowing for defaults, and cleaning up the
  validation.

js: update getDefaultKey to more precise logic

--

* 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.

js: add decrypt result options

--

* As a decrypt result cannot be known beforehand, the decrypt operation
  may add an 'expect' property, taking either 'uint8' or 'base64',
  which will return the decrypted data in the appropiate formats.
  the return property 'format' will give a feedback on which option
  was taken.
  A test was added to reflect these changes.

js: make method parameters objects

--

* As requested by using parties, the options to be passed into the
  methods are now objects, with the objects' properties better
  describing what they do, and to avoid the need to type several nulls
  in a method call if one wants the last parameter.
  - src/Keyring.js, src/gpgme.js: Changed parameters and their
    validations
  - BrowserTest/*.js Had to adapt quite some calls to the new format

js: improve decryption performance

--
* src/Connection.js, src/Helpers.js: performance of decoding incoming
  base64 data was improved to about 4 times the speed by introducing
  two more efficient functions (thanks to rrenkert@intevation.de for
  finding and testing them)

* src/gpgmejs.js: Decrypted data will now return as Uint8Array, if the
  caller does not wish for a decoding. Decoding binary data will return
  invalid data, and a Uint8Array may be desired. This can be indicated
  by using the (new) 'binary' option in decrypt.

* src/Errors.js A new error in case this decoding fails

* src/Message.js, src/Connection.js: expected is change from base64
  to binary, to avoid confusion later on.

js: Return error if signature has no fingerprint

--

* src/Signature.js/get fingerprint: A signature with no fingerprint
  should not happen, but if it does, we should throw an error here,
  as the method is a getter.

Merge branch 'javascript-binding'

This adds a new language binding "gpgme.js" to GPGME. It
serves as a bridge between the native-messaging service "gpgme-json"
and JavaScript Applications.

The first user of this binding will be Mailvelope which will
see GnuPG integration in the near future.

GnuPG-Bug-Id: T4107

js: changed verify signature result infos

--

* the resulting information of verify now are as documented,
  and the same as in a decrypt callback

js: throw errors in sync functions

--

* synchronous functions should throw errors if something goes wrong,
  Promises should reject. This commit changes some error cases that
  returned Error objects instead of throwing them

  - src/Key.js: createKey() and sync Key.get() throw errors
  - src/Error.js: Exporting the list of errors to be able to test and
    compare against these strings
  - src/Keyring.js: Setting a null value in pattern is not useful, and
    now caused an error with the new changes.
  - src/Message.js: createMessage and Message.setParameter now throw
    errors

js: update decrypt/verify results

--

* src/gpgmejs.js: Decrypt now parses additional optional dec_info
  information, as well as any verify information, if present

* src/permittedOperations: Now decrypt also expect the new return
  object dec_inf (containing info such as is_mime and file_name)

js: remove outdated checklists

--

* They are heavily outdated and offer no more useful information

json: Add proper decrypt_result_t handling

* src/gpgme-json.c (recipient_to_json, decrypt_result_to_json):
New.
(op_decrypt, hlp_decrypt): Update.

--
The op_decrypt as one of the first operations did not yet
match the current 1 <> 1 mapping of gpgme types to json
dictonaries.

info and dec_info are bad names but used for compatibility reasons.

js: Fix library name mentioned in js Makefiles

--

js: Update extra_dist files

* lang/js/BrowserTestExtension/Makefile.am,
lang/js/Makefile.am (EXTRA_DIST): Update.

Add example manifests for gpgme-json

* doc/examples/gpgme-chrome.json, doc/examples/gpgme-mozilla.json: New.
* doc/Makefile.am (EXTRA_DIST): Include them.

--
The id contained in the examples is the ID of Mailvelope.

js: Improve README

* lang/js/README: Clarify structure at the beginning.

Remove js as language from configure.ac

* configure.ac: Remove js language.

--
It does not make much sense to integrate gpgme-js into the
GPGME build system. gpgme-js will be distrbuted by it's users
as part of the web extensions / their distribution as that
is the JavaScript way.

So they can use their tools etc. to compile gpgme-js JavaScript
style, which is documented in the lang/js folder.

js: set expiry of generatedKey to seconds from now

--

* src/Keyring.js: Changed key ecpiration from Date to seconds from
  creation, as in gpgme. The Date parameter used before was due to a
  misunderstanding in documentation and requests from potential users.

js: add option "subkey-algo" to generateKey

--

* The option was recently added to gpgme-json; this reflects this on
  javascript side

js: set expiry date on generateKey

--

* on the javascript side a Date is expected, gpggme-json expects
  seconds from 'now'

json: Add subkey_algo and defaults to createkey

* src/gpgme-json.c (op_createkey, hlp_createkey): Add subkey_algo
handling.
(hlp_createkey): Fix documentation of expiry.
--
Due to the funny quick-gen-key interface generating a key
with an explicit algo would result in bad defaults (only an SC key),
without a subkey.

This adds handling that should probably be in GnuPG proper to fix
the semantics of createkey by adding default subkey_algo handling.

js: add and apply eslint rules

--

* mainly spacing, see .eslintrc.json for details

js: revert changes to class read/write restriction

--

* undoes 94ee0988d4eaac27785de6efb7c19ca9976e1e9c and
  e16a87e83910ebb6bfdc4148369165f121f0997e.
  I do not fully understand why my approach was bad, but I am not in
  a position to argue. This revert was requested to me after a review,
  and I'm doing it in the assumption that more experienced people know
  better than me.
* unittests: Also changed some outdated tests that stopped working
  since 754e799d35fd62d7a979452f44342934659908c7 (as GPGME_Key is not
  exported, one cannot check for instanceof in the tests anymore)

Python bindings examples

* import-key.py: fixed a minor typo.
* pmkey-import.py: locates and imports keys from the ProtonMail keyserver.
* pmkey-import-alt.py: the same as the previous except with setting an
  alternative $GNUPGHOME directory.

Python bindings setup file

* Moved the build import back up where it belongs.
* Included comments indicating how to build and install for multiple
  Python versions beyond the first 2 on the same system.

Python bindings tests: Near PEP8 compliance

* PEP8 compliance for the vast majoeity of the tests.

Python bindings examples: PEP8 conpliance

* Appears to be complete compliance.

Python bindings setup: Near PEP8 compliance

* lang/python/version.py.in: Fixed most things, but there's still an
  issue near the build portion with the existing Python bugs referenced.
* lang/python/setup.py.in: Now PEP8 compliant.

Python bindings constants: PEP8 compliance (almost)

* PEP8 compliance for all constants except the globals in
  src/constants/__init__.py depending on whether the import sequence
  affects the globals themselves.

Python bindings src: PEP8 compliance

* import namespace clearance for src/*.py.
* Fixed a handful of is/is not None checks as well.

js: decode arriving gpg message strings

--

* Arriving strings (i.e. user id names, error messages) are not
  always in javascript encoding. This is an attempt to go through
  the whole gpgme answer (with the exception of payload data) and
  to fix the encoding of these

js: correct decrypt result info (2)

--

* the permittedOperation from last commit ended up in the wrong place.
  sign does not return an additional 'info' object.

js: expect additional 'info' to arrive on decrypt, too

--

* src/permittedOperations.js: if decrypt includes a verification,
  this info needs to pass, too.

js: decrypt callback is_mime fix

--

* src/gpgmejs: is_mime should report its' counterpart. Also,
  file_name is not optional in specification. We'll send null if
  there is no file_name

js: don't expire new keys if no date is set

--

* src/Keyring.js A new Key without expiration is documented as
  'never expire' here, and should behave accordingly. This requires
  sending '0' here.

js: small documentation fix

--

js: removed Key.armor property in synchronous use

--

* src/Key.js The synchronous mode for a Key does not offer an armor/
  armored property anymore. This frees up a lot of performance issues,
  also the armored expoort is expected to change quite often, so a
  cached version is not advisable.

* hasSecret/getHasSecret is now refactored, to reflect their uses.
  With get('hasSecret') there is a method that fetches the result.

* src/Key.js also some refactoring

js: disallow bulk set data on key from outside

--

* src/Key.js Key class is not exported anymore, as it should not be
  used directly anywhere. setKeyData is no more a method of the Key,
  (optional) data are now validated and set on Key creation and on
  updates, both from within this module, thus no longer exposing
  setKeyData to the outside.
* createKey now gained an optional parameter which allows to set Key
  data at this point.

js: importKey feedback refactor

--
* src/Keyring.js: An empty result should no longer cause an error,
  the import feedback summary has been refactored slightly
* Browsertests to reflect import feedback change

js: fix import feedback

--
* src/Keyring.js For Key imports without prepare_sync the import
  feedback was lacking the summary

js: avoid async getters

--

* src/Key.js get armored was returning a promise on async keys.
  As getters should not do that, it returns an error in this case.

js: wrong object assumed in recent commit

--

* src/Keyring.js I wrongly assumed an object to be a GPGME_Key,
  it was the raw answer from nativeMessaging instead. Now it returns
  a GPGME_Key again.

js: get default key fixes

--

* src/Keyring.js: The answer was not parsed correctly, so a config was
  being ignored.

* If no config is set, we return the first non-invalid key with a
  secret, instead of the first key (which may be e.g. an expired one)

js: simplify getDefaultKey

--

* src/Keyring.js: In case no default Key is set in configuration,
  only Keys reported as having a secret part should be considered
  for default Keys, avoiding some extra requests.

js: consistently return uppercase fingerprint

--

* src/Key.js: the fingerprint returned by a Key is now always upper
  case hex, even if the constructor had lower case input. This is to be
  more consistent with gpgme and to be more readable and reliable in
  comparisions.

Symmetric example

* lang/python/examples/howto/symcrypt-file.py: *sigh*; passphrase was
  right the first time, just the error check that wasn't.
* I really should stop second guessing myself one of these days ...

Signed-off-by: Ben McGinnes <ben@adversary.org>

Symmetric encryption example

* lang/python/examples/howto/symcrypt-file.py: Fixed the error code
  and the passphrase key word arg.

Symmetric encryption example.

* lang/python/examples/howto/symcrypt-file.py: A variation on standard
  key based encryption.

PEP8 compliance and other code fixes

* Ran all the .py files in src/ and below through Yapf.
* Included some manual edits of core.py, this time successfully making
  two notorious sections a bit more pythonic than scheming.
* Left the module imports as is.
* This will be committed if it passes the most essential test:
  compiling, installing and running it.

Signed-off-by: Ben McGinnes <ben@adversary.org>

Link fixes

* lang/python/README: Fixed links in both versions of the README.

json: Wipe memory in cJSON_Delete

* src/cJSON.c (cJSON_Delete): Wipe memory on deletion.

json: Only use calloc instead of malloc

* src/cJSON.c, src/gpgme-json.c (CALLOC_ONLY): New define
to change xmalloc / xtrymalloc to use calloc.

--
Some people consider malloc dangerous as it might allow an
information leak.

json: Add checks when skipping byte

* src/cJSON.c (parse_string, cJSON_Minify): Check for
terminating NULL byte when skipping the byte after a an escaped
quote.

json: Don't error out if chunksize is omitted

* src/gpgme-json.c (encode_and_chunk): Don't error out
if no chunksize is provided.

--
This fixes 82e4b900a96c837392259469a9a5821a95e7a707 which
caused every call without chunksize to error out.

cpp: Fix use after free in gencardkeyinteractor

* lang/cpp/src/gpggencardkeyinteractor.cpp
(GpgGenCardKeyInteractor::Private::keysize): Change to string.

--
The value is only required as string so we can save it this
way to avoid the need to convert it for the action command.

GnuPG-Bug-Id: T4094

Make GNUPGHOME for tests overridable

* lang/python/tests/Makefile.am,
lang/qt/tests/Makefile.am,
tests/Makefile.am,
tests/gpg/Makefile.am,
tests/gpgsm/Makefile.am,
tests/opassuan/Makefile.am (GNUPGHOME): Make variable explict.

--
If the build directory has too long path, gpgme could fail.
This is similar to

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206

In order to fix that, this patch extracts the GNUPGHOME variable
to be presented directly in the Makefile and thus overridable by
command line option.

A build system can then create a symlink to the GNUPGHOME directory
in /tmp and use that symlink as the GNUPGHOME directory
thus making the path very short.

GnuPG-Bug-Id: T4091

Patch provided by vlmarek

js: make init export immutable

--

* src/index.js: The export now uses a freezed Object, which does not
  allow for simply overwriting the init method by e.g. a third-party
  library.
* BrowsertestExtension: Added some tests trying if decryption of bad
  data properly fails

js: fix confusion about loop in last commit

--

* The aim is to iterate through the results of the first request
 (all keys), and then add the propert 'hasSecret' to those that
  are in the second request (secret Keysring)  as well. I messed
  this up in a recent change, and it escaped testing.

js: Fix Key.hasSecret answer

--

* The comparision result between Keyring and Keyring with secrets was
  set to the wrong Object which was not returned at all.

js: Making objects inmutable

--

* An Object.freeze should stop any malicious third party from changing
  objects' methods once the objects are instantiated (see unittest for
  an approach that would have worked before)
  - An initialized gpgmejs- object doesn't have a '_Keyring' property
    anymore (it still has its 'Keyring')
  - The internal expect='base64' needed to be turned into a method.

js: fix indentaion

--

* doing the indentation changes that became neccesary in the last
  commit.

js: change the write access for js class methods

--
* src/ [Connection, Error, Key, Keyring, MEssage, Signature, gpgmejs]:
    Functions and values that are not meant to be overwritten are now
    moved into their constructors, thus eliminating the possibility of
    overwrites after initialization.

* Key: The mode of use (synchronous cached, or async promises) ivs now
  determined at initialization of that Key. The property Key.isAsync
  reflects this state.

* unittests: fixed old Key syntax for testing.

* Message.js isComplete is now a method and not a getter anymore.

* Added some startup tests.

js: clean up test extension

--

Tests will now run with one instance of gpgmejs each block,
which reduces overhead. Readability is (hopefully) improved),
some negative tests are added.

There is still a performance problem in base64 encoding/decoding,
which causes some tests to fail due to time out.

js: include armored Key in import callback

--

* The import answer now also directly contains the armored Key as Key
  property, without need to refresh the Key object created in the
  answer. This allows for direct comparision of input and output.
* BrowserTestExtension: added test for that import callback

js: Fix wrong encoding in received error messages

--

* The libgpg error strings arrive in the browser in a different
  encoding than used by browsers. Escaping and then decoding it
  should cover most languages in the supported browsers.

cpp: Add safety checks for key update

* lang/cpp/src/key.cpp (Key::update): Check that the key is
not NULL.
* lang/cpp/src/verificationresult.cpp (GpgME::Signature::key):
Check for fingerprint.

docs: python bindings howto

* Fixed and tested the changes necessary for org-mode to correctly
  parse pythonic (Python 3) indentation.
* Updated the source blocks to recommended upper case for BEGIN_SRC
  and END_SRC.
* Tested and confirmed XHTML output matches correct examples.
* Tested against pseudo-control output via exporting from org-mode to
  org-mode and then exporting that to XHTML.  Remaining differences
  appear to be discarding the custom tags used to provide X[HT]ML id
  elements to each section which does not appear to offer any benefit.
* Exporting directly to XHTML or other HTML output should no longer
  cause problems, but if there are any then the first step should be
  exporting from org-to-org and then exporting that to XHTML.

Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>

doc: python bindings howto

* Another retrofitting of the HOWTO Python example code, this time
  following adjustments to python-mode configuration and having
  trawled through the org-mode mailing lists for clues.

doc: python bindings howto

* Added org-mode byline.

js: repair BrowserTextExtension test

--

* the signed message to verify was signed by a wrong test key