* src/context.h (gpgme_context): Add new flag for extended-edit.
* src/engine-gpg.c (append_args_from_sig_notations): Add flags to
control the kind of notations.
(gpg_edit): Respect extended-edit and notations.
(gpg_encrypt_sign, gpg_sign): Update call to
append_args_from_sig_notations.
* src/gpgme.c (gpgme_set_ctx_flag, gpgme_get_ctx_flag): Support
extended-edit.
* NEWS, doc/gpgme.texi: Mention extended-edit.
--
This provides a way to get the extended key-edit interface without
breaking bad state machines that rely on the current command flow.
A use case for this is to enable multiple local signatures, which
can be used together with annotations for:
GnuPG-Bug-Id: T4734
* src/context.h (gpgme_context): Extend with trust_model.
* src/engine-gpg.c (engine_gpg): Extend with trust_model.
(gpg_set_engine_flags): Take trust_model from context.
(build_argv): Handle trust_model.
(gpg_release): Free trust_model.
* src/gpgme.c (gpgme_set_ctx_flag): Handle trust-model flag.
(gpgme_release): Release trust-model.
* doc/gpgme.texi: Document new flag for gpgme_set_ctx_flag.
(Context Flags): New subsection for the context flags.
* tests/run-keylist.c (show_usage, main): Add new --trust-model
parameter.
--
This gives a GPGME user fine grained control over the
trust-model.
Changing the trust model for only a single application depends
on:
GnuPG-Bug-Id: T4134
Maniphest Tasks: T4134
Differential Revision: https://dev.gnupg.org/D466
* conf/: New dir.
* configure.ac (AC_CONFIG_HEADER): Move header to conf dir.
* doc/Makefile.am (mkdefsinc): Adjust rule.
* lang/python/Makefile.am (copystamp): Ditto.
--
C++ uses those stupid files without a suffix and thus the new standard
header <version> as included by newer other libc++ versions may
conflict with the VERSION file in out top directory. This change
should solve the problem.
GnuPG-bug-id: 4168
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/Makefile.am: Removed a bit I forgot about.
* Renamed lang/python/docs to lang/python/doc bvecause apparently
automake cares about that too.
* Decided to be extra explicit in the manifest because if I don't then
all sorts of things get deleted ... like lang/python
* Tested on an external linux system just in case my osx workstation
introduces too much weirdness.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* doc/Makefile.am: removed the python howto from this file, restoring
it to just the main project and the newer .js files.
* deleted: doc/gpgme-python-howto.texi
* renamed the Short_History.org file to short-history.org to keep the
naming conventions similar.
* All the Python files can (and should) live together.
* Changed the order of python versions the configure/make process
checks for, placing Python 3.7 ahead of 3.6.
* Updated the HOWTO documentation to reflect this change.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Tightened up the docs a little bit, updated the "what's new"
section, dropped the "-draft" version in preparation for GPGME
1.12.0's release.
* Exported another .texi version (and updated the draft copies to this
commit (which ought to be 1.11.1-beta313).
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Sometimes you really do need or want punctuation in a heading, but
ideally without something else generating whitespace and other
annoyances to go with it.
* Trying a real decimal point instead.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Woumd up the "what's new" section.
* Added an example for sending a key to the keyservers via hkp4py.
* Updated the export key code to use a more complete check for the
$GNUPGHOME location.
* Expanded on the installation and reinstallation troubleshooting
section.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Added a What's New section to summarise changes since the last
release. There have been quite a few and some attention does need
to be drawn to some of them.
* Confirming certain issues with some platform builds, especially
BSD/OSX vs. Linux issues which will need to update the installation
troubleshooting guides.
* Added more comprehensive examples using hkp4py and added a couple
more example scripts for protonmail.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Mostly tightening up the details on the hkp4py example script.
* Also fixed a typo in the LGPL boiler plate text included in all the
other example scripts for the HOWTO.
* added a new example script to search the keyservers and import the
results, this time using Marcel Fest's hkp4py module.
* Updated the key importing section to match this addition.
* Tested with the current version of hkp4py from github.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Confirmed that updates to the tests have significant'y improved that
output.
* Updated some of the additional notes for the section on hkp4py.
** This is in anticipation adding at least import examples using that
module as well. It may also include adding examples of exporting a
key and uploading it to the keyservers.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Added some material on using the new-ish hkp4py module with GPGME.
* Example code will be added later once a couple of little issues are
addressed.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Sanitized the shell command examples of extraneous whitespace.
* Removed keycount.c as sanitising it is pointless and it will be
generated by Cython when the example is followed.
* Regenerated the .texi version.
* Added new advanced section with an example of using the Python
bindings with CPython code compiled back to C code using Cython.
* Though it may seem a bit counter-intuitive to use the bindings just
to go back to C via a different route, this is not actually stupid.
* Added examples/howto/advanced/cython/ directory.
* Added keycount.pyx, setup.py and the keycount.c file which the first
two generated with Cython. Not including the .so and .o files from
the build.
* Exported the .texi version of the howto for the main docs.
* lang/python/docs/gpgme-python-howto.org: more tweaks and edits,
along with another build of output formats.
* doc/gpgme-python-howto.texi: updated texinfo version for parent docs.
* 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.
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
* 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.
* src/gpgme.h.in (gpgme_data_new_from_estream): New.
* src/data-estream.c: New.
* src/data.h (gpgme_data): New union member e_stream.
--
The estream functions (gpgrt_fopen et al.) are any waypart of the
required libgpg-error library and thus it makes sense to provide this
convenience interface.
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/gpgme.texi (GPGME_KEYLIST_MODE_EXTERN),
(GPGME_KEYLIST_MODE_LOCATE, GPGME_KEYLIST_MODE_LOCAL): Mention
command line flags for CMS and OpenPGP Protocol.
--
This might help new users coming to gnupg to understand what
the flags do.
* src/engine-gpg.c (engine_gpg): Add diagnostics member.
(gpg_release): Release diagnostics data.
(gpg_new): Set up logger-fd and diagnostics.
(gpg_getauditlog): New. Copy diagnostics to a user data.
(engine_ops): Add getauditlog.
* src/engine-gpgsm.c (gpgsm_getauditlog): Return not implemented
for GPGME_AUDITLOG_DIAG.
* src/getauditlog.c (getauditlog_start): Don't reset engine
for diagnostics.
* src/gpgme.h.in (GPGME_AUDITLOG_DIAG): New.
(GPGME_AUDITLOG_DEFAULT): New alias to 0.
* tests/run-decrypt.c (show_usage, main): Add --diagnostics.
* doc/gpgme.texi(Additional Logs): Document getauditlog.
--
This enables users of GPGME to get more verbose information
from gpg which can assist users in figuring out a problem
that was before hidden behind a generalized error like
"Decryption Failed".
For GPGSM it is not yet available as it is problematic to
get it properly in server mode and GPGSM already had the
original audit log mechanism in place.
GPGME_AUDITLOG_DEFAULT was added for a more explicit
documentation.
* 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/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>
* src/op-support.c (_gpgme_parse_plaintext): Add arg r_mime.
* src/decrypt.c (_gpgme_decrypt_status_handler): Ser mime flag.
* src/verify.c (_gpgme_verify_status_handler): Ditto.
* src/gpgme.h.in (gpgme_op_verify_result_t): Append fields 'is_mime'
and '_unused'.
(gpgme_op_decrypt_result_t): New field 'is_mime'. Shrink '_unused'.
* tests/run-decrypt.c (print_result): Print MIME flag.
* tests/run-verify.c (print_result): Ditto.
--
Note that this flag (Liternal Data packet's 'm' mode) is only
specified in RFC-4880bis. To use it you currently need to add
"rfc4880bis" to the the gpg.conf.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/engine-gpg.c (append_args_from_recipients_string): Add new
flags.
--
Now you can use gpgme to encrypt without first importing a key.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/engine-gpg.c (struct engine_gpg): New flag.offline.
(gpg_set_engine_flags): Set it. Also fix setting of no_symkey_cache.
(build_argv): Pass --disable-dirmngr in offline mode.
--
GnuPG-bug-id: 3831
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.h.in (gpgme_op_encrypt_ext_start) New.
(gpgme_op_encrypt_ext): New.
(gpgme_op_encrypt_sign_ext_start): New.
(gpgme_op_encrypt_sign_ext): New.
* src/libgpgme.vers, tests/run-encrypt.c: Add them.
* src/encrypt.c (encrypt_start): Add arg recpstring.
(gpgme_op_encrypt): Factor code out to ...
(gpgme_op_encrypt_ext): new function with new arg recpstring.
(gpgme_op_encrypt_start): Factor code out to ...
(gpgme_op_encrypt_ext_start): new function with new arg recpstring.
* src/encrypt-sign.c (encrypt_sign_start): Add arg recpstring.
(gpgme_op_encrypt_sign): Factor code out to ...
(gpgme_op_encrypt_sign_ext): new function with new arg recpstring.
(gpgme_op_encrypt_sign_start): Factor code out to ...
(gpgme_op_encrypt_sign_ext_start): new function with new arg
recpstring.
* src/engine-backend.h (struct engine_ops): Change fields encrypt and
encrypt_sign.
* src/engine.c (_gpgme_engine_op_encrypt): Add arg recpstring and pass
to engine.
(_gpgme_engine_op_encrypt_sign): Ditto.
* src/engine-gpg.c (append_args_from_recipients_string): New.
(gpg_encrypt): Add arg recpstring and call new function as needed.
(gpg_encrypt_sign): Ditto.
* src/engine-gpgsm.c (set_recipients_from_string): New.
(gpgsm_encrypt): Add arg recpstring and call new function as needed.
* src/engine-uiserver.c (set_recipients_from_string): New.
(uiserver_encrypt): Add arg recpstring and call new function as
needed.
* tests/run-encrypt.c (xstrdup): New.
(main): Add option --keystring.
* src/gpgme-json.c (get_keys): Simplify.
(op_encrypt): Modify to make use of the extended encrypt function.
--
This new feature can be used to avoid the need for a key lookup and
thus several extra calls to the backend.
Note that run-test uses a semicolon as delimiter because that make
testing the feature on the command line much easier.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.h.in (_gpgme_op_import_result): Move new field
'skipped_v3_keys' to the end.
--
The ABI break has not made it into a release.
Also document the new field.
Fixes-commit: a630a1e3e7
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/data.c (_gpgme_data_new): Check for failed selftest.
* tests/run-support.h (make_filename): Print a message on mallooc
failure.
(init_gpgme_basic): New.
* tests/run-identify.c (main): Call init_gpgme_basic becuase we do not
need to setup a protocol.
* tests/t-data.c: Define PGM and include run-support.h.
(make_filename): Remove.
(main): Call init_gpgme_basic.
--
Note: This patch may break applications which used gpgme_data but no
gpgme_new without having called the required gpgme_check_version.
GPGME can be used without a protocol for example to work with the data
object abstraction. Thus a call to gpgme_data_new also needs to check
the result of the core selftests - including on whether
gpgme_check_version has been called.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.c (gpgme_set_ctx_flag, gpgme_get_ctx_flag): New flag
"auto-key-retrieve".
* src/context.h (gpgme_context): New field auto_key_retrieve.
* src/engine-backend.h (struct engine_ops): Add arg auto_key_retrieve
to field 'decrypt'.
* src/engine-gpg.c (gpg_decrypt): Add arg auto_key_retrieve and pass
option --auto-key-retrieve to gpg. Adjust all callers.
(gpg_verify): Ditto.
* src/engine-gpgsm.c (gpgsm_decrypt): Add dummy arg auto_key_retrieve.
* src/engine-uiserver.c (uiserver_decrypt): Ditto.
* tests/run-verify.c (main): Add option --auto-key-retrieve.
--
This makes the --auto-key-retrieve option available in the GPGME API.
Test plan:
Run
GPGME_DEBUG=9:out tests/run-verify SIGNEDFILE
with and without its new option --auto-key-retrieve and check in the
trace stored in "out" whether --auto-key-retrieve was passed to gpg.
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/gpgme.texi (since): New macro. Use it to add version
information to those APIs that are mentioned in the NEWS file.
Signed-off-by: Marcus Brinkmann <mb@g10code.com>
GnuPG-bug-id: 3137
* src/decrypt.c (op_data_t): Add flag any_no_seckey.
(_gpgme_decrypt_status_handler): Consult that flag.
(_gpgme_decrypt_status_handler): Set that flag.
--
The NO_SECKEY is emitted instead of an "S ERROR pkdecrypt_failed" if
gpg knowns that a key has been encrypted to that key (cf. "S ENC_TO").
it is not fool proffof but in the majority of cases we can provide a
better error message than just DECRYPTION_FAILED.
GnuPG-bug-id: 3270
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/gpgme.texi (Passphrase Callback): Mention pinentry_mode and
restrictions.
(Pinentry Mode): Fix wording and clarify versions that need
loopback mode for passphrase_cb to work.
* configure.ac <c>: Bump LT version to C29/A18/R0.
<cpp>: Bump LT version to C10/A4/R0.
<qt>: Bump LT version to C9/A2/R0.
--
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.h.in (GPGME_ENCRYPT_WRAP): New const.
(gpgme_decrypt_flags_t): New enum.
(GPGME_DECRYPT_VERIFY): New const
(GPGME_DECRYPT_UNWRAP): New const
(gpgme_op_decrypt_ext_start): New func.
(gpgme_op_decrypt_ext): New func.
* src/decrypt-verify.c (gpgme_op_decrypt_ext_start): New.
(gpgme_op_decrypt_ext): New.
(decrypt_verify_start): Add arg FLAGS. Replace call to
engine_op_decrypt_verify by the plain decrypt with the flag set.
(gpgme_op_decrypt_verify_start): Pass the flag.
(gpgme_op_decrypt_verify): Pass the flag.
* src/decrypt.c (decrypt_start): Rename to ...
(_gpgme_decrypt_start): this. Add arg FLAGS. Pass FLAGS to
engine_op_decrypt.
(gpgme_op_decrypt_start): Adjust for chnage pass 0 for FLAG.
(gpgme_op_decrypt_start): Ditto.
* src/engine.c (_gpgme_engine_op_decrypt_verify): Remove.
(_gpgme_engine_op_decrypt): Add arg FLAGS.
* src/gpgme.def, src/libgpgme.vers: Add new functions.
* src/engine-backend.h (struct engine_ops): Remove member
'decrypt_verify'. Add FLAGS to 'decrypt'. Adjust all initialization.
* src/engine-uiserver.c (uiserver_decrypt): Remove.
(uiserver_decrypt_verify): Remove.
(_uiserver_decrypt): Rename to ...
(uiserver_decrypt): this. Replace arg VERIFY by new arg FLAGS.
* src/engine-gpg.c (gpg_decrypt): Support GPGME_DECRYPT_UNWRAP.
(gpg_encrypt): Support GPGME_ENCRYPT_WRAP.
* tests/run-decrypt.c (main): New option --unwrap.
* tests/run-encrypt.c (main): New option --wrap.
--
Manual testing of that wrap/unwrap feature can be done this way:
./run-encrypt --verbose --key Alice /etc/motd > x
./run-decrypt --verbose --unwrap x > y
./run-encrypt --verbose --key Bob --wrap y > z
1. The message was first encrypted to Alice.
2. Alice decrypts the message receiving a valid OpenPGP message.
3. Alice encrypt that message to Bob
This will also work with encrypted and signed messages; the signature
will be kept intact during re-encryption. Requires GnuPG 2.1.12.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/dirinfo.c (WANT_GPG_WKS_CLIENT_NAME): New const.
(struct dirinfo): New field 'gpg_wks_client_name'.
(get_gpgconf_item): Build it on demand.
(gpgme_get_dirinfo): New value "gpg-wks-client-name" for WHAT.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.h.in (GPGME_ENCRYPT_THROW_KEYIDS): New flag.
* src/engine-gpg.c (gpg_encrypt): Implement flag
(gpg_encrypt_sign): Implement flag.
* tests/run-encrypt.c (main): New option --throw-keyids.
--
It would be nice to also selectively hide recipients (that is gpg
--hidden-recipient) but our API does not ye allow this because it is
based on key objects. A possible way to implement that would be a API
to set processing flags into a key but this is complicated due to the
reference counting and thus the possibility that a key object is used
by different context.
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/gpgme.texi (gpgme_op_encrypt_sign_start): recp is an array of
gpgme_key_t, not a single element.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* NEWS: Update.
* doc/gpgme.texi (gpgme_op_createkey): Clarify the meaning of the
'expire' parameter.
(GPGME_CREATE_NOEXPIRE): Document new flag.
(gpgme_op_createsubkey): Clarify the meaning of the 'expire'
parameter.
* src/engine-gpg.c (gpg_add_algo_usage_expire): Fix handling of the
expiration time.
* src/gpgme.h.in (GPGME_CREATE_NOEXPIRE): New macro.
--
Previously, the documentation stated that the expiration time was an
absolute timestamp. However, this value was passed using the
'seconds=N' syntax to GnuPG which specifies the expiration time in
seconds relative to the creation time. Fix the documentation.
Furthermore, the documentation stated that using 0 results in keys
that do not expire. This was communicated to GnuPG by using the
implicit default. However, as of GnuPG 2.1.17, the default was
changed to create keys that expire within a reasonable timespan.
Fix this discrepancy by aligning the behavior with recent GnuPG
versions: 0 means use a reasonable default, and introduce a flag that
can be used to create keys that do not expire. Communicate this
explicitly to GnuPG.
Signed-off-by: Justus Winter <justus@g10code.com>
--
While educating students we can also get them to use useful habits, in
particular to parenthese bit tests.
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/gpgme.texi (gpgme_sigsum_t summary): Clarify what "you
can check one bit means"
--
It was unclear which bit to test for is. And tests
with students have shown that they would "test" for
this one bit by using if(sig.summary == GPGME_SIGSUM_VALID)
which would fail because valid sigs are also SIGSUM_GREEN.
So lets give an example for people not used to checking bits and
clarify through this example which bit is meant to be checked.
* src/engine-gpg.c (struct engine_gpg): New field
override_session_key.
(gpg_release): Free that field.
(gpg_decrypt): With gnupg 2.1.16 use --override-session-key-fd.
* tests/run-decrypt.c (main): Fix setting over the override key.
--
Note that this works only with gnupg 2.1.16 and later.
Signed-off-by: Werner Koch <wk@gnupg.org>
* doc/gpgme.texi: Document requirements of verifying that it is OK to
use session_key.
* tests/run-decrypt.c: Ensure that we fail if we're unable to access
the session key, so that we do not violate the guidance above.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Changed the description
-@code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns
-@code{GPG_ERR_NO_ERROR} or @code{gpgme_get_ctx_flag (ctx,
-"export-session-key")} returns @code{"1"}.
+@code{gpgme_set_ctx_flag (ctx, "export-session-key")} returns success
+or @code{gpgme_get_ctx_flag (ctx, "export-session-key")} returns true
+(non-empty string).
to get gpgme_get_ctx_flag for boolean values in sync with its own
description.
Note that I don't agree with the above suggestion but it does not
really harm to have it in the man page.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.c (gpgme_set_ctx_flag): Add flags "export-session-key" and
"override-session-key".
(gpgme_get_ctx_flag): Ditto.
(gpgme_set_export_session_keys): Remove.
(gpgme_get_export_session_keys): Remove.
* src/gpgme.def, src/libgpgme.vers: Remove them.
* src/context.h (struct gpgme_context): Add field
override_session_key.
* src/decrypt-verify.c (decrypt_verify_start): Pass
override_session_key value to the engine.
* src/decrypt.c (decrypt_start): Ditto.
* src/engine.c (_gpgme_engine_op_decrypt): Ditto.
(_gpgme_engine_op_decrypt_verify): Ditto.
* src/engine-backend.h (struct engine_ops): Extend DECRYPT and
DECRYPT_VERIFY_START with override_session_key.
* src/engine-uiserver.c (_uiserver_decrypt): Add stub arg
override_session_key.
(uiserver_decrypt): Ditto.
(uiserver_decrypt_verify): Ditto.
* src/engine-gpgsm.c (gpgsm_decrypt): Ditto.
* src/engine-gpg.c (gpg_decrypt): Add arg override_session_key and set
corresponding gpg option.
* tests/run-decrypt.c (print_result): Print the session key if
available.
(main): Add options --export-session-key and --override-session-key.
--
To keep the number of context manipulation functions at bay, this
patches removes the just added gpgme_set_export_session_keys and
gpgme_get_export_session_keys by flags for the generic context
function.
The patch also implements the --override-session-key feature.
GnuPG-bug-id: 2754
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.h.in (gpgme_get_ctx_flag): New.
* src/gpgme.c (gpgme_set_ctx_flag): Move down the file and add a trace
statement.
(gpgme_get_ctx_flag): New.
* src/gpgme.def, src/libgpgme.vers: Add new interface.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.c (gpgme_set_export_session_keys): New function.
(gpgme_get_export_session_keys): New function.
* src/gpgme.h.in (struct _gpgme_op_decrypt_result): Add session_key
member.
(gpgme_{set,get}_export_session_keys): Declare new functions.
* src/libgpgme.vers, src/gpgme.def: Export new functions in shared
object.
* src/engine.h: (_gpgme_engine_op_decrypt) Add export_session_key
parameter.
(_gpgme_engine_op_decrypt_verify): Add export_session_key parameter.
* src/engine-backend.h: (struct engine_ops): Change function
pointer declarations to match.
* src/context.h (struct gpgme_context): Add export_session_keys member.
* src/decrypt.c (release_op_data): Free result.session_key.
(_gpgme_decrypt_status_handler): Store a copy of the exported session
key.
(decrypt_start): Pass export_session_keys from the context.
* src/decrypt-verify.c (decrypt_verify_start): Pass
export_session_keys from context.
* src/engine.c (_gpgme_engine_op_decrypt): Pass through
export_session_key flag.
(_gpgme_engine_op_decrypt_verify): Pass through export_session_key
flag.
* src/engine-gpg.c (gpg_decrypt): If export_session_key is set, add
--export-session-key to argument list.
* src/engine-gpgsm.c (gpgsm_decrypt): Ignore export_session_key for
now, since gpgsm offers no such mechanism.
* src/engine-uiserver.c (_uiserver_decrypt): If export_session_key is
set, add --export-session-key flag to cmd.
* doc/gpgme.texi: Document new functions and session_key member of
decrypt_result_t.
* doc/uiserver.texi: Add --export-session-key flag to DECRYPT command.
--
gpg(1) documents session key export as useful for key escrow, and is
rightly dubious of that use case. However, session key export is also
useful in other use cases. Two examples from MUA development (where
this functionality would be specifically useful to me right now):
* If the MUA stores a local copy of the session key upon decrypting
the message, it can re-decrypt the message without expensive
asymmetric operations. When rendering a thread with dozens of
encrypted messages, this can represent a significant speedup.
* A user may have expired encryption-capable secret key material,
along with many messages encrypted to that material. If she stores
the session keys for those messages she wants to keep, she can
destroy her secret key material and make any messages she has
deleted completely unrecoverable, even to an attacker who gets her
remaining secret keys in the future.
This patchset makes a two specific implementation decisions that could
have gone in different ways. I welcome feedback on preferred outcomes.
0) session key representation: we currently represent the session key
as an opaque textual string, rather than trying to provide any
sort of in-memory structure. While it wouldn't be hard to parse
the data produced by gpg's --export-session-key, I chose to use
the opaque string rather than lock in a particular data format.
1) API/ABI: i've added a member to gpgme_op_decrypt_result_t. This
has the potential to cause an out-of-bound memory access if
someone uses code compiled against the newer verision, but linked
at runtime against an older version. I've attempted to limit that
risk by documenting that users must verify
gpgme_get_export_session_keys() before accessing this new struct
member -- this means that code expecting this capability will
require the symbol at link-time, and will refuse to link against
older versions.
Another approach to solving this problem would be to avoid
modifying gpgme_op_decrypt_result_t, and to introduce instead a
new function gpgme_op_session_key(), which could be called in the
same places as gpgme_op_decrypt_result(). Depending on the
representation of the session key, this might introduce new
memory-management burdens on the user of the library, and the
session key is certainly part of a decryption result, so it seemed
simpler to go with what i have here.
If anyone has strong preferences that these choices should be solved
in a different way, i'm happy to hear them.
Additionally, I note that i'm also still pretty unclear about how the
"UI Server" fits into this whole ecosystem. In particular, I don't
know whether it's kosher to just add an --export-session-key flag to
the DECRYPT operation without actually having implemented it anywhere,
but i don't see where i would actually implement it either :/
If this patch (or some variant) is adopted, i will supply another
patch that permits offering a session key during decryption (e.g. "gpg
--override-session-key"), but I wanted to get these implementation
choices ironed out first.
Gnupg-Bug-Id: 2754
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
On the concern of adding a new field to a structure: It may not be
clearly documented but we don't expect that a user ever allocates such
a structure - those result structure may only be created bu gpgme and
are read-only for the user. Adding a new member constitutes a
compatible ABI change and thus an older SO may not be used by code
compiled with a header for the newer API. Unless someone tinkers with
the build system, this should never happen. We have added new fields
to result structure may times and I can't remember any problems.
- wk
* doc/gpgme.texi: Documentationabout gpgme_op_decrypt_verify_start was
stored under the name gpgme_op_decrypt_verify instead.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* configure.ac: Require libgpg-error 1.17. No longer
check for pthread.
* doc/gpgme.texi: Document removed neccessity for thread
safe gpgme flavours.
* src/sema.h (DEFINE_GLOBAL_LOCK),
(DEFINE_STATIC_LOCK, INIT_LOCK, DECLARE_LOCK)
(DESTROY_LOCK, LOCK, UNLOCK): Change to gpgrt equivalents.
* src/posix-sema.c, src/w32-sema.c: Removed.
* src/Makefile.am: Remove libpthread and
Update accordingly.
* src/ath.c, src/ath.h (ath_mutex_init)
(ath_mutex_destroy, ath_mutex_lock, ath_mutex_unlock): Removed.
* src/ath.h (ATH_MUTEX_INITIALIZER): Removed.
* src/version.c (do_subsystem_inits): sema_subsystem_init is
no longer required.
* tests/gpg/Makefile.am: Add new threading tests.
(t_thread1_LDADD, t_cancel_LDADD):
Use just gpgme.
* tests/gpg/t-thread-keylist-verify.c,
tests/gpg/t-thread-keylist.c: New.
* src/gpgme-config.in: Use -lgpgme for thread-model pthread.
--
Using gpgrt locks instead of pthread locks removes
the neccessity to link pthread directly to gpgme and
have a different, thread safe flavor of gpgme. Now
gpgme is thread-safe if the conditions mentioned
in the doc are met.
As the cpp bindings linked against libgpgme
and not libgpgme-pthread this fixes threading problems
with them.
libgpgme-pthread is removed but gpgme-config still supports
--thread=pthread for compatibility with find scripts.
* THANKS, doc/ChangeLog-2011, tests/ChangeLog-2011,
tests/gpg/geheim.txt: convert from iso 8859-1 to utf-8.
* lang/qt/src/dataprovider.cpp, lang/qt/src/qgpgmerefreshkeysjob.cpp,
lang/qt/src/qgpgmesecretkeyexportjob.cpp: replace U+FFFD REPLACEMENT
CHARACTER with proper U+00E4 LATIN SMALL LETTER A WITH DIAERESIS.
--
Note that src/versioninfo.rc.in is still ISO-8859-1. I don't know
whether Windows will properly handle UTF-8 in this file or not, so i
have not touched it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* src/status-table.c (_gpgme_status_to_string): Return "" for EOF.
* src/engine-gpg.c (read_status): Ditto. The old code accidently used
GPGME_STATUS_EOF which is the integer 0 and neiteyr NULL nor a string.
Signed-off-by: Werner Koch <wk@gnupg.org>
