--
* src/Keyring.js: Adapted Keyring.getDefaultKey() to my current
understanding of a default signing key: either the default key set
in the gpg config, or 'the first usable private key' - usability
meaning 'not invalid, expired, revoked, and can be used for
signing'. It should be the same key used as in command line when
doing a --sign operation.
In case the user has a smartcard plugged in, we currently
won't know of this here, so our choice may differ. But as we do all
javascript-binding sign operations with the key fingerprint
explicitly set, this should not be a real problem. This method is
seen more as a convenience to tell using librarys which key
represents the main user.
--
* As a decrypt result cannot be known beforehand, the decrypt operation
may add an 'expect' property, taking either 'uint8' or 'base64',
which will return the decrypted data in the appropiate formats.
the return property 'format' will give a feedback on which option
was taken.
A test was added to reflect these changes.
--
* As requested by using parties, the options to be passed into the
methods are now objects, with the objects' properties better
describing what they do, and to avoid the need to type several nulls
in a method call if one wants the last parameter.
- src/Keyring.js, src/gpgme.js: Changed parameters and their
validations
- BrowserTest/*.js Had to adapt quite some calls to the new format
--
* src/Connection.js, src/Helpers.js: performance of decoding incoming
base64 data was improved to about 4 times the speed by introducing
two more efficient functions (thanks to rrenkert@intevation.de for
finding and testing them)
* src/gpgmejs.js: Decrypted data will now return as Uint8Array, if the
caller does not wish for a decoding. Decoding binary data will return
invalid data, and a Uint8Array may be desired. This can be indicated
by using the (new) 'binary' option in decrypt.
* src/Errors.js A new error in case this decoding fails
* src/Message.js, src/Connection.js: expected is change from base64
to binary, to avoid confusion later on.
--
* src/Signature.js/get fingerprint: A signature with no fingerprint
should not happen, but if it does, we should throw an error here,
as the method is a getter.
This adds a new language binding "gpgme.js" to GPGME. It
serves as a bridge between the native-messaging service "gpgme-json"
and JavaScript Applications.
The first user of this binding will be Mailvelope which will
see GnuPG integration in the near future.
GnuPG-Bug-Id: T4107
--
* synchronous functions should throw errors if something goes wrong,
Promises should reject. This commit changes some error cases that
returned Error objects instead of throwing them
- src/Key.js: createKey() and sync Key.get() throw errors
- src/Error.js: Exporting the list of errors to be able to test and
compare against these strings
- src/Keyring.js: Setting a null value in pattern is not useful, and
now caused an error with the new changes.
- src/Message.js: createMessage and Message.setParameter now throw
errors
--
* src/gpgmejs.js: Decrypt now parses additional optional dec_info
information, as well as any verify information, if present
* src/permittedOperations: Now decrypt also expect the new return
object dec_inf (containing info such as is_mime and file_name)
* src/gpgme-json.c (recipient_to_json, decrypt_result_to_json):
New.
(op_decrypt, hlp_decrypt): Update.
--
The op_decrypt as one of the first operations did not yet
match the current 1 <> 1 mapping of gpgme types to json
dictonaries.
info and dec_info are bad names but used for compatibility reasons.
* doc/examples/gpgme-chrome.json, doc/examples/gpgme-mozilla.json: New.
* doc/Makefile.am (EXTRA_DIST): Include them.
--
The id contained in the examples is the ID of Mailvelope.
* configure.ac: Remove js language.
--
It does not make much sense to integrate gpgme-js into the
GPGME build system. gpgme-js will be distrbuted by it's users
as part of the web extensions / their distribution as that
is the JavaScript way.
So they can use their tools etc. to compile gpgme-js JavaScript
style, which is documented in the lang/js folder.
--
* src/Keyring.js: Changed key ecpiration from Date to seconds from
creation, as in gpgme. The Date parameter used before was due to a
misunderstanding in documentation and requests from potential users.
* src/gpgme-json.c (op_createkey, hlp_createkey): Add subkey_algo
handling.
(hlp_createkey): Fix documentation of expiry.
--
Due to the funny quick-gen-key interface generating a key
with an explicit algo would result in bad defaults (only an SC key),
without a subkey.
This adds handling that should probably be in GnuPG proper to fix
the semantics of createkey by adding default subkey_algo handling.
--
* undoes 94ee0988d4 and
e16a87e839.
I do not fully understand why my approach was bad, but I am not in
a position to argue. This revert was requested to me after a review,
and I'm doing it in the assumption that more experienced people know
better than me.
* unittests: Also changed some outdated tests that stopped working
since 754e799d35 (as GPGME_Key is not
exported, one cannot check for instanceof in the tests anymore)
* import-key.py: fixed a minor typo.
* pmkey-import.py: locates and imports keys from the ProtonMail keyserver.
* pmkey-import-alt.py: the same as the previous except with setting an
alternative $GNUPGHOME directory.
* Moved the build import back up where it belongs.
* Included comments indicating how to build and install for multiple
Python versions beyond the first 2 on the same system.
* lang/python/version.py.in: Fixed most things, but there's still an
issue near the build portion with the existing Python bugs referenced.
* lang/python/setup.py.in: Now PEP8 compliant.
* PEP8 compliance for all constants except the globals in
src/constants/__init__.py depending on whether the import sequence
affects the globals themselves.
--
* Arriving strings (i.e. user id names, error messages) are not
always in javascript encoding. This is an attempt to go through
the whole gpgme answer (with the exception of payload data) and
to fix the encoding of these
--
* src/Key.js The synchronous mode for a Key does not offer an armor/
armored property anymore. This frees up a lot of performance issues,
also the armored expoort is expected to change quite often, so a
cached version is not advisable.
* hasSecret/getHasSecret is now refactored, to reflect their uses.
With get('hasSecret') there is a method that fetches the result.
* src/Key.js also some refactoring
--
* src/Key.js Key class is not exported anymore, as it should not be
used directly anywhere. setKeyData is no more a method of the Key,
(optional) data are now validated and set on Key creation and on
updates, both from within this module, thus no longer exposing
setKeyData to the outside.
* createKey now gained an optional parameter which allows to set Key
data at this point.
--
* src/Keyring.js: An empty result should no longer cause an error,
the import feedback summary has been refactored slightly
* Browsertests to reflect import feedback change
--
* src/Keyring.js I wrongly assumed an object to be a GPGME_Key,
it was the raw answer from nativeMessaging instead. Now it returns
a GPGME_Key again.
--
* src/Keyring.js: The answer was not parsed correctly, so a config was
being ignored.
* If no config is set, we return the first non-invalid key with a
secret, instead of the first key (which may be e.g. an expired one)
--
* src/Keyring.js: In case no default Key is set in configuration,
only Keys reported as having a secret part should be considered
for default Keys, avoiding some extra requests.
--
* src/Key.js: the fingerprint returned by a Key is now always upper
case hex, even if the constructor had lower case input. This is to be
more consistent with gpgme and to be more readable and reliable in
comparisions.
* lang/python/examples/howto/symcrypt-file.py: *sigh*; passphrase was
right the first time, just the error check that wasn't.
* I really should stop second guessing myself one of these days ...
Signed-off-by: Ben McGinnes <ben@adversary.org>
* 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>
