MAM messages don't have a type nor a from.
If we detect a message without type let's log it and exit without
continuing to try to parse it.
Otherwise we go into _handle_chat() and crash on the no from.
The function creates a form to find such strings as software, os, etc.
It remembers the strings allocated by form_create() and use them below
in caps_create(). The issue is that the form is destroyed before and as
result the strings are freed too.
As solution, allocate own copy of strings.
Timestamps are only set if a message is delayed.
If none is set let's set it upon recaival so we don't have to set it
when it gets displayed.
This means we will also have it for logs etc in the ProfMessage.
xmpp_stanza_add_child() takes own reference to the child stanza.
Therefore we have to release our reference or the child is lost
and not freed otherwise.
The memory leak happens when a presence is received for a MUC room. The
JID is not present in the roster, so updating its status is ignored. We
have to free resource in this case, because it has no owner and is lost
otherwise.
==25736== 47 (32 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 1,625 of 3,399
==25736== at 0x4A330FF: malloc (vg_replace_malloc.c:309)
==25736== by 0x13A962: resource_new (resource.c:47)
==25736== by 0x145501: _available_handler (presence.c:665)
==25736== by 0x145501: _presence_handler (presence.c:399)
==25736== by 0x145501: _presence_handler (presence.c:358)
==25736== by 0x80D5F34: handler_fire_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80D2B49: _handle_stream_stanza (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x80E15CE: _end_element (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x843EE9B: doContent (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x843F94B: contentProcessor (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x8441E77: XML_ParseBuffer (in /usr/lib64/libexpat.so.1.6.10)
==25736== by 0x80D586B: xmpp_run_once (in /usr/lib64/libstrophe.so.0.0.0)
==25736== by 0x13E07E: connection_check_events (connection.c:119)
==25736== by 0x13869C: prof_run (profanity.c:129)
Fixes#1279.
win_println_incoming_muc_msg() always used the current time. Now let's
use whatever is sent int he message struct (from the delay stanza or
the current time that we set now once the message is received).
No playing with the time upon display anymore.
If we are connected with another client and send a message, then correct
it. We now display it correctly in Profanity.
Id wasn't saved for carbon copied messages too so far.
So far the correction is sent. But the UI in Profanity itself is not
updated.
Also autocompletion for `/correct` with the last sent message is
missing.
So far we saved the timestamp which also had the `from`.
But we need this only to find out whether it's MUC history.
For displaying we should use the oldest delay timestamp.
Also in
61f66966dd (diff-4926fd4577a336bd3eb240f8104a5c5bL837)
a error was introduced.
Before we saved the timestamp in all cases. And only if timestamp AND
from was given we went into MUC history case.
Normal timestamp saving was not done anymore only if it also had a from
attribute.
Regards https://github.com/profanity-im/profanity/issues/1254
So far we got the first delay with a from that comes from the server.
This way we know it's MUC history.
Now we take the first time stamp we actually find. Which is likely the
one being added first. And should contain the correct time to display.
It would be nicer to actually compare the dates though.
Regards https://github.com/profanity-im/profanity/issues/1254
Cannot be configured for now.
Can be set via `adv.notify.discoversion` in the `notification` section.
Will notify about version requests via XEP-0092 and XEP-0232.
Client version can still be seen via caps (capabilities).
See `stanza_attach_caps()`.
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
So far we removed the avatar feature only after a succesful retrive in
avatar_request_item_by_id() before we are going to retrieve the actual
image.
We should remove it at every `/avatar barejid` call too so in case one
retrieval was unsucessful that we can call it again.
So far it seems like there is no other way to trigger getting the nodes
except announcing that we support the avatar feature.
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
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
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.
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
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.
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
```
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
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
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)
```
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.
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:
```
==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)
```
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
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)
```
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)
```
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)
```
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.
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
