| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
| |
Proof of concept.
Needs error checking, a nice interface, general cleanup..
|
|
|
|
| |
Add a `/avatar` command.
|
|
|
|
| |
So far we just subscribe and get the IDs.
|
|
|
|
| |
Fix https://github.com/profanity-im/profanity/issues/1227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 bug introduced in 68af0aad65d243e654866eac5a7cd728ee293aa0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Let's use UUID to have a more random string then just 10 alphanumeric
values.
|
|
|
|
|
| |
It's not up to date.
Some time ago we changed from individual handlers to general ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
| |
|
| |
|
| |
|
|
|
|
| |
Bedore we assign it new.
|
|
|
|
| |
Not meant for internal usage only.
|
|
|
|
|
| |
Hash twice.
Use HMAC SHA256 from glib.
|
| |
|
|
|
|
| |
And move defintion to xmpp.h
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Regards https://github.com/profanity-im/profanity/issues/1201
|
|
|
|
|
| |
We sent `prof_prefix_uuid` as id. Where the prefix was also optional.
We don't need this at all.
|
| |
|
|
|
|
|
| |
To return identifier and uuid together.
We can remove the prefix later on.
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
And rename `instance` to `identifier`.
Regards https://github.com/profanity-im/profanity/issues/1207
|
|
|
|
|
| |
Move the code that creates a random string into it's own function
+get_random_string().
|
|
|
|
|
|
|
|
|
|
| |
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)
```
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Part of what `roster_update()` does manually is actually done in
`roster_change_name()`.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Command form userdata were freed by iq_id_handler.
We should now free the command ourself.
|
|\
| |
| | |
Fix segfault in group add/remove command
|
| |
| |
| |
| |
| | |
Also regarding destructor.
Fix https://github.com/profanity-im/profanity/issues/1159
|
| | |
|
| |
| |
| |
| | |
strdup() is not needed here but will actually lead to a memleak.
|