about summary refs log tree commit diff stats
path: root/src/xmpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Add random string at the end of the default resourcePaul Fariello2019-04-123-1/+23
| | | | | | | | When connecting for the first time or when creating a new account don't use only 'profanity' as default resource. Some server don't support having 2 connection with same resource. Using profanity as default lead to deconnections.
* Fix build on travisPaul Fariello2019-04-101-0/+2
|
* Wait for discovery end to publish omemo devicelist and bundlePaul Fariello2019-04-105-3/+34
| | | | Add sv_ev_connection_features_received for that purpose
* Rework MUC reflected message filteringPaul Fariello2019-04-104-5/+33
| | | | | | | | | Reflected messages can't be filtered by nick only otherwise you might ignore messages comming from you on another devices. Consequently we maintain a list of sent messages id in mucwin. To be sure the id will be correctly reflected we use the origin-id stanza.
* Fix devicelist notification handlerPaul Fariello2019-04-102-6/+5
| | | | 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-104-21/+164
| | | | | We try to reconfigure node and publish again. If it fails again then we give up.
* Ensure encrypted carbon of own message are marked as encryptedPaul Fariello2019-04-101-1/+1
|
* 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-103-13/+46
|
* Revert "Ensure room isn't anonymous"Paul Fariello2019-04-101-1/+0
| | | | This reverts commit 733e1a24c7e08dde6aa2c15ec4528220aa360845.
* Add publish option to OMEMO device list and bundlePaul Fariello2019-04-104-0/+57
|
* Ensure room isn't anonymousPaul Fariello2019-04-101-0/+1
|
* Log and print outgoing encrypted messagePaul Fariello2019-04-101-2/+5
|
* Add support for sending encrypted message in MUCPaul Fariello2019-04-102-5/+11
|
* Ensure saved_account is set before calling sv_ev_login_account_successPaul Fariello2019-04-101-1/+1
|
* Add MUC message decryptionPaul Fariello2019-04-102-7/+14
|