- the workflow done with /omemo_reset is now using the right methods
(encryptRatchetForwardingMessage and decryptRatchetForwardingMessage)
- fixed type error with device when calling python-omemo methods: a mix of str and int
was leading to two caches being created, and random bugs
OMEMO trust policy can now be specified. For now there are 2 policies:
- `manual`: each new device fingerprint must be explicitly trusted or not before the
device can be used, and the message sent
- `BTBV` (Blind Trust Before Verification): each new device fingerprint is automically
trusted, until user manually trust or not a device, in which case the behaviour becomes
the same as for `manual` for the entity. When using the Trust UI, user can put the
entity back to blind trust if they wish.
A message is send as feedback to user when a new device is/must be trusted, trying to
explain clearly what's happening to the user.
Devices which have been automically trusted are marked, so user can know which ones may
cause security issue.
If peer sends encrypted message and we have no encryption activated, we automatically
start encryption to avoid sending plain text message when answering.
markAsEncrypted now needs the encryption algorithm namespace as mandatory argument.
attachment handling has been simplified, and now use a "register" method similar as the
ones used for download or upload.
A default method (for unencrypted messages) will try a simple upload and will copy the
links to body.
AESGCM plugin has been adapted to be used for encrypted files. If more than one file is
sent with AESGCM plugin, they will be split in several messages as current de-facto
standard (OMEMO media sharing) doesn't support several files per message.
- async coroutine can now be used for text commands (in addition to Deferred and regular
callbacks)
- isidentifier is now used to detect a command, allowing to use "_" in command names
- if message starts with a single `/`, it is never sent (previously it could be sent is
some corner cases)
- don't use OrderedDict anymore as dict now keep insertion order by default
- max_items = 1 is requested with publish-options when publishing the bundle or the
devices list. If the constraint is failed, a warning will be shown, and the publication
will be done without this option
- fixed return values when devices list is badly formed
- sendItems is now an "async" coroutine, and sendItem use it instead of duplicating
publication logic
- policy to use when a precondition is not met (with publish-options) can now be
specified, for now it's either raise the exception (default policy), or try to publish
without the options
- constants have been added to handle "extra" keys
"path" refers to a local path of a file, we don't want to store it in database as the file
may be in a temporary location, or even be a temporary file. So once the file has been
uploaded, we remove it.
if dest_path is not set, the file will be downloaded in cache. A new name will be
generated using a hash of the uri. If the file is already downloded in cache, it won't be
downloaded again (in this case returned progress_id is an empty string).
SàT was using 16 bytes IV when sending files withr AES-GCM, due to ChatSecure being only
compatible with that. Monal, an other iOS client is only compatible with 12 bytes IV, and
ChatSecure has fixed its code to also handle 12 bytes IV, so there is not reason anymore
to use 16 bytes, and SàT now uses 12 bytes.
Android doesn't have a "/etc/resolv.conf" that Twisted expect. As a result, SRV records
can't be checked correctly on connection.
To work around that, DNS servers used on Android are checked when necessary (on Android
plugin startup and on connectivity change), using some hacks, and Twisted is patched to
use them.
`PyCrypto` is unmaintained for years but was used in SàT for password hashing. This patch
fixes that by replacing `PyCrypto` by the reference `cryptography` module which is well
maintained.
The behaviour stays the same (except that previously async `hash`, `encrypt` and `decrypt`
methods are now synchronous, as they are quick and using a deferToThread may actually be
more resource intensive than using blocking methods).
It is planed to improve `memory.crypto` by using more up-to-date cryptography/hashing
algorithms in the future.
PyCrypto is no more a dependency of SàT
instead of calling plyer's generic notify, AndroidNotification is now inherited to add a
SàT specific behaviour: a "sat_action" dictionary is now attached, to indicate to the
frontend what to do when the notification is opened.
this method will be called by frontend to know which profile to connect automatically
(when the frontend has been closed and is reopened, this will avoid to have to go through
the profileManager again).
A new Connection/autoconnect_backend param can be set for a profile or component to be
started automatically with backend. This is specially useful for components, but can be
useful for client profile too (e.g. on Android we need to start profile with backend to
get notifications, this part will come with following commits).
The new Sqlite.getIndParamValues method allows to retrieve the same parameters for all
profiles.
namespaces and encryption plugins are only retrieved once backend is ready, else they may
not yet be available (can happen notably when the backend is start at the same time as the
frontend, e.g. on Android).
- new notification sound
- vibration and notification sound are now activated depending on ringer mode (normal,
vibrate or silent)
- notification sound/vibration can be configured in settings.
- encryption is now allowed for group chats
- when an encryption is requested for a MUC, real jids or all occupants are used to
encrypt the message
- a cache for plain text message sent to MUC is used, because for security reason we can't
encrypt message for our own device with OMEMO (that would prevent ratchet and break the
prefect forward secrecy). Thus, message sent in MUC are cached for 5 min, and the
decrypted version is used when found. We don't send immediately the plain text message
to frontends and history because we want to keep the same MUC behaviour as for plain
text, and receiving a message means that it was received and sent back by MUC service
- <origin-id> is used to identify messages sent by our device
- a feedback_jid is now use to use correct entity for feedback message in case of problem:
with a room we have to send feedback message to the room and not the the emitter
- encryptMessage now only accepts list in the renamed "entity_bare_jids" argument
