* 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>
* NEWS: Update.
* lang/python/src/core.py (Context.__read__): New helper function.
(Context.encrypt): Attach partial results to exceptions.
(Context.decrypt): Likewise.
(Context.sign): Likewise.
(Context.verify): Likewise.
* lang/python/src/errors.py (GpgError): Move the core of GPGMEError to
this class, add a nicer interface for it. This makes the errors
thrown by this library more uniform, and allows us to track the
underlying error in synthesized high-level errors.
(GPGMEError): Simplify.
(...): Make sure to call the parent classes' constructor in all other
classes.
--
Attach partial results to errors. Some operations return results even
though they signal an error. Of course this information must be taken
with a grain of salt. But often, this information is useful for
diagnostic uses or to give the user feedback. Since the normal
control flow is disrupted by the exception, the callee can no longer
return results, hence we attach them to the exception objects.
GnuPG-bug-id: 3271
Signed-off-by: Justus Winter <justus@g10code.com>
* NEWS: Update.
* lang/cpp/src/decryptionresult.cpp (DecryptionResult::isDeVs): New
function.
* lang/cpp/src/decryptionresult.h (DecryptionResult::isDeVs): New
prototype.
* lang/cpp/src/verificationresult.cpp (Signature::isDeVs): New
function.
* lang/cpp/src/verificationresult.h (Signature::isDeVs): New
prototype.
* lang/python/src/results.py (DecryptResult): Turn field 'is_de_vs'
into a boolean.
(Signature): Likewise.
* src/decrypt.c (_gpgme_decrypt_status_handler): Handle the new
compliance status line.
* src/verify.c (_gpgme_verify_status_handler): Likewise.
* src/gpgme.h.in (gpgme_status_code_t): Add new status codes for the
new status lines.
* src/keylist.c (parse_pub_field18): Move function to 'util.h'.
(keylist_colon_handler): Adapt callsites.
* src/status-table.c (status_table): Add new status lines.
* src/util.h (PARSE_COMPLIANCE_FLAGS): New macro. This used to be
'parse_pub_field18', but turned into a macro to make it polymorphic.
--
When decrypting data and verifying signatures, report whether the
operations are in compliance with the criteria for data classified as
VS-NfD. This information can the be presented to the user.
GnuPG-bug-id: 3059
Signed-off-by: Justus Winter <justus@g10code.com>
* 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>
* lang/cpp/data.h, lang/cpp/data.cpp (GpgME::Data::toKeys): New.
--
Doing this in data instead of Context is a bit more idiomatic. But
this could also be added to Context.
* NEWS: Update.
* lang/python/gpg/core.py (Context.keylist): New keyword argument
'source'. If given, list keys from 'source'.
* lang/python/gpgme.i: Wrap the argument to
'gpgme_op_keylist_from_data_start'.
* lang/python/tests/Makefile.am (py_tests): Add new test.
* lang/python/tests/support.py (EphemeralContext): Do not throw an
error if no agent has been started in the context.
* lang/python/tests/t-keylist-from-data.py: New file.
Signed-off-by: Justus Winter <justus@g10code.com>
* 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>
--
This reverts commit 6df6e01ed5.
gpgme_error_t et al are from a time where we had no hard dependency on
libgpg-error. Now libgpg-error is a required and thus it does not
make sense to have these surrogates. In fact we should ventually
completely remove them.
Signed-off-by: Werner Koch <wk@gnupg.org>
* 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>
* NEWS: Update.
* src/data.c (gpgme_data_set_flag): Return a 'gpgme_error_t'.
* src/error.c (gpgme_strerror_r): Fix type of first argument.
* src/gpgme.h.in (gpgme_strerror_r): Adapt.
(gpgme_data_set_flag): Likewise.
--
Fix for consistency. This should not pose problems, because typedef
gpg_error_t gpgme_error_t.
Signed-off-by: Justus Winter <justus@g10code.com>
* src/gpgme.h.in (gpgme_data_rewind): Un-deprecate.
* src/data-compat.c (gpgme_data_rewind): Move to ...
* src/data.c (gpgme_data_rewind): here.
--
That function is very convenient because it is required a lot with
memory streams. It also documents the intention of the caller better
than gpgme_data_seek with its addition parameters and the need to map
system errors. Thus it does not make sense to make it a first class
citizen again.
Signed-off-by: Werner Koch <wk@gnupg.org>
* lang/qt/src/Makefile.am (qgpgme_sources): Add cryptoconfig.cpp
* lang/qt/src/cryptoconfig.cpp: New.
* lang/qt/src/cryptoconfig.h (CryptoConfigEntry::stringValueList):
New.
* lang/qt/src/qgpgmenewcryptoconfig.cpp
(QGpgMENewCryptoConfigEntry::stringValueList): New.
* lang/qt/src/qgpgmenewcryptoconfig.h: Update accordingly.
--
This is a pardigm change in cryptoconfig.h to avoid ABI breaks
with each new config value we support it now has an implementation
that is directly related to qgpgmenewcryptoconfig, which is now
the only one.
* 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/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>
* 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.
* lang/qt/src/dn.cpp (DN, DN::Attribute): New public API.
* lang/qt/src/dn.h: New.
* lang/qt/src/Makefile.am: Update accordingly.
--
This is a general useful API to work with X509 distinguished
names and is useful when doing CMS with GpgME.
Adding this class from libkleo allows kmails messagelib to
avoid any KDE UI Frameworks and so can be used more versatile
in the future.
This class can be combined with libkleos DNAttributeMapper
to have the same bevavior as before in libkleo when using
DN::prettyDN calls can be converted from:
Kleo::DN(uid).prettyDN();
to:
QGpgME::DN dn(uid);
uid.setAttributeOrder(
Kleo::DNAttributeMapper::instance()->attributeOrder());
dn.prettyDN();
This follows weeks of discussion on the gnupg-devel mailing list.
Hopefully it will make it easier for people using Python to use GnuPG
in the future.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* configure.ac: Set LT version to C27/A16/R0. Note that the LT
versions for cpp and Qt have already been updated.
Signed-off-by: Werner Koch <wk@gnupg.org>
