* moved single encrytion examples up to the first ones, pending merge
and major cut.
* This is basically just to make future checks of revisions a little easier.
* src/cJSON.c: Remove util.h. Use gpgrt alloc functions.
(cJSON_Delete): Do not clobber ERRNO.
(cJSON_AddItemToObject): Return OBJECT or NULL.
(cJSON_AddNullToObject): New.
(cJSON_AddTrueToObject): New.
(cJSON_AddFalseToObject): New.
(cJSON_AddBoolToObject): New.
(cJSON_AddNumberToObject): New.
(cJSON_AddStringToObject): New.
* src/cJSON.h (cJSON__h): Replace macro by cJSON_h for C compliance.
(cJSON_AddNullToObject): Remove macro.
(cJSON_AddTrueToObject): Remove macro.
(cJSON_AddFalseToObject): Remove macro.
(cJSON_AddBoolToObject): Remove macro.
(cJSON_AddNumberToObject): Remove macro.
(cJSON_AddStringToObject): Remove macro.
--
The gpgrt malloc functions are used so that we can easily mix memory
returned by gpgrt (e.g. es_read_line) with memory returned from the
JSON function. In general that is not needed but on Windows it makes
a difference if the gpgme DLL is linked to a different C runtime
than the application.
The macros have been replaced to allow error checking (i.e out of
core) for these functions. More error checking should be implemented
instead of silently creating objects which are not as requested.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme.h.in (gpgme_import_result_t): Extend with skipped_v3_keys.
* src/import.c (gpgme_op_import_result): Extend debug with new field.
(parse_import_res): Parse skipped_v3_keys.
* tests/gpg/t-support.h, tests/run-support.h (print_import_result):
Print skipped_v3_keys.
--
This makes it possible to handle this in a GUI in a future
version.
GnuPG-Bug-Id: T3776
* Fixed a minor typographic error.
* Bumped version number in preparation for merge with master.
* While there are probably a few more things worthy of being added
(mainly how to revoke things), this document is essentially ready
for publication now.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Added a new user ID for Danger Mouse.
* Removed the empty entry for key preferences since that is handled
through gpg.conf and/or editing the key directly.
* src/cJSON.c: New.
* src/cJSON.h: New.
* src/cJSON.readme: New.
--
This is a copy of the code from the payproc commit
af5d6b4f820ee19e246a2cab6f56465fe91f1233. The code was originally
added to payproc with the commit below.
Signed-off-by: Werner Koch <wk@gnupg.org>
===============================================
commit 7ae7ef29bc5ec19e005e6a5a739233d655f3f05f
Author: Werner Koch <wk@gnupg.org>
AuthorDate: Wed Apr 2 09:01:42 2014 +0200
Commit: Werner Koch <wk@gnupg.org>
CommitDate: Wed Apr 2 09:12:02 2014 +0200
Simplify cJSON and add new macros.
* src/cJSON.h: Re-indented.
(cjson_t): New.
(cjson_is_): New macros.
* src/cJSON.c: Re-indented. Include errno.h and our util.h.
(ep): Remove global var.
(cJSON_GetErrorPtr): Remove.
(cJSON_strcasecmp): Cast args for use with tolower.
(cJSON_malloc, cJSON_free): Remove. Change callers to use xtrymalloc
and xfree.
(cJSON_InitHooks): Remove.
(cJSON_strdup): Remove. Change callers to use xtrystrdup.
(cJSON_New_Item): Simplify.
(cJSON_ParseWithOpts, cJSON_Parse): Add arg R_ERROFF.
(parse_string, parse_value, parse_array, parse_object): Add arg EP.
--
cJSON has been taken from cjson-code-58.zip. The README file has been
renamed to cJSON.readme and the files have been changed to GNU coding
standards. Because that parser is small enough to be source copied it
does not make sense to treat it as a library and I changed the memory
allocation functions to the usual xmalloc ones. The only external
dependency now is out util.h which declares those functions.
The lowercase cjson_t better fits into our coding style as well as the
new macros. Thanks to Dave Gamble for this nice parser.
===============================================
* Clarified which English dialects this is written in.
* Translating to American can happen *after* it's done.
** The Yank version would probably want to change some of the examples
anyway.
* Began the description for normal/default signing.
* Added a section on key selection.
* Included recommendation for using fingerprint when selecting one
specific key.
* Also included the most ironically amusing example of multiple key
selection in a GPG guide. Hey, it's public data ... (heh).
* Added explanation of the ascendance of Python 3 over Python 2 in the
guide to the intro.
* Expanded key selection description so people know what not to
include regarding key IDs with this key selection method.
* During the course of working out the updated signature methods,
determined that key selection (including counting) will beed to be
presented before the basic functions.
* Moved "working with keys" up.
* Added a miscellaneous work-arounds section at the end.
* Included code in said miscellaneous section for accessing the groups
specified in a gpg.conf file.
* It's a bit ugly since it does require subprocess (but not call,
Popen or shell access and only accesses one command).
* updated multi-encryption final example to be complete.
* second example shows most likely method of reading plaintext.
* updated example filenames to stick with running gag
(i.e. secret_plans.txt).
* error corrections.
* multiple typesetting fixes only required due to certain archaic
eccentricities of LaTeX.
* a couple of minor python PEP8 compliance corrections.
* Added a more complicated encryption example with a few variations on
the encryption method to account for untrusted recipient keys,
signing or not signing, including or excluding default keys and so
on.
* Switched from links to some external docs to using footnotes where
necessary.
* Ideally the howto should be as stand alone as possible.
* Also it makes it difficult to convert to another format for
proof-reading if there are links that the conversion can't find.
* Wrote the text description explaining each step in the most basic
encryption operation.
* Will need to include additional examples for encrypting to multiple
recipients using Context().encrypt instead of Context().op_encrypt.
* Added all four signing code examples that are most likely to be
used: armoured, clearsigned, detached armoured and detached binary.
* May remove some examples and just discuss the differences, but it
depends on the way the text is filled out.
