* 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.
* src/gpgme.h.in (_gpgme_op_decrypt_result): Add flag
legacy_cipher_nomdc.
* src/decrypt.c (parse_status_error): Set this flag.
* tests/run-decrypt.c (print_result): print it.
(main): Print the result even on error.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/engine-gpg.c (read_status): Remove the handling of
GPGME_STATUS_END_STREAM; this was used only by the former experimental
--pipemode of gpg but that is not even anymore invoked here.
(struct engine_gpg): Remove cmd.linked_data and .linked_idx.
(build_argv): Remove code for linked_data.
(gpg_new): Ditto.
(gpg_set_command_handler): Remove arr linked_data.
* src/engine-backend.h (engine_ops): Remove arg data from
set_command_handler.
* src/engine.c (_gpgme_engine_set_command_handler): Remove arg
linked_data and adjust all callers.
Signed-off-by: Werner Koch <wk@gnupg.org>
--
* src/Keys.js
- made setKeyData more consistent with other methods
- added convenience methods (Key.armored, Key.hasSecret)
- Added a Key delete function
* src/Keyring.js:
- added a getkeysArmored which allows for bulk export of public Keys
gpgmejs:
- removed deleteKey. It is now a method of the Key itself
- Encrypt: Added some common options as parameter, and the
possibility to set all allowed flags via an additional Object
* 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
--
* implementing Keyring methods:
- Keyring.getKeys: has an additional option that retrieves the armor
and secret state once at the beginning. This is power hungry, but
allows for Keys to be used directly (without querying gpgme-json
each call)
* permittedOperations.js: reflect recent changes in the native
counterpart, adding more options
* Key: adding two methods for retrieving the armored Key block and
for finding out if the Key includes a secret subkey.
--
* After an operation a connection should be disconnected again.
The "end of operation" is now assumed to be either an error as
answer, or a message not including a "more"
* GPGME, GPGME_Key, GPGME_Keyring don't require a connection
anymore
* Message.js: The Message.post() method will open a connection as
required
* src/gpgme-json.c (op_export, op_delete): Return GPG_ERR_FORBIDDEN if
"secret" is used.
--
This should not be possible from a browser and we need to make this
fully clear. Actually gpg-agent won't allow that anyway but having
this explicitly is better.
If that is ever needed a dedicated command line option may enable
this, for example when used by regular programs and not by the browser.
But that requires other changes as well.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme-json.c (create_onetime_context): New.
(release_onetime_context): New.
(op_sign): Use the new fucntions to create a separate context.
(op_encrypt): Use a separate context for key listings.
(create_keylist_patterns): Remove unneeded cast.
--
get_context retruns a static per-process context and can thus not be
used as a separate context. Use dedicated fucntions for this.
Signed-off-by: Werner Koch <wk@gnupg.org>
--
* Keys can now be queried for information. Onne version queries gnug
directly (asynchronous Promise in javascript terms), the cached
version refreshes on demand.
* Small fixes:
src/Connection.js joins answers that stay json properly now
* src/gpgme-json.c (op_encrypt): Add optional signing_keys param.
(get_keys, create_keylist_patterns): Add param for json object name.
--
If the optional parameter signing_keys is provided to encrypt
it becomes an encrypt-sign operation.
* src/gpgme-json.c (add_summary_to_object): Changed to:
sigsum_to_json.
(add_signature_to_object): Changed to signature_to_json.
(add_signatures_to_object): Changed to verify_result_to_json.
(add_ei_to_object): Changed to engine_info_to_json.
(op_decrypt, op_verify, op_version): Use new functions.
--
This pattern of gpgme_type to json object conversion
is much cleaner then the error returning "add to object"
functions.
* src/gpgme-json.c (xjson_AddStringToObject0)
(xjson_AddItemToObject): New helpers.
(sig_notation_to_json, key_sig_to_json, tofu_to_json)
(uid_to_json, subkey_to_json, key_to_json): New
GPGME to JSON functions.
(op_keylist): New.
(process_request): Add op_keylist.
--
The conversion from GPGME data structures to
JSON follow the same pattern for the keylist
functions using the xjson wrappers instead
of error checking every cJSON call.
For large keylists the keylist command also
needs a data / getmore handling somehow.
* gpgme-json.c (get_string_data): New.
(op_verify, op_sign, op_decrypt, op_encrypt): Use it.
--
This handles the common base64 decoding and creation of the
gpgme_data object.
--
* src/Connection.js: isConnected was renamed to checkConnection, that
returns a promise with either version information or Boolean
* Connection checks have been adapted to reflect that checkConnection
returns a Promise
* BrowsertestExtension: tests/signTest.js was missing from my last
commit
* 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.
* src/gpgme-json.c (gpg_error_object): New.
(error_object_v): Extend to take error.
--
Having the error code is helpful, especially as
the strerrors are localized. E.g. to detect
an ERROR_CANCELED.
* src/gpgme-json.c (op_verify): New.
(hlp_help): Add verify.
(process_request): Add verify.
--
Mostly works, except for detached, base64 encoded signatures,
they are somehow not yet written to gpgme.
* src/gpgme-json.c (add_signatures_to_object): Fix call to
xjson_CreateArray.
--
That is what happens if you edit code while reviewing changes,
without testing it again,..
* 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.
--
* Uint8Arrays are not supported for now there are unsolved issues in
conversion, and they are lower priority
* encrypt gains a new option to indicate that input values are base64
encoded
* as decrypted values are always base64 encoded, the option base64 will
not try to decode the result into utf, but leave it as it is
* src/w32-util.c (_gpgme_get_gpg_path): Use new defines.
(GNUPG_REGKEY_2): x64 aware regkey as used by GnuPG in Gpg4win 2.x
(GNUPG_REGKEY_3): x64 aware regkey as used by GnuPG in Gpg4win 3.x
(_gpgme_get_gpgconf_path): Use new regkeys. Add another fallback.
--
This should fix more "unsupported protocol" issues if Gpg4win /
GnuPG is installed in a non standard path on 64bit systems.
The regkey handling is similar to that of gpgex and gpgol.
GnuPG-Bug-Id: T3988
* src/decrypt.c (struct op_data_t): Add field not_integrity_protected.
(parse_decryption_info): Set this. Also rename mode to aead_algo for
clarity.
(_gpgme_decrypt_status_handler): Force failure in case of a missing
MDC.
--
This extra check makes sure that a missing or stripped MDC in
- gpg < 2.1
- or gpg 2.2 with an old cipher algorithm
will lead to a decryption failure. gpg 2.3 will always fail in this
case. Implementing this check here and not backporting the 2.3 change
to 2.2 has the benefit that all GPGME using applications are protected
but scripts relying on rfc2440 (i.e. without MDC) will only break when
migrating to 2.3.
Note that S/MIME has no integrity protection mechanism but gpgsm
neither emits a DECRYPTION_INFO status line, so an error will not be
triggered. If in the future gpgsm supports authenticated encryption
it may issue a DECRYPTION_INFO line to force a failure here but it
will in that case also emit a DECRYPTION_FAILED anyway.
GnuPG-bug-id: 3981
Signed-off-by: Werner Koch <wk@gnupg.org>
--
* Some assumption on messages were wrong. Now the tests use more
reasonable sizes.
* bigString now uses the full utf8-extent, with the exception of
U+0000. This code gets dropped during the encryption-decryption
process.
