| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Related to https://github.com/profanity-im/profanity/issues/1512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the following options in `omemo_bundle_publish()`:
- "pubsub#persist_items" = "true"
- "pubsub#access_model" = "open"
The same options are also used in Gajim.
I've tested this on two different servers. The bundle was successfully
added as a new PEP node. Test cases:
1. Normal use on my main account
2. Log in into a fresh tesst account on a different server
3. `/omemo clear_device_list`. In this case, the client(s) may have to
be restarted.
Note: In `_omemo_bundle_publish_result`, there's a route that is taken
when the bundle publish stanza failed. In this case, the node is
configured manually, i.e. the access_model is set to 'open'. I have
manually tested this case, but this case didn't naturally occur for me.
Note: The option "pubsub#max_items=max" is REQUIRED for the bundle
publication, as per XEP-0384. However, this is not done in other clients
(I've checked the source code of Gajim and Conversations), and it is
also not supported by Prosody. Cf. <https://github.com/xsf/xeps/pull/988>.
|
|
|
|
|
| |
Also "handle" some errors in `_omemo_bundle_publish_configure` if the
stanzas can't be found
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 9b55f2dec0ea27a9ce4856e303425e12f866cea2.
Sorting the includes creates some problems.
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1396
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
NOTE: as per XEP-0060 ยง12.20, it is RECOMMENDED for the publisher to specify an
ItemID of "current" to ensure that the publication of a new item will overwrite
the existing item.
https://xmpp.org/extensions/xep-0384.html#devices
Issue: 1329
|
| |
|
|
|
|
| |
Fixes #1239
|
|
|
|
|
|
|
|
| |
prekey is defined as `<xs:attribute name="prekey" type="xs:boolean"/>`
which allows both `true` and `1` as truthy values.
Not checking for `1` breaks omemo encryption when interacting with
clients which set prekey="1", example: psi+ 1.4.983
Regards https://github.com/profanity-im/profanity/issues/1247
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some clients (eg. PSI) are sending the stanzas delimited by whitespace
text nodes, which will fail while looping through the <prekeys/>
children and also print weird errors when iterating through the <list/>
of devices.
When debugging this, I was looking at the XML of Gajim and PSI and first
was somehow confused why Profanity printed "OMEMO: received device
without ID" while the XML looked identical (minus the actual IDs and the
JIDs of course).
However, Gajim was sending the XML without whitespace nodes in between
and PSI did not, so for example the following (with the relevant
whitespace nodes marked with X):
<message type="headline" to="..." from="...">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items type="headline" node="eu.siacs.conversations.axolotl.devicelist">
<item id="...">
<list xmlns="eu.siacs.conversations.axolotl">
X <device id="..."/>
X <device id="..."/> X
</list>
</item>
</items>
</event>
<delay xmlns="urn:xmpp:delay" stamp="..." from="..."/>
</message>
... would result in three times the "OMEMO: received device without ID"
error, because we actually have three XML text nodes here that obviously
don't have an "id" attribute.
Now since the <list/> children above aren't really a problem and only
annoying, text nodes in the <prekeys/> stanza actually cause
omemo_start_device_session_handle_bundle to return failure.
I've fixed this by explicitly matching the stanza names we are
interested in, skipping everything else.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
|
|
|
|
|
| |
We sent `prof_prefix_uuid` as id. Where the prefix was also optional.
We don't need this at all.
|
|
|
|
|
|
|
|
|
| |
omemo_key_free() was called to free the key.
It free the key->data too. But in same cases this was not set yet. So
we need to set the data to NULL (or use calloc) at initialization so
that omemo_key_free() only frees it if it was actually allocated.
Regards https://github.com/profanity-im/profanity/issues/1148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix:
```
==20561== 32 bytes in 1 blocks are definitely lost in loss record 1,467
of 3,678
==20561== at 0x483677F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20561== by 0x4B16C9: omemo_start_device_session_handle_bundle
(omemo.c:167)
==20561== by 0x43405E: _iq_handler (iq.c:214)
==20561== by 0x5AF118E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==20561== by 0x5AEDBDA: ??? (in /usr/lib64/libmesode.so.0.0.0)
==20561== by 0x5AFA43E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==20561== by 0x6818AA4: ??? (in /usr/lib64/libexpat.so.1.6.8)
==20561== by 0x681A3AB: ??? (in /usr/lib64/libexpat.so.1.6.8)
==20561== by 0x681D7EB: XML_ParseBuffer (in
/usr/lib64/libexpat.so.1.6.8)
==20561== by 0x5AF0A63: xmpp_run_once (in
/usr/lib64/libmesode.so.0.0.0)
==20561== by 0x432E5D: connection_check_events (connection.c:104)
==20561== by 0x4323B3: session_process_events (session.c:255)
==20561== by 0x42C097: prof_run (profanity.c:128)
==20561== by 0x4B260D: main (main.c:172)
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some conditions we just returned without freeing allocated variables.
Should fix following valgrind reported leak:
```
==17941== 19 bytes in 1 blocks are definitely lost in loss record 613 of
3,674
==17941== at 0x483677F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17941== by 0x5BB0DAA: strdup (strdup.c:42)
==17941== by 0x4B1592: omemo_start_device_session_handle_bundle
(omemo.c:126)
==17941== by 0x43405E: _iq_handler (iq.c:214)
==17941== by 0x5AF118E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==17941== by 0x5AEDBDA: ??? (in /usr/lib64/libmesode.so.0.0.0)
==17941== by 0x5AFA43E: ??? (in /usr/lib64/libmesode.so.0.0.0)
==17941== by 0x6818AA4: ??? (in /usr/lib64/libexpat.so.1.6.8)
==17941== by 0x681A3AB: ??? (in /usr/lib64/libexpat.so.1.6.8)
==17941== by 0x681D7EB: XML_ParseBuffer (in
/usr/lib64/libexpat.so.1.6.8)
==17941== by 0x5AF0A63: xmpp_run_once (in
/usr/lib64/libmesode.so.0.0.0)
==17941== by 0x432E5D: connection_check_events (connection.c:104)
==17941== by 0x4323B3: session_process_events (session.c:255)
==17941== by 0x42C097: prof_run (profanity.c:128)
==17941== by 0x4B2610: main (main.c:172)
```
|
|
|
|
| |
Use it to print message on red background if not trusted.
|
|
|
|
| |
Fixes https://github.com/boothj5/profanity/issues/1079
|
|
|
|
| |
Add sv_ev_connection_features_received for that purpose
|
|
|
|
| |
devicelist handler should be kept after trigger
|
| |
|
|
|
|
|
| |
We try to reconfigure node and publish again.
If it fails again then we give up.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Ensure we request device_list and remove non conforming handling of
responses.
Move initialisation of iq_handlers before call to sv_ev_login_account_success
|
| |
|
|
|
|
|
|
| |
We try to decrypt all messages, if it's successful we use
sv_ev_incoming_message even for OMEMO messages. We pass an OMEMO
boolean to let UI be aware that message were encrypted.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Devicelist subscription can be done directly with caps_add feature.
|
| |
|
|
|