aboutsummaryrefslogtreecommitdiffstats
path: root/lang (unfollow)
Commit message (Collapse)AuthorFilesLines
2018-08-30python bindings: estreams fixben/estreams-fixBen McGinnes1-7/+7
* lang/python/src/core.py: Adjusted new_from_estream function to alias new_from_stream instead of fd. * fixed the _gpgme import errors introduced in commit 08cd34afb762975b0273575035dacf69449ef241 by changing the exported functions/types to match the inner module where all the work is done, rather than the outer one(s). Tested-by: Ben McGinnes <[email protected]> Signed-off-by: Ben McGinnes <[email protected]>
2018-08-29js: return base64 after encrypt with armor=falseMaximilian Krambach2-3/+7
-- * 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.
2018-08-29python bindings: coreBen McGinnes1-6/+7
* lang/python/src/core.py: expanded gpgme_error check lists.
2018-08-29python bindings: coreBen McGinnes1-0/+1
* lang/python/src/core.py: added gpgme_data_set_flag to the errorcheck funtion.
2018-08-29python bindings: coreBen McGinnes1-1/+7
* lang/python/src/core.py: added new function new_from_estream to wrap new_from_fd just like new_from_stream does and for the same reason.
2018-08-29docs: python bindings - protonmail examplesBen McGinnes3-1/+17
* lang/python/docs/GPGMEpythonHOWTOen.org: Updated links to the ProtonMail keyserver import scripts and added a warning regarding being unable to update third party keys. * lang/python/examples/howto/pmkey-import-alt.py: added usage. * lang/python/examples/howto/pmkey-import.py: added usage.
2018-08-28docs: python bindings HOWTOBen McGinnes1-13/+24
* Finished CFFI vs SWIG bit in known issues. * tidied up some of the structure. * Fixed some minor errors and links.
2018-08-28docs: python bindingsBen McGinnes1-3/+22
* Added section on why no CFFI.
2018-08-28docs: python howtoBen McGinnes1-0/+94
* Added another key import example using ProtonMail's new keyserver.
2018-08-27docs: python bindingsBen McGinnes1-1/+157
* Added details on installation troubleshooting.
2018-08-27js: small documentation updateMaximilian Krambach1-1/+2
--
2018-08-27js: make non-payload data more encoding-tolerantMaximilian Krambach1-1/+8
-- * 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.
2018-08-27js: typecheck destructured parametersMaximilian Krambach3-20/+40
-- * 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
2018-08-27js: extend information on decoding in decryptMaximilian Krambach2-3/+9
-- * 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.
2018-08-27js: fix file_name return on decryptMaximilian Krambach1-17/+17
-- * src/gpgmejs: Line 228 checked the wrong variable. To avoid further confusion, _result was renamed to returnValue in the whole file
2018-08-24js: add new options to permittedOperationsMaximilian Krambach1-0/+6
-- * reflecting the new optional strings accepted by the backend. 'file_name' and 'sender' can be used via the 'additional' parameter in encrypt operations
2018-08-23js: fix syntax inside Keyring methodsMaximilian Krambach1-1/+2
-- * 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)
2018-08-23js: offer an always-trust parameter on encryptMaximilian Krambach1-1/+7
-- * 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.
2018-08-23js: use destructured option parametersMaximilian Krambach3-107/+66
-- * Adds to f0409bbdafcbd4f8b0be099a6b3ce0d5352c9bcd and makes use of destructuring, allowing for defaults, and cleaning up the validation.
2018-08-23js: update getDefaultKey to more precise logicMaximilian Krambach1-1/+6
-- * 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.
2018-08-22js: add decrypt result optionsMaximilian Krambach4-12/+44
-- * 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.
2018-08-22js: make method parameters objectsMaximilian Krambach11-309/+385
-- * 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
2018-08-22js: improve decryption performanceMaximilian Krambach5-19/+100
-- * 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 [email protected] 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.
2018-08-22js: Return error if signature has no fingerprintMaximilian Krambach1-1/+4
-- * 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.
2018-08-22js: changed verify signature result infosjavascript-bindingMaximilian Krambach2-21/+28
-- * the resulting information of verify now are as documented, and the same as in a decrypt callback
2018-08-22js: throw errors in sync functionsMaximilian Krambach6-61/+76
-- * 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
2018-08-21js: update decrypt/verify resultsMaximilian Krambach4-12/+49
-- * 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)
2018-08-21js: remove outdated checklistsMaximilian Krambach3-36/+0
-- * They are heavily outdated and offer no more useful information
2018-08-21js: Fix library name mentioned in js MakefilesAndre Heinecke4-15/+15
--
2018-08-21js: Update extra_dist filesAndre Heinecke2-2/+4
* lang/js/BrowserTestExtension/Makefile.am, lang/js/Makefile.am (EXTRA_DIST): Update.
2018-08-21js: Improve READMEAndre Heinecke1-9/+36
* lang/js/README: Clarify structure at the beginning.
2018-08-21js: set expiry of generatedKey to seconds from nowMaximilian Krambach1-6/+4
-- * 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.
2018-08-20js: add option "subkey-algo" to generateKeyMaximilian Krambach2-2/+14
-- * The option was recently added to gpgme-json; this reflects this on javascript side
2018-08-20js: set expiry date on generateKeyMaximilian Krambach1-1/+2
-- * on the javascript side a Date is expected, gpggme-json expects seconds from 'now'
2018-08-20js: add and apply eslint rulesMaximilian Krambach25-397/+421
-- * mainly spacing, see .eslintrc.json for details
2018-08-20js: revert changes to class read/write restrictionMaximilian Krambach9-1255/+1164
-- * undoes 94ee0988d4eaac27785de6efb7c19ca9976e1e9c and e16a87e83910ebb6bfdc4148369165f121f0997e. 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 754e799d35fd62d7a979452f44342934659908c7 (as GPGME_Key is not exported, one cannot check for instanceof in the tests anymore)
2018-08-19Python bindings examplesBen McGinnes3-1/+251
* 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.
2018-08-18Python bindings setup fileBen McGinnes1-2/+11
* 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.
2018-08-18Python bindings tests: Near PEP8 complianceBen McGinnes31-500/+773
* PEP8 compliance for the vast majoeity of the tests.
2018-08-18Python bindings examples: PEP8 conplianceBen McGinnes12-35/+49
* Appears to be complete compliance.
2018-08-18Python bindings setup: Near PEP8 complianceBen McGinnes2-89/+119
* 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.
2018-08-18Python bindings constants: PEP8 compliance (almost)Ben McGinnes19-35/+29
* PEP8 compliance for all constants except the globals in src/constants/__init__.py depending on whether the import sequence affects the globals themselves.
2018-08-18Python bindings src: PEP8 complianceBen McGinnes5-13/+18
* import namespace clearance for src/*.py. * Fixed a handful of is/is not None checks as well.
2018-08-17js: decode arriving gpg message stringsMaximilian Krambach4-4/+76
-- * 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
2018-08-17js: correct decrypt result info (2)Maximilian Krambach1-3/+3
-- * the permittedOperation from last commit ended up in the wrong place. sign does not return an additional 'info' object.
2018-08-17js: expect additional 'info' to arrive on decrypt, tooMaximilian Krambach1-1/+2
-- * src/permittedOperations.js: if decrypt includes a verification, this info needs to pass, too.
2018-08-17js: decrypt callback is_mime fixMaximilian Krambach1-1/+3
-- * src/gpgmejs: is_mime should report its' counterpart. Also, file_name is not optional in specification. We'll send null if there is no file_name
2018-08-17js: don't expire new keys if no date is setMaximilian Krambach1-0/+2
-- * src/Keyring.js A new Key without expiration is documented as 'never expire' here, and should behave accordingly. This requires sending '0' here.
2018-08-17js: small documentation fixMaximilian Krambach1-6/+7
--
2018-08-17js: removed Key.armor property in synchronous useMaximilian Krambach4-93/+145
-- * 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