about summary refs log tree commit diff stats
path: root/src/xmpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix stanza_get_child_by_name_and_from() strcmpMichael Vetter2019-11-141-1/+3
| | | | Fix https://github.com/profanity-im/profanity/issues/1227
* Add vim modelineMichael Vetter2019-11-1337-0/+105
|
* Check for correct delay tag for muc timestampsMichael Vetter2019-11-133-19/+42
| | | | | | | | | | | | | https://github.com/profanity-im/profanity/issues/1190 had another issue: Sometimes servers send multiple </delay> and we just checked the first one we got and only used it if the 'from' attribute was fitting. However it could be that we actually wanted the second </delay> element and there the 'from' would have been right. So we need to loop through them until we get the one with the fitting 'from'. Fix https://github.com/profanity-im/profanity/issues/1190
* Fix stanza_get_child_by_name_and_ns() if no nameMichael Vetter2019-11-121-1/+3
| | | | Fix bug introduced in 68af0aad65d243e654866eac5a7cd728ee293aa0.
* _handle_groupchat(): get correct origin-id stanzaMichael Vetter2019-11-083-2/+22
| | | | | | | | | | | | | | | | | | The problem is that in _handle_groupchat() we look for STANZA_NS_STABLE_ID which will result in origin-id or stanza-id. It seems like prosody servers send origin-id first, so this worked in all my tests. But actually we cannot be sure of the order. So far we stopped after the first element was found. I only found xmpp_stanza_get_child_by_ns() and xmpp_stanza_get_child_by_name() in libstrophe. But we need a combination of both. So I created stanza_get_child_by_name_and_ns() for Profanity. I need to remember to upstream this to libstrophe later (if they really don't have such a function). Fix https://github.com/profanity-im/profanity/issues/1223
* Don't override ProfMessage Id with origin-idMichael Vetter2019-10-312-19/+43
| | | | | | | | | | Profanity sends the same value for both. Other clients might not. Safe both since we could need them later. Once we implement Last Message Correction we will need the regular id. If we override it with origin-id and another client chooses to not use the same value for id and origin-id then we can't interpret the id sent with the LMC request correctly.
* 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
* Set mucuser in carbon caseMichael Vetter2019-10-291-0/+8
| | | | | | | | | | | Also we initialize mucuser properly. Now in case of a carbon of a MUC PM we sv_ev_incoming_carbon() which calls _sv_ev_incoming_plain() and then we log it via chat_log_msg_in() in there. But we also get the sv_ev_incoming_private_message() and call chat_log_msg_in() in there too. So the incoming message get's logged twice.
* Make prof_identifier constMichael Vetter2019-10-221-1/+1
|
* Display ownership of connection_get_profanity_identifierMichael Vetter2019-10-222-2/+2
|
* Use UUID in origin-id and idMichael Vetter2019-10-222-11/+11
| | | | | Let's use UUID to have a more random string then just 10 alphanumeric values.
* Remove old commentMichael Vetter2019-10-211-1/+0
| | | | | It's not up to date. Some time ago we changed from individual handlers to general ones.
* Set prof_ident to NULL after freeMichael Vetter2019-10-211-1/+2
| | | | | | | | | | | | | | | | | | This caused the bug mentioned in the PR comment: ``` It seems with the changes done here we get a crash in: src/xmpp/message.c message_handlers_init() when looking up handlers: ProfMessageHandler *handler = g_hash_table_lookup(pubsub_event_handlers, curr->data);. Steps to reproduce: open Profanity and connect /autoping set 10 /autoping timeout 10 stop WiFi/connection wait for Lost connection restart wifi /connect ```
* Rename _calculate_identifier to _compute_identifierMichael Vetter2019-10-201-3/+3
|
* Rename random_bytes to profanity_instance_idMichael Vetter2019-10-191-6/+6
|
* Free hmac and msgidMichael Vetter2019-10-192-3/+7
|
* Free prof_identifier in case of reconnectMichael Vetter2019-10-191-0/+3
| | | | Bedore we assign it new.
* Move ProfMessage and message_is_sent_by_us to xmppMichael Vetter2019-10-192-23/+24
| | | | Not meant for internal usage only.
* Change origin-id/id algoMichael Vetter2019-10-182-14/+29
| | | | | Hash twice. Use HMAC SHA256 from glib.
* Move message sent by us logic in own functionMichael Vetter2019-10-182-0/+17
|
* Add connection_get_profanity_identifier stubMichael Vetter2019-10-182-2/+2
| | | | And move defintion to xmpp.h
* Add XEP-0359 to capabilitiesMichael Vetter2019-10-181-0/+1
| | | | | | | | | | | | | We implement </origin-id> from [XEP-0359](https://xmpp.org/extensions/xep-0359.html). We already had this implemented for OMEMO. And now use it to check whether MUC messages were sent from us (https://github.com/profanity-im/profanity/issues/1201). We don't implement </stanza-id> yet, but probably need to do so for MAM. Anyways let's flag this as implementing the XEP. Fix https://github.com/profanity-im/profanity/issues/1207
* Log incoming MUC messages if origin-id sais they dont come from usMichael Vetter2019-10-182-10/+9
| | | | Regards https://github.com/profanity-im/profanity/issues/1201
* Remove prefix from stanza idMichael Vetter2019-10-1710-64/+64
| | | | | We sent `prof_prefix_uuid` as id. Where the prefix was also optional. We don't need this at all.
* Change algo for connection_create_stanza_id()Michael Vetter2019-10-171-7/+11
|
* Change connection_create_stanza_id()Michael Vetter2019-10-171-11/+11
| | | | | To return identifier and uuid together. We can remove the prefix later on.
* Calculate identifier upon connectMichael Vetter2019-10-161-5/+28
| | | | | | | This will be needed so that we can later detect if messages (origin-in) was sent by us. Regards https://github.com/profanity-im/profanity/issues/1207
* Rename identification fileMichael Vetter2019-10-161-1/+2
|
* Use random string for random-bytes identifierMichael Vetter2019-10-161-4/+5
| | | | | | And rename `instance` to `identifier`. Regards https://github.com/profanity-im/profanity/issues/1207
* Move code from jid_random_resource() into own functionMichael Vetter2019-10-161-12/+4
| | | | | Move the code that creates a random string into it's own function +get_random_string().
* Create random-bytes fileMichael Vetter2019-10-161-0/+53
| | | | | | | | | | So far only with dummy value. We will need an identifier that we can hash together with a message ID and put in as the origin-id. So when we receive message we can unsplit it and see if it was sent from this client. Regards https://github.com/profanity-im/profanity/issues/1207
* Improve MUC 1:1 loggingMichael Vetter2019-10-072-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we get a private message from a user in a MUC profanity shows this like: `profanity@roomsASDF.dismail.de/Martin: Hi` This was so far logged at: `~/.local/share/profanity/chatlogs/my-account-at-server/profanity_at_rooms.dismail.de/2019_09_04.log` as: ``` 10:48:13 - profanity@rooms.dismail.de: Hi ``` So the nickname was not saved anywhere. This is due to us not knowing whether we got a regular message from user@server.org/resource or a MUC PM from room@server.org/user. We now check for `<x xmlns='http://jabber.org/protocol/muc#user' />` and add the resourcepart to the logging if we get it. The file will be created at `~/.local/share/profanity/chatlogs/my-account-at-server/profanity_at_rooms.dismail.de_nick` and look like: ``` 23:59:43 - nick: Hi ``` Fix https://github.com/profanity-im/profanity/issues/1184
* Fix typo handel -> handleMichael Vetter2019-10-061-3/+3
|
* Fix invalid read in muc codeMichael Vetter2019-10-061-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We didn't set the variables to NULL, but the rest of the code depends on this check. ``` ==22201== Invalid read of size 8 ==22201== at 0x44E560: autocomplete_clear (autocomplete.c:69) ==22201== by 0x427B2C: muc_invites_clear (muc.c:190) ==22201== by 0x461328: ev_disconnect_cleanup (common.c:59) ==22201== by 0x463FB5: cl_ev_disconnect (client_events.c:91) ==22201== by 0x431252: cmd_disconnect (cmd_funcs.c:1234) ==22201== by 0x47E883: clears_chat_sessions (test_cmd_disconnect.c:28) ==22201== by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0) ==22201== by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0) ==22201== by 0x47F1BE: main (unittests.c:629) ==22201== Address 0x814b690 is 0 bytes inside a block of size 24 free'd ==22201== at 0x48379AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==22201== by 0x44E5F7: autocomplete_free (autocomplete.c:90) ==22201== by 0x4278A0: muc_close (muc.c:97) ==22201== by 0x47DBAA: cmd_join_uses_password_when_supplied (test_cmd_join.c:169) ==22201== by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0) ==22201== by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0) ==22201== by 0x47F1BE: main (unittests.c:629) ==22201== Block was alloc'd at ==22201== at 0x483677F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==22201== by 0x44E51B: autocomplete_new (autocomplete.c:57) ==22201== by 0x427837: muc_init (muc.c:88) ==22201== by 0x47DA77: cmd_join_uses_password_when_supplied (test_cmd_join.c:154) ==22201== by 0x487E9E1: _run_test (in /usr/lib64/libcmocka.so.0.7.0) ==22201== by 0x487ECCC: _run_tests (in /usr/lib64/libcmocka.so.0.7.0) ==22201== by 0x47F1BE: main (unittests.c:629) ```
* Detect MUC history correctly with some Prosody versionsMichael Vetter2019-09-301-1/+3
| | | | | | | | | | Some versions of prosody send the domainpart. See https://issues.prosody.im/1416 Workaround to handle those cases. Thanks to Holger Weiss for helping with this! Fix https://github.com/profanity-im/profanity/issues/1190
* Log alleged roster push to fileMichael Vetter2019-09-121-0/+1
| | | | | | | | | | https://gultsch.de/dino_multiple.html mentions CVE-2019-16235, CVE-2019-16236 and CVE-2019-16237. CVE-2019-16235: Is checking the from in carbon messages. We do that. CVE-2019-16236: Is checking the from in roster pushes. We do that but didn't log it yet. CVE-2019-16237: Is checking the form in MAM messages. We don't support them yet.
* Set message->plain in carbon caseMichael Vetter2019-09-041-1/+8
| | | | | message->plain should always contain something. In the case of the carbons we forgot to set if rom the body in case it's empy.
* Remove duplicate code in roster_updateMichael Vetter2019-08-231-9/+1
| | | | | Part of what `roster_update()` does manually is actually done in `roster_change_name()`.
* Don't render (all) delayed messages as MUC historyHolger Weiß2019-08-203-2/+20
| | | | | | | | Double-check that a <delay/> tag on a groupchat message was actually added by the MUC service (rather than the sending client) before assuming it was received from the MUC history. Fixes #1173.
* Fix memleak in /cmd execPaul Fariello2019-07-301-0/+7
|
* Fix command form submitPaul Fariello2019-07-301-1/+1
| | | | | Command form userdata were freed by iq_id_handler. We should now free the command ourself.
* Merge pull request #1160 from profanity-im/fix/1159-groupaddsegfaultMichael Vetter2019-07-221-4/+0
|\ | | | | Fix segfault in group add/remove command
| * Fix segfault in group add/remove commandMichael Vetter2019-07-221-4/+0
| | | | | | | | | | Also regarding destructor. Fix https://github.com/profanity-im/profanity/issues/1159
* | Fix memleak in roster_change_name()Michael Vetter2019-07-221-2/+2
| |
* | Fix memleak in roster_removeMichael Vetter2019-07-221-1/+1
| | | | | | | | strdup() is not needed here but will actually lead to a memleak.
* | Fix memory leak in roster_update()Michael Vetter2019-07-221-1/+2
|/ | | | current_name should not be const and should be freed.
* Fix segfault in block commandMichael Vetter2019-07-191-6/+0
| | | | | | Another case of double free() due to new destructor. Fixes https://github.com/profanity-im/profanity/issues/1156
* Fixup for last commitMichael Vetter2019-07-121-1/+0
|
* Fix segfault in iq_{submit,cancel}_command_configMichael Vetter2019-07-121-6/+0
| | | | Taken care of by the destructor.
* Merge pull request #1150 from paulfariello/hotfix/omemo-memleaksMichael Vetter2019-07-112-2/+13
|\ | | | | | | | | Hotfix/omemo memleaks Regards https://github.com/profanity-im/profanity/issues/1131
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-08-27 10:26:04 +0000