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.
If I'm not mistaken MUC PMs have not been logged at all if there was no
other client sending carbons.
This should add MUC PM logging functionality.
We still need to make sure carbons log to the same file.
Regards https://github.com/profanity-im/profanity/issues/1214
Change default themes text color
Using "default" instead of white makes the default better readable
when using a black/dark font on white/light background.
May fix#535
So far if one had enabled `/history` and did `/msg somenick` the history
was loaded from file and displayed like this:
```
04-04-17 15:23 - 3/4/2017:
01-01-00 10:30 - me: ....
01-01-00 10:31 - somebody: ....
01-01-00 10:32 - somebody: ....
```
So the first line contained the actual date. But the date used in each
line was always 01-01-2000. This date was for some reason hardcoded.
This commit now actually uses that date to build the proper GDateTime
instead of just printing it.
Fix https://github.com/profanity-im/profanity/issues/922
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
ncursesw defines _XOPEN_SOURCE macro via command-line. In particular, it
is defined in ncursesw.pc and extracted via pkg-config. From other side,
Python defines the same macro unconditionally in pyconfig.h. Python-3.x
defines the macro with value different than ncursesw does. In turn, this
causes a warning that the macro is redefined. And warnings are treated
as errors.
Since both entities define the mecro unconditionally, we can't simply
reorder headers as Python developers suggest. So, undefine the macro
just before the <Python.h> to fix this silly issue.
room is either argv[0] or allocated by GString. We have to free memory
in the 2nd case. Replace argv[0] with g_strdup(argv[0]) in order to
make unconditional g_free().
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
`sv_ev_room_message()` called `groupchat_log_msg_in()` to log all
incoming MUC messages.
`cl_ev_send_muc_msg()` calls `groupchat_log_msg_out()`.
So messages sent by the user himself was logged two times.
Filter the incoming messages and only log the ones not from our occupant
jid/nick.
Fix https://github.com/profanity-im/profanity/issues/1201
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)
```
Incoming carbons are logged as normal message already.
So we had this logged twice but didn't log outgoing carbons,
send from our account but by another client, at all.
Fix https://github.com/profanity-im/profanity/issues/1181
This theme color applies to the tab title text of the statusbar tab that
is currently shown.
The (somewhat confusingly named) `statusbar.active` theme color now
applies to all other tabs (before, it applied to all tabs).
Coloring of a tab that is highlighted/has new messages is done as before
using the `statusbar.new` theme color.
The default color is set to `cyan`, and thus causes no visible change
for users -- until modified.
Glib can print error messages to stderr and blocking write freezes
Profanity if the buffer is full. Move stderr to nonblocking mode
in hope that glib will skip printing on EWOULDBLOCK error. In this
case we lose some error messages, but Profanity continues working.
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.
Profanity uses the node part of a JID as display name for a tab. If such
a JID doesn't contain the node part, Profanity crashes on NULL pointer
dereference.
In the above case, use barejid which is just a domain. Fixes#1153.
Just to be on the safe side.
Probably only relevant for unit tests where ncurses vars are not
initialized with real values.
Fix unit tests on all platforms.
