* Ran all the .py files in src/ and below through Yapf.
* Included some manual edits of core.py, this time successfully making
two notorious sections a bit more pythonic than scheming.
* Left the module imports as is.
* This will be committed if it passes the most essential test:
compiling, installing and running it.
Signed-off-by: Ben McGinnes <ben@adversary.org>
* src/cJSON.c, src/gpgme-json.c (CALLOC_ONLY): New define
to change xmalloc / xtrymalloc to use calloc.
--
Some people consider malloc dangerous as it might allow an
information leak.
* src/gpgme-json.c (encode_and_chunk): Don't error out
if no chunksize is provided.
--
This fixes 82e4b900a9 which
caused every call without chunksize to error out.
* lang/cpp/src/gpggencardkeyinteractor.cpp
(GpgGenCardKeyInteractor::Private::keysize): Change to string.
--
The value is only required as string so we can save it this
way to avoid the need to convert it for the action command.
GnuPG-Bug-Id: T4094
* lang/python/tests/Makefile.am,
lang/qt/tests/Makefile.am,
tests/Makefile.am,
tests/gpg/Makefile.am,
tests/gpgsm/Makefile.am,
tests/opassuan/Makefile.am (GNUPGHOME): Make variable explict.
--
If the build directory has too long path, gpgme could fail.
This is similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206
In order to fix that, this patch extracts the GNUPGHOME variable
to be presented directly in the Makefile and thus overridable by
command line option.
A build system can then create a symlink to the GNUPGHOME directory
in /tmp and use that symlink as the GNUPGHOME directory
thus making the path very short.
GnuPG-Bug-Id: T4091
Patch provided by vlmarek
--
* src/index.js: The export now uses a freezed Object, which does not
allow for simply overwriting the init method by e.g. a third-party
library.
* BrowsertestExtension: Added some tests trying if decryption of bad
data properly fails
--
* The aim is to iterate through the results of the first request
(all keys), and then add the propert 'hasSecret' to those that
are in the second request (secret Keysring) as well. I messed
this up in a recent change, and it escaped testing.
--
* An Object.freeze should stop any malicious third party from changing
objects' methods once the objects are instantiated (see unittest for
an approach that would have worked before)
- An initialized gpgmejs- object doesn't have a '_Keyring' property
anymore (it still has its 'Keyring')
- The internal expect='base64' needed to be turned into a method.
--
* src/ [Connection, Error, Key, Keyring, MEssage, Signature, gpgmejs]:
Functions and values that are not meant to be overwritten are now
moved into their constructors, thus eliminating the possibility of
overwrites after initialization.
* Key: The mode of use (synchronous cached, or async promises) ivs now
determined at initialization of that Key. The property Key.isAsync
reflects this state.
* unittests: fixed old Key syntax for testing.
* Message.js isComplete is now a method and not a getter anymore.
* Added some startup tests.
--
Tests will now run with one instance of gpgmejs each block,
which reduces overhead. Readability is (hopefully) improved),
some negative tests are added.
There is still a performance problem in base64 encoding/decoding,
which causes some tests to fail due to time out.
--
* The import answer now also directly contains the armored Key as Key
property, without need to refresh the Key object created in the
answer. This allows for direct comparision of input and output.
* BrowserTestExtension: added test for that import callback
--
* The libgpg error strings arrive in the browser in a different
encoding than used by browsers. Escaping and then decoding it
should cover most languages in the supported browsers.
* lang/cpp/src/key.cpp (Key::update): Check that the key is
not NULL.
* lang/cpp/src/verificationresult.cpp (GpgME::Signature::key):
Check for fingerprint.
* Fixed and tested the changes necessary for org-mode to correctly
parse pythonic (Python 3) indentation.
* Updated the source blocks to recommended upper case for BEGIN_SRC
and END_SRC.
* Tested and confirmed XHTML output matches correct examples.
* Tested against pseudo-control output via exporting from org-mode to
org-mode and then exporting that to XHTML. Remaining differences
appear to be discarding the custom tags used to provide X[HT]ML id
elements to each section which does not appear to offer any benefit.
* Exporting directly to XHTML or other HTML output should no longer
cause problems, but if there are any then the first step should be
exporting from org-to-org and then exporting that to XHTML.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Another retrofitting of the HOWTO Python example code, this time
following adjustments to python-mode configuration and having
trawled through the org-mode mailing lists for clues.
* src/data.c (PROPERTY_TABLE_ALLOCATION_CHUNK): New.
(insert_into_property_table): Use it here. Clear all flags.
--
Fixes-commit: 085cdeddef
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/data.h (data_prop_t): New enum.
(struct gpgme_data): Add field propidx.
* src/data.c (property_t): New.
(property_table, property_table_size, property_table_lock): New.
(insert_into_property_table): New.
(remove_from_property_table): New.
(_gpgme_data_get_dserial): New.
(_gpgme_data_set_prop): New.
(_gpgme_data_get_prop): New.
(_gpgme_data_new): Connect new object to property_table.
(_gpgme_data_release): Remove from property_table.
(gpgme_data_read): With DATA_PROP_BLANKOUT set don't fill the buffer.
* src/data-mem.c (gpgme_data_release_and_get_mem): Likewise.
* src/decrypt.c (struct op_data): Add field plaintext_dserial.
(_gpgme_op_decrypt_init_result): Add arg plaintext and init new field.
(_gpgme_decrypt_status_handler): Set DATA_PROP_BLANKOUT on decryption
failure.
(_gpgme_decrypt_start): Pass PLAIN to the init function.
* src/decrypt-verify.c (decrypt_verify_start): Ditto.
* configure.ac: Check for stdint.h and bail out if uint64_t is not
available.
--
This is a best effort feature to not output plaintext after a
decryption failure (e.g. due to no or broken authenticated
encryption). It always work when using a memory object and reading it
after the decryption but it can't work reliable when the user is
reading from the data object while the decryption process is still
running.
This is quite a large change because the data objects and the context
objects are allowed to be owned by different threads. Thus a
synchronization is needed and we do this with a global table of all
data objects to which the context objects can do soft-linking via a
unique data object serial number.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/gpgme-json.c (create_keylist_patterns): Use CNT as first arg for
xcalloc.
(process_request): s/strdup/xtrystrdup/.
--
calloc takes two arguments so to be able to detect integer overflow.
Thus if we switch from malloc to calloc we should utilize that.
Signed-off-by: Werner Koch <wk@gnupg.org>
* 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>
* src/gpgme-json.c (native_messaging_repl): Free request and
response after each loop.
--
If we only accept once request we should not loop. If we loop
we should do it properly.
* src/gpgme-json.c (native_messaging_repl): Ensure that the
request is NULL terminated.
--
This avoids potential memory leaks and access to unmapped memory
in case the request was not terminated.
Other request functions use es_read_line which gurantees NULL
termination.
* src/gpgme-json.c (encode_and_chunk): Try to always
return at least an error.
(process_request): Double check that it does not return NULL.
--
If process_request returns NULL the following strlen on it
would crash.
* src/gpgme-json.c (create_keylist_patterns): Reserve two
pointers more then linefeeds.
(create_keylist_patterns): Fix loop to count linebreaks.
(create_keylist_patterns): Use calloc for good measure.
--
This fixes crashes and memory corruption as cnt did not
match i.
* lang/qt/src/threadedjobmixin.cpp (fromEncoding)
(stringFromGpgOutput): New helpers.
(markupDiagnostics): Use it.
--
The Problem is that on my western windows system GnuPG
gets CP 437 as GetConsoleOutputCP and prints in that codepage.
In a W32 GUI Application we get 0 as GetConsoleOutputCP and 1252
with GetACP.
The only thing that seemed to somehow match was GetOEMCP but
that might just be luck and it might still be broken in
other windows languages.
This code is also used in Kleopatra so it might make sense
to make it public once it is demonstrated that it works on
most systems.
* src/gpgme-json.c (process_request): Init res. Check for
json object before encode and chunk.
--
If json is invalid we can't read chunksize and would crash
in encode and chunk.
* src/cJSON.c: Add comments on the origin of the code.
(parse_string): Allocate an extra byte for safeness.
(cJSON_AddItemToArray): Allo ARRAY to be NULL.
Signed-off-by: Werner Koch <wk@gnupg.org>
* src/cJSON.c (parse_string): Correctly detect bad hex.
--
The call to parse_hex4 checks that only hex digits follow and in the
error case returns 0. However, by the time of the combined check for
an invalid value and the error PTR has already been set to the last
hex character and thus if the end-of-string or a quote character was
one of the bad hex digits the loop will miss the end of the string
which does not match with the simple buffer length allocation test at
the begin of the function.
Signed-off-by: Werner Koch <wk@gnupg.org>
--
* src/Keyring.js: If the optional "pattern" parameter is not to be
used, but another, following parameter is, null is more of a
convention in javascript, thus both null and undefined are
interpreted as "this parameter is not meant to be set".
--
* Reflects the changes made to gpgme-json in commit
6cc842c9aa.
- getKeysArmored now returns an object with property 'armored' being
the exported armored block, and an (optional) array of fingerprint
strings for those keys that can be used in sign/encrypt operations
as property 'secret_fprs'. With this, extensions such as mailvelope
will be able to bulk fetch all necessary key information in one
request.
* src/gpgme-json.c (add_secret_fprs): New helper.
(op_export, hlp_export): Extend for with-sec fprs.
--
This is a request from Mailvelope, to import an export
they need the information for which keys from the export
a secret key is also available. For simplicity it is
much preferred to get this information in a single call
without the need to do and parse a keylisting additionally
in a second native-messaging call.
So we make it optional to include that info in the export.
--
* Fixed errors:
- src/Message.js post(): Set chunksize to defined default value instead
of hardcoded
- src/Keys.js: added getHasSecret() to refreshKey operation.
* Reviewed and updated the documentation
* non-documentation changes which do not affect functionality:
- src/Errors: disabled a console.warn that is only useful for debugging
- helpers.js: renamed "string" to "value" in isFingerprint and isLongId
to avoid confusion
- src/Keyring: prepare_sync, search are both explicitly set to false by
default
* Complete typographic overhaul.
* Removed all section level indentation since it does not affect
output formatting, but might affect source code examples.
* In text-mode stripped out all tabs which had crept in and replaced
them with four spaces.
* Updated all code examples (again) to conform with Python-mode.
* Bumped version number in preparation for next release of GPG 2.2.9
and corresponding GPGME release.
--
* Don't make a secret-Key request for each Key retrieved, use one
request for all of them instead, and assemble the info later. This
should reduce the traffic with large Keyrings. The bulk retrieval
for the public armored Keys for each of these Keys is still up to
discussion
* unittests: disabled assertion for the armored key (as it currently
doesn't work)
* encryptTest: clarified the mechanism/reason of rejection for
Messages >64 MB. This is still a TODO, as this error comes from a
different place (the browser itself) and behaves different from the
other errors.
