--
* Connection.js: In some cases, the browser disconnect does not
happen inmediately (e.g. wrong extension for the app). I added a
delay of 25 ms to see if the connection was closed by the browser.
Also, I tried to make the checkConnection more readable.
--
* Connection.js
- Add some meaningful nativeMessaging feedback for failing
communication due to misconfiguration or other browser-originated
fails
- add an "isDisconnected" property
- "isNativeHostUnknown" tries to match browser's feedback string if
the browser does not find gpgme-json
* init.js
- initialization will now reject with a more meaningful error if the
configuration is not set up or other browser-based errors
(chrome.runtime.lastError) are present. This should speed up
the normal initialization (not having to waiting for a timeout
any more in case of improper setup)
* errors.js
- CONN_NATIVEMESSAGE: New error that passes the browser's
nativeMessaging error
- CONN_NO_CONFIG: native messaging error indicating that the
nativeMessaging host was not set up properly
* unittests.js:
- added the "isDisconnected" property to the startup tests
- added tests for proper behavior of connection checks
* src/gpgme-json.c (op_createkey): Remove subkey-algo param.
(GPG_AGENT_ALLOWS_KEYGEN_TRHOUGH_BROWSER): Fix typo.
* lang/js/src/Keyring.js: Remove subkey-algo support.
* lang/js/src/permittedOperations.js: Ditto.
--
We do not want to expose details of the protocol's key generation and
thus the subkey-algo does not make sense. Right now we support only
the default and future-default algorithms. A user can configure them
anyway using new-default-key-algo in gpg.conf. Eventually we may
officially support a more flexible way of creating special structured
OpenPGP keys but right now that is not part of the API.
Signed-off-by: Werner Koch <wk@gnupg.org>
--
* src/index.js: Added an optional configuration object for the startup.
* configuration: timeout - the initial check for a connection ran into
timeouts on slower testing machines. 500ms for initial startup is
not sufficient everywhere. The default timeout was raised to 1000ms,
and as an option this timeout can be increased even further.
* BrowsertestExtension: Set the initial connection timeouts to 2
seconds, to be able to test on slower machines.
--
* src/Helpers.js: GPGME_Keys were not parsed as valid, as their
fingerprint getter is not a fingerprint 'property'.
* BrowserTestExtension: fixed a dsplay typo in counting of tests.
--
* BrowsertestExtension/tests/decryptTest.js: There were cases in which
file names returned in a wrong encoding from decryption. The test
cases here are a 'Hello World' in a text file with different names,
then being encrypted with cli gnupg.
--
* src/Helpers.js: This additional escape should 'repair' special
characters like spaces in filenames. In the strange world of
encoding there is little hope that this captures all cases, or
that it will never fail to return some value, let alone meaningful.
In my test cases it worked.
--
* BrowserTestExtension/tests:
- decryptTest.js: Check Decryption and return values of binary data
- encryptTest.js: Return data type of armored/non-armored encryption
- added a small encoded input png for testing
* DemoExtension/maindemo.js: Fixed unexpected usage of the Demo encrypt
(non-armored)
--
* src/gpgme.js: In case the encryption was done unarmored, the result
is binary data. Added an option to either return the binary data as
base64-encoded string or as Uint8Array, similar to return values of
decrypt
--
* src/Connection.js; src/permittedOperations.js: To avoid further
encoding problems, data sent by gpgme is now sorted as either
'payload' or 'info'. Payload data may come in any encoding, and here
the 'expected' and 'format' options are used, 'info' data may
contain text created by gnupg which may need re-encoding, but this
should not be affected by 'expected' and 'format'
--
* src/gpgmejs.js/encrypt: the encrypted data were converted back to a
(incorrect) string, whereas they should be data with no encoding
specified. Returning base64 data is the expected way.
* DemoExtension: caught yet another usage of old syntax.
--
* src/Helpers.js: As non-payload data might come in different
encodings, a conversion has been introduced that worked in most
cases. Data like the userid might come in different encodings,
which we don't know of. For now, a try..catch returns the data
as they are if the utf-8 decoding fails. Sometimes this yields the
correct result, sometimes it may not work, but it won't stop the
whole operation anymore.
--
* destructuring just takes the input argument and treats it as object.
In cases like in src/Keyring/generateKey, where I forgot to change
the old syntax, the fingerprint as string was destructured into an
object without "pattern", which caused all Keys to be retrieved.
So, methods with a destructuring now check if the first argument is
an object and get a default empty object if no parameter is
submitted. This allows the further use of destructured parameters,
while still ensuring nothing vastly incorrect is used.
* src/Kering.js, unittsets.js: fixed old syntax in method usage
--
* src/Connection.js: resulting data, if not pure ascii, is base64
encoded in the result message. A further decoding attempt into
javascript 'string' will be attempted by default, unless specified
at the decrypt() method. The return value 'format' now shows which
of the possibilities has been applied. The old boolean 'base64'
now turns into format:'base64' if the returned payload is a base64
string after decryption.
--
* reflecting the new optional strings accepted by the backend.
'file_name' and 'sender' can be used via the 'additional'
parameter in encrypt operations
--
* recent changes in parameter calling led to a forgotten internal call
in getDefaultKey using old syntax (and failing in case a default key
is configured)
--
* src/gpgmejs.js: Setting the default to 'always trust' assumes that
most api users will already have made their internal checks, but may
not have the gnupg web-of-trust model implemented, thus trusting the
key themselves, without gnupg having full or even any information.
Still it should stay an option to have gnupg decide.
--
* 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.
--
* 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/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.
--
* 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)
--
* 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
