The to_native_str function was supposed to produce Unicode decoded
native strings for python2 and python3.
Upon further consideration this doesn't make much sense since under
python2 it would need to decode the bytes into a Unicode string and turn
it back into a python2 str.
The ability to use the replacement character requires us to use a
Unicode string under python2 as well.
This patch changes the decryption functions not to fail if there was an
unicode decode error while converting the decrypted bytes plaintext into
a native python string.
Characters that cannot be decoded as unicode are now replaced with the
unicode replacement character (U+FFFD).
The old behaviour of raising an UnicodeDecodeError can be achieved by
passing the "strict" error handling scheme to the decrypt function.
This patch adds bindings to the PK part of the Olm library contained in
the pk.h header file.
Encryption, decryption as well as pickling/unpickling of the decryption
object is supported.
Signed-off-by: Damir Jelić <poljar@termina.org.uk>
This is a workaround for a bug where signature verification would
overwrite the variable holding the signature.
This only happens on python2.
Signed-off-by: Damir Jelić <poljar@termina.org.uk>
This commit imports the python bindings from:
https://github.com/poljar/python-olm
The bindings are imported at commit c44b145818520d69eaaa350fb95afcb846125e0f
Minor modifications were made while importing:
- Removed travis config
- Removed Arch Linux PKGBUILD
- Removed the html docs, they can be rebuild by running make html in
the docs folder
- Slightly modified the README
The new bindings feature some improvements over the old ones:
- Python 2 and 3 support
- Automatic memory management
- Automatic memory clearing before it is freed
- Type signatures via the python typing module
- Full test coverage
- Properties are utilized where it makes sense (e.g. account.id)
Signed-off-by: Damir Jelić <poljar@termina.org.uk>
Ed25519 private keys, it turns out, have 64 bytes, not 32.
We were previously generating only 32 bytes (which is all that is required to
generate the public key), and then using the public key as the upper 32 bytes
when generating the per-message session key. This meant that everything
appeared to work, but the security of the private key was severely compromised.
By way of fixes:
* Use the correct algorithm for generating the Ed25519 private key, and store
all 512 bits of it.
* Update the account pickle format and refuse to load the old format (since we
should consider it compromised).
* Bump the library version, and add a function to retrieve the library
version, so that applications can verify that they are linked against a
fixed version of the library.
* Remove the curve25519_{sign, verify} functions which were unused and of
dubious quality.
