about summary refs log tree commit diff stats
path: root/src/xmpp/omemo.c
Commit message (Collapse)AuthorAgeFilesLines
* _omemo_receive_devicelist() use if/elseMichael Vetter2020-05-291-18/+19
|
* OMEMO - Request only "current" itemDebXWoody2020-05-231-1/+5
| | | | | | | | | 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
* Fix maybe uninitialized and don't guard g_freePaul Fariello2020-01-201-17/+14
|
* Ignore invalid base64 in OMEMO stanzasPaul Fariello2020-01-201-10/+44
| | | | Fixes #1239
* omemo: Check for `1` alongside `true` in an omemo encrypted message stanzaSven Speckmaier2020-01-031-1/+3
| | | | | | | | 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
* Add vim modelineMichael Vetter2019-11-131-0/+35
|
* omemo: Check stanza names when iterating nodesaszlig2019-10-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove prefix from stanza idMichael Vetter2019-10-171-5/+5
| | | | | We sent `prof_prefix_uuid` as id. Where the prefix was also optional. We don't need this at all.
* Fix double free in omemo_start_device_session_handle_bundle()Michael Vetter2019-07-081-0/+1
| | | | | | | | | 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
* Free key on error in omemo_start_device_session_handle_bundle()Michael Vetter2019-07-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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) ```
* Rework omemo_start_device_session_handle_bundle exitMichael Vetter2019-07-041-24/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) ```
* Add trusted state after OMEMO decryptionPaul Fariello2019-06-201-2/+2
| | | | Use it to print message on red background if not trusted.
* OMEMO: Check if ID is present before using itMichael Vetter2019-04-241-1/+5
| | | | Fixes https://github.com/boothj5/profanity/issues/1079
* Wait for discovery end to publish omemo devicelist and bundlePaul Fariello2019-04-101-2/+6
| | | | Add sv_ev_connection_features_received for that purpose
* Fix devicelist notification handlerPaul Fariello2019-04-101-4/+4
| | | | devicelist handler should be kept after trigger
* Add support for missing from in bundle iqPaul Fariello2019-04-101-3/+9
|
* Handle bundle publication error on publish-optionsPaul Fariello2019-04-101-11/+100
| | | | | We try to reconfigure node and publish again. If it fails again then we give up.
* Temporarly disable check for publish-options supportPaul Fariello2019-04-101-6/+2
|
* Use connection_support to check for publish-options supportPaul Fariello2019-04-101-6/+2
|
* Add support for disconnect in OMEMOPaul Fariello2019-04-101-9/+33
|
* Add publish option to OMEMO device list and bundlePaul Fariello2019-04-101-0/+14
|
* Add MUC message decryptionPaul Fariello2019-04-101-4/+5
|
* device_list iq should be from barejid or nonePaul Fariello2019-04-101-16/+11
| | | | | | | 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
* Randomly choose a prekey on session buildPaul Fariello2019-04-101-19/+22
|
* Follow normal workflow for OMEMO message receptionPaul Fariello2019-04-101-0/+79
| | | | | | 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.
* Add OMEMO message encryption and decryptionPaul Fariello2019-04-101-2/+2
|
* Create signal sessionPaul Fariello2019-04-101-3/+47
|
* Add signal store backend and OMEMO start commandPaul Fariello2019-04-101-1/+73
|
* Request for device list when OMEMO is readyPaul Fariello2019-04-101-3/+23
|
* Fix devicelist subscription and handle pubsub eventPaul Fariello2019-04-101-8/+58
| | | | Devicelist subscription can be done directly with caps_add feature.
* Add devicelist and bundle publicationPaul Fariello2019-04-101-2/+42
|
* Add devicelist subscriptionPaul Fariello2019-04-101-0/+15