* src/engine-gpgconf.c (gpgconf_write): Add --runtime.
* src/gpgme.h.in (gpgme_conf_opt_change): Document this
behavior.
--
If a tool uses GPGME for changing configuration values it
needs a way to ensure that these changes take effect. Otherwise
users may change and see config values and do not understand
why they are not working.
* src/engine-gpg.c (gpg_addkey): Pass --batch to gpg when
GPGME_CREATE_NOPASSWD is set to fix pinentry without loopback mode.
--
Signed-off-by: Ben Kibbey <bjk@luxsci.net>
* m4/qt.m4: Use grep -E when using the alternation character.
--
POSIX specifies '|' is only supposed to work as an alternation special
character when grep is used in extended mode. The code worked fine
with GNU grep because it accepts extended regular expressions by
default, but other POSIX-compliant implementations might fail and take
it literally.
Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
* lang/cpp/src/key.cpp (Key::update): Check for
a secret key first before listing public keys.
--
This is a performance delay but the update should
only be called in a non gui thread anyway. The information
if we have the secret key for this key is important to provide
after update.
* lang/cpp/src/key.cpp (UserID::addrSpec): Use uid->address instead
of normalizing again.
(&operator<<(std::ostream &, const UserID &): Print it.
--
This saves a normalization and fixes the case where a user id
is just a mail address without name, in that case gpgme sets
"address" but not email. Because the email is then the name.
* lang/cpp/src/verificationresult.cpp
(Signature::key(bool,bool)): Don't update the returned copy
but the actual key of the signature.
--
The whole point of the update is to change the partial key
from the signature (e.g. only fingerprint and one uid as we
would have from tofu) to a fully keylisted one.
--
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.
* lang/python/helpers.c (_gpg_obj2gpgme_data_t): Extended error
message.
* lang/python/tests/t-encrypt.py: Test for "encode" in error message.
--
The motivation is to help the user when encrypting fails. I claim that
it is not obvious to not being able to encrypt a string directly. To
nudge the user into encoding it to bytes, the error message is a bit
extended.
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
* lang/python/gpgme.i (wrapresult): New Macro.
--
This reduces the amount of copy and pasted code at the expense of a
slightly more complicated logic with a macro.
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
* lang/python/tests/support.py (print_data): Add check for buffer.
--
When running with something like make -C lang/python check verbose=2 the
test would fail under python2, because the file objects do not have a
buffer property.
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
* lang/python/gpg/core.py (Context.__repr__): New function.
--
This makes Context objects look nicer in a REPL.
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
* lang/python/gpg/results.py (Result.__str__): Renamed to '__repr__'
...
* lang/python/gpg/results.py (Result.__repr__): ... and added fields.
--
So that it looks a bit nicer in the Python REPL.
It looked like this before:
In [2]: gpg.core.get_engine_info()[0]
Out[2]:
<gpg.results.EngineInfo at 0x7fb23509a240>
Now the output is
In [2]: gpg.core.get_engine_info()[0]
Out[2]:
EngineInfo(file_name='/usr/bin/gpg2', home_dir=None,
protocol=0, req_version='1.4.0', version='2.1.11')
This also applies to other results, e.g. the ImportResult.
Note that the format now changed from "<Class >" to "Class()". The
Python documentation on repr states: "For many object types, including
most builtins, eval(repr(obj)) == obj."
Signed-off-by: Tobias Mueller <muelli@cryptobitch.de>
* lang/cpp/src/GpgmeppConfig.cmake.in.in: Remove a forgotten
instance of @libsuffix@.
--
b2c07bd47b removed @libsuffix@ from
cmake config files, but missed one instance.
Signed-off-by: Heiko Becker <heirecka@exherbo.org>
* configure.ac: Set version to 1.8.0. Set LT version C28/A17/RO.
Set CPP LT version to C9/A3/R0. Set Qt LT version to C8/A1/R0.
--
Signed-off-by: Werner Koch <wk@gnupg.org>
* 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>
* lang/cpp/src/GpgmeppConfig-w32.cmake.in.in
lang/qt/src/QGpgmeConfig-w32.cmake.in.in: New.
* lang/cpp/src/GpgmeppConfig.cmake.in.in,
lang/qt/src/QGpgmeConfig.cmake.in.in: Remove libsuffix handling.
* lang/cpp/src/Makefile.am,
lang/qt/src/Makefile.am: Create / install w32 config files.
* configure.ac: Configure them.
--
To work with DLL's cmake needs to know about the implib and
the final DLL. So the config files look different enough
that it's better to use alternative files.
* 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
* lang/qt/src/job.cpp,
lang/qt/src/job.h (Job::context): New.
* lang/qt/src/threadedjobmixin.cpp
(ThreadedJobMixin::~ThreadedJobMixin): New. Unregister context.
(ThreadedJobMixin::lateInitialization): Register context.
* NEWS: Update for cpp and qt.
--
The global map hack is necessary because the job class does
not know about the context which is held in threadedjobmixin.
Adding a virtual function in Job would be an ABI break which
I'd like to avoid at this point. Although QGpgME's API will
need a big ABI break to make it ABI maintainable. The virtual
jobs -> implementation classes are nearly unmaintainable ABI wise.
The context is exposed to provide more flexibility to users, e.g.
to add a passphrase callback or to set the sender in a context.
* 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>
* src/gpgme.c (gpgme_set_armor, gpgme_set_textmode,
gpgme_set_offline): Ensure that non-zero values actually set the
appropriate internal bit.
--
The documentation for these functions says things like "disabled if
YES is zero, and enabled otherwise", where YES is an integer.
However, if you pass an even integer, it will be aliased back to 0
because the context member variables are declared as single bits.
This should make the implementation match the documentation.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* src/posix-io.c (_gpgme_io_select): Return EMFILE instead of EBADF.
--
Also EBADF seem more correct, EMFILE (Too man open files) gives
a clearer message to the user that there are somehow too many files
open. The problem can be exhibited by running lots of threads,
We should eventually move to poll but that would be a large change and
so we better fix it with the planned migration of the I/O subsystem to
libgpgrt (currently known as libgpg-error).
Signed-off-by: Werner Koch <wk@gnupg.org>
* gpg/t-thread-keylist-verify.c,
gpg/t-thread-keylist.c: Reduce threads to 100
--
Due to the limit of FD_SETSIZE the
number of parallel threads is limited. So some systems
run into this problem when running the testsuite.
* src/keylist.c (op_data_t): Add field keydb_search_err.
(keylist_status_handler): Parse STATUS_ERROR into that var.
(gpgme_op_keylist_next): Use that err instead of GPG_ERR_EOF.
--
With a recent GnuPG version this allows to detect a keyring with wrong
permissions (i.e. no read access). GPG_ERR_OPEN_KEYRING will be
returned instead of GPG_ERR_EOF.
Signed-off-by: Werner Koch <wk@gnupg.org>
* tests/gpg/t-thread-keylist-verify.c (start_keylist): Mark
arg as unused. Release context.
(start_verify): Ditto.
(main): Mark args as unused.
* tests/gpg/t-thread-keylist.c (start_keylist): Mark
arg as unused. Release context.
(main): Mark args as unused.
* 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.
* src/w32-io.c (fd_table_lock): New.
(new_fd): Lock allocation of a new slot.
(release_fd): Lock deallocation of a slot.
--
Note that we lock only the allocation but not the sanitiy checks we do
further down in the code.
Signed-off-by: Werner Koch <wk@gnupg.org>
