* Added a secret key export variant which saves output as both GPG
binary and ASCII armoured, plus saves in $GNUPGHOME and uses
multiple methods of determining what that location is.
* Example of default exporting keys.
* Example of exporting minimised keys.
* Example of exporting secret keys to a file with correct permissions.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* The holy grail: a function to export secret keys.
* GPGME will still invoke pinentry and gpg-agent as usual to authorise
the export.
* Mostly similar to the two previous export functions for public keys
except that it will return None if the result had a length of zero
bytes. Meaning that the difference between the specified pattern
(if any) not matching available keys and an incorrect passphrase is
not able to be determined from this function (or the underlying one
for that matter).
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Updated key_export and key_export_minimal to return None where a
pattern matched no keys in a manner simnilar to the possible result
of key_export_secret.
* Added functions for exporting public keys to gpg.core in both
complete form and in minimised form.
* Rather than letting people need to worry about the export modes we
are simply separating the functions as people would be more familiar
with from the command line usage anyway.
* Functions added for Context are: ctx.key_export_minimal and
ctx.key_export as the default or full export.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* src/gpgme-json.c (main): Add possibilty to set log file.
--
This is similar to how GPGME_DEBUG works. It takes ; on
Windows as seperator and : on linux. Followed by a file name.
For Linux it might make sense to use a different seperator
to allow setting a socket explicitly. But this is better
in line with the current GPGME_DEBUG behavior.
The change helps on Windows where we don't have a
log socket.
* Fixed most of the PEP8 errors in core.py
* Those remaining may need more than little edits and are a bit
strange (too clearly the result of a programmer who has spent far
too much time dealing with Lisp so that for Python it looks
... strange).
* Wrapped the key import function in the try/exception statements
needed to catch at least the most likely unsuccessful import attempt
errors.
* Mostly draws on the file error and no data import statuses for
errors, with a couple of exceptions.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* The foundation of a pythonic key import function authored by Jacob
Adams.
* A unit testing script for the same function originally authored by
Tobias Mueller
* Added DCO reference for Jacob Adams to the GPGME AUTHORS file.
* Additional details regarding this patch are available here:
https://dev.gnupg.org/T4001
Signed-off-by: Ben McGinnes <ben@adversary.org>
* lang/cpp/src/context.cpp, lang/cpp/src/context.h
(Context::createKeyEx): New.
--
The createKeyEx function follows the usual pattern that the
synchronous call returns a result directly while for the
async an extra call is neccessary.
* src/gpgme-json.c (hlp_createkey, op_createkey): New.
(process_request, hlp_help): Add it.
--
This uses an unrestricted context for now until
GnuPG-Bug-Id: T4010
is implemented in GnuPG.
* src/gpgme-json.c (MIN_REPLY_CHUNK_SIZE): Lower value to
new real minimum.
(DEF_REPLY_CHUNK_SIZE): Don't chunk by default.
(pending_data): Remove type and base64.
(make_data_object): Remove chunksize handling as this is now
generic.
(encode_and_chunk): Setup the pending_data buffer for chunking
if required.
(op_getmore): Changed to generically work on a response.
(hlp_getmore): Update accordingly.
(hlp_help): Document chunksize as generic parameter for all commands.
(process_request): Use encode_and_chunk on the response.
(hlp_encrypt, op_encrypt, hlp_decrypt, op_decrypt),
(hlp_verify, op_verify, hlp_sign, op_sign),
(op_keylist, hlp_keylist, hlp_export, op_export): Update accordingly.
--
To include handling for json properties e.g. in a keylist in
the chunk mechanism the mechanism is now more general.
If the chunksize property is provided the response will
always look exactly like a "getmore" response. E.g.
e.g.:
{
"op": "keylist",
"chunksize": 64
}
Results in:
{
"more": true,
"base64": true,
"response": "ewoJImtleXMiOglbewoJCQkicmV2b2tlZCI6"
}
For simplicity this is even true if the chunksize is larger
then the response.
The client has to combine all "response" chunks and base64
decode them to get valid json.
The complete response (including json) is never larger then
the chunksize but might be smaller. Except for interactive
use due to additional format characters.
* src/gpgme-json.c (sigsum_to_json): Add bool repr.
(signature_to_json, verify_result_to_json): Extend and follow better
pattern.
(hlp_decrypt, hlp_verify): Expand doc.
--
This should make it more clear which values are mapped as
the naming is more direct and clear and help to use
the gpgme documentation to understand the verify_result values.
* src/gpgme-json.c (op_config_opt, hlp_config_opt): New operation.
(process_request, hlp_help): Add it.
--
This is more conveniant API for most query operations where
a single option is required.
An example would be:
{
"op": "config_opt",
"component": "gpg",
"option": "default-key"
}
Which results in:
{
"option": {
"name": "default-key",
"description": "use NAME as default secret key",
"argname": "NAME",
"flags": 0,
"level": 0,
"type": 1,
"alt_type": 1,
"value": [{
"string": "F462B6B1",
"is_none": false
}]
}
}
* Uses the groups module to prepare a list of recipients and encrypt
to those.
* The main version (encrypt-to-group.py) tries to check for invalid
recipients, but still falls back to always trust for the second
encryption attempt.
* The gullible version doesn't try pruning the recipient list at all,
it just tries to encrypt and if it fails, switches straight to
always trust.
* The trustno1 version doesn't use the always trust model at all and
only attempts pruning the list of invalid recipients.
* src/decrypt.c (op_data_t): Add field first_status_error.
(parse_status_error): Set it.
(_gpgme_decrypt_status_handler): Prefer an ERROR code over a
NO_SECKEY.
--
GnuPG-bug-id: 3983
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/cJSON.c: Use gpgrt fucntion only if available.
--
We have a hack in gpgme-json to allow building with older libgpg-error
versions. That whole thing will not work but the instead the binary
will print an error at runtime that it needs to be build with a newer
libgcrypt. There was a little bug here for the Debian packages
libgpg-error versions which failed to build cJSON. cJSON is only
needed be the full gpgme-json but nevertheless the Makefile wants to
build it. The fix is straightforward.
GnuPG-bug-id: 3971
Signed-off-by: Werner Koch <wk@gnupg.org>
* 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>
* 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
* 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>
* 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.
* 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.
