As all parts of the code invoking the `files_get_account_data_path()`
function did the same afterwards, a function has been added with the same
behavior.
1. create path
2. `mkdir` of that path
3. return final path
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Remove support for libsignal-protocol-c < 2.3.2.
Debian 10 uses 2.3.2, Debian 11 and 12 use 2.3.3.
openSUSE from 15.2 onward uses 2.3.3.
Fedora since 28 uses 2.3.2.
We should be good.
After generation of an identity we observe that `omemo_ctx.device_list`
has an entry for sender's jid. But on application restart it is absent
thus messages are not encrypted for the rest set of sender devices.
This commit fixes this by applying code for acquiring the aforementioned device list after the connection.
In profanity are two handlers for device list:
* _handle_own_device_list
* _handle_device_list_start_session
I seems both handler will start a session via
omemo_start_device_session_handle_bundle
_handle_own_device_list will also make sure, that the own device is withing the
omemo device list. If we add the _handle_device_list_start_session into the
hashmap, we are not going the republish ourself, in case we clean-up the device
list from another client.
This will maybe fix#1552
99 Little Bugs in my Code.
Take one down.
Patch it around.
113 Bugs in my Code
If we are not able to publish our own device list, we just ignored it.
This commit will show at least an error message and informs the user that this
device is currently not in the list of devices.
See Issue: #1538
Next task will be to handle the <precondition-not-met/> conflict properly.
As defined in XEP-0384 the application should not encrypt the message to own
devices. Within a groupchat, yourself are a recipients as well.
We will check the recipients and filter out the own device of the own jid.
This Pull Request will fix Issue: #1541
The most loggings has been set to debug. Just in case of error / problem the
logging should be done with log-level ERROR or WARNING.
We will see later, which loggings should be switched to log-level INFO.
This improvement has been done to find OMEMO bugs.
See also: #1070#1530#1538
If the message (key) can't be encrypted for any device, sending the
message is refused and an informative error message is presented to the
user.
Also, don't encrypt for the same device, since the OMEMO XEP disallows
this.
In 0.9.x we fixed an issue, because OMEMO devices should be defined in "item"
with id "current". This should work, but it won't work if there is no "current".
If there is no "current" we will just use the first item.
Issue #1384
Profanity requests the device list and keys for contacts, also when the user
hasn't generated the OMEMO key. If the user has no OMEMO key, there is no need
to request OMEMO information.
Issue: #1332
