about summary refs log tree commit diff stats
path: root/src/xmpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
| * Fix various OMEMO memleaksPaul Fariello2019-07-102-2/+13
| |
* | Fix some more potential double freesMichael Vetter2019-07-111-34/+0
|/ | | | Regards https://github.com/profanity-im/profanity/issues/1148
* Reduce codelines in form.cMichael Vetter2019-07-101-16/+2
| | | | | Let's use calloc instead of malloc and then setting almost all fields to NULL.
* Fix double free in roster_process_pending_presenceMichael Vetter2019-07-101-1/+0
| | | | This is taken care of now in the destructor _pendingPresence_free().
* Add destructor for roster_pending_presenceMichael Vetter2019-07-091-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Fix: ``` ==18682== 408 bytes in 17 blocks are definitely lost in loss record 3,279 of 3,632 ==18682== at 0x483677F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18682== by 0x42F602: roster_update_presence (roster_list.c:129) ==18682== by 0x448AA3: sv_ev_contact_online (server_events.c:906) ==18682== by 0x43D2BA: _available_handler (presence.c:674) ==18682== by 0x43C81B: _presence_handler (presence.c:398) ==18682== by 0x5AF118E: handler_fire_stanza (handler.c:124) ==18682== by 0x5AEDBDA: _handle_stream_stanza (conn.c:1253) ==18682== by 0x5AFA43E: _end_element (parser_expat.c:190) ==18682== by 0x6818AA4: doContent (xmlparse.c:2977) ==18682== by 0x681A3AB: contentProcessor (xmlparse.c:2552) ==18682== by 0x681D7EB: XML_ParseBuffer (xmlparse.c:1988) ==18682== by 0x681D7EB: XML_ParseBuffer (xmlparse.c:1957) ==18682== by 0x5AF0A63: xmpp_run_once (event.c:255) ==18682== by 0x432E5D: connection_check_events (connection.c:104) ==18682== by 0x4323B3: session_process_events (session.c:255) ==18682== by 0x42C097: prof_run (profanity.c:128) ==18682== by 0x4B25B9: main (main.c:172) ```
* Fix double free in room id handlerMichael Vetter2019-07-091-6/+1
| | | | | Free is done in destructor now. Regards https://github.com/profanity-im/profanity/issues/1148
* 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
* Fix double free regarding iq handlersMichael Vetter2019-07-081-14/+4
|
* Merge pull request #1146 from profanity-im/fix/omemoleaks-autocomplMichael Vetter2019-07-042-25/+58
|\ | | | | Fix several OMEMO related leaks
| * Free iq_id_handlers correctlyMichael Vetter2019-07-041-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | so far only the key part was freed. We also need to free the actual handler. Fix: ``` ==21171== 1,128 bytes in 47 blocks are definitely lost in loss record 3,476 of 3,670 ==21171== at 0x483677F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21171== by 0x434248: iq_id_handler_add (iq.c:265) ==21171== by 0x4B122E: omemo_devicelist_request (omemo.c:46) ==21171== by 0x4AC411: omemo_start_session (omemo.c:409) ==21171== by 0x4AC37C: omemo_start_sessions (omemo.c:396) ==21171== by 0x447881: sv_ev_roster_received (server_events.c:189) ==21171== by 0x444019: roster_result_handler (roster.c:312) ==21171== by 0x433FC2: _iq_handler (iq.c:202) ==21171== by 0x5AF118E: ??? (in /usr/lib64/libmesode.so.0.0.0) ==21171== by 0x5AEDBDA: ??? (in /usr/lib64/libmesode.so.0.0.0) ==21171== by 0x5AFA43E: ??? (in /usr/lib64/libmesode.so.0.0.0) ==21171== by 0x6818AA4: ??? (in /usr/lib64/libexpat.so.1.6.8) ==21171== by 0x681A3AB: ??? (in /usr/lib64/libexpat.so.1.6.8) ==21171== by 0x681D7EB: XML_ParseBuffer (in /usr/lib64/libexpat.so.1.6.8) ==21171== by 0x5AF0A63: xmpp_run_once (in /usr/lib64/libmesode.so.0.0.0) ==21171== by 0x432E5D: connection_check_events (connection.c:104) ==21171== by 0x4323B3: session_process_events (session.c:255) ==21171== by 0x42C097: prof_run (profanity.c:128) ==21171== by 0x4B2627: main (main.c:172) ```
| * 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) ```
* | Fix plaintext private message handlingPaul Fariello2019-07-041-3/+3
|/
* Use correct jid variableMichael Vetter2019-07-031-1/+1
|
* Define goto out in _private_chat_handler()Michael Vetter2019-07-031-0/+1
|
* Set plain message in _private_chat_handlerMichael Vetter2019-07-031-0/+7
| | | | | | In case that plain is NULL we need to copy over from body. Fix https://github.com/profanity-im/profanity/issues/1144
* Fix a segfault when carbon has no bodyPaul Fariello2019-06-211-11/+13
|
* Don't highlight cleartext message as untrustedPaul Fariello2019-06-211-0/+1
|
* Fix segfault when receiving messages without IDPaul Fariello2019-06-211-1/+3
|
* Fix NULL pointer when handling non encrypted message in MUCPaul Fariello2019-06-211-1/+9
|
* Rename prof_message_t into ProfMessagePaul Fariello2019-06-202-11/+11
|
* Add prof_message_t to wrap all message attributesPaul Fariello2019-06-202-114/+164
| | | | | | | Probably missing copy of body to plain in carbon and privmessage. Only covers the incoming message path because goal is OMEMO decryption of untrusted message. Cover some of the log functions but not all.
* Use flags in xmmp/message.c for encryption and trustPaul Fariello2019-06-202-10/+25
|
* Add trusted state after OMEMO decryptionPaul Fariello2019-06-203-11/+14
| | | | Use it to print message on red background if not trusted.
* _bookmark_destroy: follow normal logicMichael Vetter2019-06-201-7/+5
|
* Call message_handlers_clear() upon disconnectMichael Vetter2019-06-203-0/+10
| | | | Free pubsub_event_handlers. Fix memory leaks.
* Call iq_handlers_clear() upon disconnectMichael Vetter2019-06-203-0/+10
| | | | Free id_handlers. Fix memory leaks.
* statusbar: check if roster existsMichael Vetter2019-06-042-0/+9
| | | | | | | | | | | | We destory the roster in ev_disconnect_cleanup(). Adding a function to test if the roster has been destroyed and testing for it in the statusbar. So now when the connection is lost 'Lost connection' is printed in all open windows. We can then reconnect with `/connect accountname`. Should fix https://github.com/profanity-im/profanity/issues/1083
* Merge pull request #1106 from profanity-im/saved-accountMichael Vetter2019-06-031-28/+7
|\ | | | | Don't clear saved account data in session_disconnect()
| * Don't clear saved account data in session_disconnect()Dmitry Podgorny2019-06-031-28/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If connection loss occurs, it calls session_disconnect() eventually. This function clears saved account data which is required for reconnection. Therefore, when reconnect timer expires, we get errors: 02/06/2019 04:53:42: stderr: ERR: (profanity:17115): GLib-CRITICAL **: 04:53:42.305: g_key_file_has_group: assertion 'group_name != NULL' failed 02/06/2019 04:53:43: prof: ERR: Unable to reconnect, account no longer exists: (null) To solve it, don't clear the saved data in session_disconnect(). It will be cleared properly on connection loss if reconnect timer is not configured. But won't be cleared with /disconnect command. So, after /disconnect the data will live in memory until the next /connect. Also, remove some copy-paste in connection loss path.
* | Cancel autoping timer on disconnect or connection lossDmitry Podgorny2019-06-032-8/+13
|/ | | | | | | | | If Profanity is disconnected in any way before ping response is received, the autoping timer will expire after the next connection is established. As result, user will be disconnected immediately. Cancel autoping timer in ev_disconnect_cleanup(), so it is done for all kind of disconnections.
* xmpp/connection: fix #1103Dmitry Podgorny2019-06-011-11/+28
| | | | | | | | | | | | When connection is lost, profanity tries to disconnect what leads to an infinite loop. The loop occurs, because connection_disconnet() runs xmpp_run_once() separately and waits for XMPP_CONN_DISCONNECT event. But it doesn't happen, because the connection object is disconnected. As solution, don't disconnect after XMPP_CONN_DISCONNECT is received. Also, don't free libstrophe objects while the event loops executes, because the event loop continues using objects after callbacks quit.
* Update tests with new URLMichael Vetter2019-05-031-1/+1
| | | | https://github.com/profanity-im/profanity/issues/1085
* Update profanity URL in entity capabilities stanzaMichael Vetter2019-05-031-1/+1
| | | | Regards https://github.com/profanity-im/profanity/issues/1085
* OMEMO: Check if ID is present before using itMichael Vetter2019-04-241-1/+5
| | | | Fixes https://github.com/boothj5/profanity/issues/1079
* Handle presence received before rosterPaul Fariello2019-04-172-0/+44
| | | | | | | | | | Presence of contact not found in roster are filtered out. But sometimes roster is received after a first few presences. We choose to store presences until we receive roster and then process this presences. Fixes #1050
* Handle MUC anonymous state when auto starting OMEMOPaul Fariello2019-04-171-2/+14
| | | | | | | When auto joining a MUC we don't have access to required information so we just don't start OMEMO at this time. Once we receive disco info we then try to start OMEMO.
* Ensure MUC is Non-Anonymous before starting OMEMOPaul Fariello2019-04-172-0/+27
| | | | | | Store MUC anonymous type in mucwin for that purpose. Fixes #1065
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-09-10 16:26:58 +0000