Correctly handle OMEMO stanzas that contain a <header> but no <payload>.
These "Key Transport Messages" (heartbeats) are used by some clients
for session maintenance and establishing trust.
Ref: a2726b6a7 made the <payload> element mandatory in the parser.
Ref: 4d49c2b74 the bug became user-visible.
Fixes: https://github.com/profanity-im/profanity/issues/2129
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Replace the hardcoded "me" stamp for outgoing messages that are
sometimes used with the value from PREF_OUTGOING_STAMP.
It was never implemented in all code paths. Like with receipts for
example.
Additionally fix the confusing description and variable names.
Ref: 2c003dd2 (Add /stamp feature)
Ref: 3a4cd7da (Broke the variables)
Fixes: https://github.com/profanity-im/profanity/issues/2125
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
If an incoming OMEMO message failed to decrypt (due to missing session
keys or untrusted identities), Profanity would fall back to displaying
the raw XMPP body. This usually contained a generic string like "This
message is encrypted with OMEMO,".
We wrote the detailed reason in the debug logs but the user only saw the
fallback message and probably wondered *why* the message wasn't
displayed properly.
I'm unsure if we should display the fallback message as well though.
Migrate structure allocations from calloc to glibs g_new0 macro to
improve type safety and memory robustness.
* Type Safety: The macro takes the type name directly, ensuring the
allocated size always matches the pointer type.
* Static Analysis: It guarantees a non-NULL return by aborting on
failure, which silences -fanalyzer warnings regarding potential NULL
pointer dereferences.
* Readability: Removes redundant sizeof() calls and is the glib way
While trying to get the unit tests working again I stumbled over all those
things that I thought could be better^TM.
Now we also know "TODO: why does this make the test fail?" - because
the unit tests are brittle AF ... and we have to init the subsystems
we use in the test, otherwise the cleanup will fail...
BTW. you can now also only run a single test ... or a pattern or so ...
you'd have to read how `cmocka_set_test_filter()` works exactly.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Use a singleton `Jid` inside the connection instead of always re-creating
a `Jid` from the same string.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Disallow correcting historical MUC messages, as the XEP-308 requires.
Previous changes introduce problem with
"Illicit LMC attempt from conference@server/user for message from user"
During investigation it was revealed that XEP does not recommend support
of historical MUC messages correction.
```
When used in a Multi-User Chat (XEP-0045) context,
corrections must not be allowed (by the receiver)
for messages received before the sender joined the room -
particularly a full JID leaving the room
then rejoining and correcting a message SHOULD be disallowed,
as the entity behind the full JID in the MUC may have changed.
```
https://xmpp.org/extensions/xep-0308.html#rules
XEP details mentioned by @jubalh
Bug discovered and solution improved by @jaeckel
Sometimes the server is too busy sending other stanzas or our connection is
saturated because of something else, so the pong arrives too late.
Prevent the autoping disconnect event by extending the timeout
each time a stanza is received.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
This also fixes a memory leak from within `_handle_groupchat()` in [0].
[0] src/xmpp/message.c
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Messages would get duplicated when you chat with yourself, worse if you
had omemo enabled the duplicated message would say something along the
lines of "Your client doesn't support OMEMO". The cause was carbons
when the message was sent from another client, whilst it was a sent
and received message when profanity was the one to send it. This commit
ignores the carbon message in the 1st case and ignores the received one
in the 2nd.
Fixes https://github.com/profanity-im/profanity/issues/1595
Muc configuration in profanity used to not update until next login, ie:
make muc non_anonymous and members_only but be unable to start omemo
until next login. Now a disco info request is sent after forrm submit
and chatroom details are changed accordingly.
Fixes https://github.com/profanity-im/profanity/issues/1347
We only want to have the decrypted message or the alternative body in
message->plain.
Also let's print error messages if it makes sense and log other issues.
Partly addresses the commit in the comit mesage of:
2dc0cc489c
Fix https://github.com/profanity-im/profanity/issues/1693
```
@StefanKropp @DebXWoody please check `_handle_ox_chat()` I don't
understand what you are doing there.
1)
First plain is assigned `message->plain =
p_ox_gpg_decrypt(xmpp_stanza_get_text(ox));`
and then in the same if block you overwrite this with `message->plain =
xmpp_stanza_get_text(b);` without freeing the old value as far as I can
see.
2)
Sometimes even doing `message->plain = "OX error: No payload found";`.
Shouldn't there be a `strdup()`? I think later on we try to free the
whole message struct. So we can't mix this static things.
```
Like mentioned on the review at
https://github.com/profanity-im/profanity/pull/1605 I don't ge why
@DebXWoody changed the code like he did.
I changed it to something that made more sense to me now.
Instead of looking for headline in two places and checking for pubsub in
a headline place (only).
I didn't check this deeply. And still have a feeling that this is not
the best way to go. But I didn't read the XEP yet.
Added a TODO to the code regarding this too.
A quick skimming through https://xmpp.org/extensions/xep-0107.html
doesn't show me anything regarding headline. So I really don't see why
this needs to go here.
Hopefully @DebXWoody checks this in the future. But since he didn't
react on the PR I decided to make some adjustments myself so we can
merge it.
We came into the carbons checking code when we received `<private
xmlns="urn:xmpp:carbons:2"/>`. Which actually marks a message to _not_
be a carbon.
In this code we also make sure that carbons only come from us.
If not we don't call the message handler code.
So we should actually only check for `<sent xmlns='urn:xmpp:carbons:2'>`
and `<received xmlns='urn:xmpp:carbons:2'>`.
Thanks pukkamustard and Holger.
Fixes https://github.com/profanity-im/profanity/issues/1614
