about summary refs log tree commit diff stats
path: root/src/xmpp/omemo.c
Commit message (Collapse)AuthorAgeFilesLines
* Profani-tty has rebornDaniel Santos2023-07-011-4/+4
|
* Cleanup: gchar as gchar instead of charJohn Hernandez2023-05-041-4/+2
| | | | | | | | Use gchar instead of char in most of the cases where gchar is intended. Reason: improve compatibility and stability. Issue #1819 Minor refactoring.
* Add macro for possible NULL prints and use it on known sportsthe xhr2023-01-261-2/+2
| | | | | The macro is effective on OpenBSD and basically a no op on other platforms. Use it for one existing and the other known debug statements.
* Check if string is NULL and print placeholder insteadthe xhr2023-01-261-1/+1
| | | | OpenBSD's kernel warns about NULL printfs. Fix this with a standard check.
* auto-formatSteffen Jaeckel2022-02-011-1/+1
| | | | Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
* omemo: log when no pubsubMichael Vetter2021-12-131-0/+4
| | | | Closes https://github.com/profanity-im/profanity/issues/1621
* Format code correctlyMichael Vetter2021-10-051-9/+8
|
* Fix memleakPaul Fariello2021-08-201-0/+2
|
* Log error received while publishing OMEMO device listPaul Fariello2021-08-201-1/+2
|
* OMEMO: Fix precondition-not-met handlingPaul Fariello2021-08-191-5/+14
|
* Create devicelist if it doesn't existsPaul Fariello2021-08-191-1/+18
|
* OMEMO: try device list creation and reconfigure on precondition-not-metPaul Fariello2021-08-191-6/+24
|
* Ensure devicelist access model is configured before updating itPaul Fariello2021-08-191-23/+92
|
* OMEMO - Unable to publish own device listDebXWoody2021-06-011-0/+16
| | | | | | | | | | 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.
* Improved OMEMO loggingDebXWoody2021-05-281-8/+15
| | | | | | | | | | | 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
* Add config.h in files were it was missingMichael Vetter2021-03-261-0/+2
| | | | Related to https://github.com/profanity-im/profanity/issues/1512
* [OMEMO]: Fix bundle publishingMaximilian Wuttke2021-03-091-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>.
* Logging [OMEMO]Maximilian Wuttke2021-03-091-1/+26
| | | | | Also "handle" some errors in `_omemo_bundle_publish_configure` if the stanzas can't be found
* Logging [OMEMO]Maximilian Wuttke2021-03-091-6/+10
|
* Apply coding styleMichael Vetter2020-07-071-118/+116
|
* Revert "Apply coding style"Michael Vetter2020-07-071-116/+118
| | | | | | This reverts commit 9b55f2dec0ea27a9ce4856e303425e12f866cea2. Sorting the includes creates some problems.
* Apply coding styleMichael Vetter2020-07-071-118/+116
| | | | Regards https://github.com/profanity-im/profanity/issues/1396
* Messages are not shown in ChatSecureDebXWoody2020-07-041-20/+39
| | | | | | | | 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
* _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
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-06-27 02:24:15 +0000