First I tried with g_uri_parse() and g_uri_to_string() but then I
learned that GUri validation API is only for things that are part of a
proper URL.
Let's cut the string at `>` since they are sometimes enclosed in `<>`.
Fix https://github.com/profanity-im/profanity/issues/1877
When we are not connected and run `/plugins install` we crash because we
get the account struct to check for the (xmpp) tls setting.
To apply that to the http (etc) connection to download the plugin from a
server.
This got introduced in 3a86b8c29 to fix#1624.
There are several ways to handle this (some described in 1880) in this
patch I took the route that it will use secure connection when we are
nto connected and will only check the tls.trust account setting if we
are connected.
Fix https://github.com/profanity-im/profanity/issues/1880
Thanks to @alarixnia fot the patch and bugreport.
```
Forwarding a bug reported using the NetBSD bug tracker ("Profanity crashes at login"): http://gnats.netbsd.org/57050
The code in question here handles messages by people not in the user's contact list, and what is probably happening is that the XMPP server is sending such a message before profanity has set up its window layout.
Setting roster.unsubscribed=false indeed makes profanity start without crashing, and the attached patch bails out early in the problematic code path if layout->subwin is NULL (Adrian verified for me that either of the two makes profanity work for him again). But I am not familiar enough with the profanity code to say if this has any issues.
Profanity compiled with ncurses doesn't crash because ncurses's wattron() has a guard against the user passing null pointers, but the X/Open curses library standard doesn't have this guarantee and there's no guard in the NetBSD curses implementation.
```
Fix https://github.com/profanity-im/profanity/issues/1769
Add ability to completely turn logs off,
Needed since `/logging` and `/history` didn't stop history logging
in the DB, only in files.
Command might break something on usage,
hence it was primarily introduced for privacy geeks.
Privacy command discussion #1836
Refactor `p_gpg_list_keys`
Add `/pgp autoimport` command,
it's not described in XEP-0027, but used in some clients,
such as PSI, Pidgin. It will autoimport keys received with
`/pgp sendpub`, in plain text as a message, or using features,
provided in other clients. It doesn't autoassign them, but shows
command to assign, letting user to decide.
Improve documentation for some preexisting functions
Add contact argument to `/pgp sendpub`
Improve documentation
Update code formatting and indentation for better readability
Show state if no argument provided
Show if argument wasn't changed
Reduce amount of arguments
Command allows to share your PGP pub key with ease,
it's not described in XEP-0027, but used in some clients,
such as PSI, Pidgin.
Fix typos
Minor improvements
The strings have to be dup'ed, otherwise we'll free them twice.
Fixes#1855
Introduced by b6bb50ceb2
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Tell the user that a MAM request will be issued delayed instead of showing
a warning that MAM isn't supported by the server.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
When compiling with `CFLAGS="-O2 -fexceptions -Wp,-D_FORTIFY_SOURCE=2"`, as
done per default when creating an AUR package e.g. via `makepkg`, this
error is produced.
Refactor `stanza_create_mam_iq()` in order to fix said warning-turned-into-
an-error.
Edit by jubalh:
I still think the error message is a false positive. But this commit improves the
code a lot.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
`MB_CUR_MAX` looks like a macro, but it's a function call and therefore
creates a VLA. We don't want that.
Also this array being uninitialized created the following Valgrind error
```
==503529== Conditional jump or move depends on uninitialised value(s)
==503529== at 0x619F15E: waddnstr (lib_addstr.c:67)
==503529== by 0x1929B7: _inp_write (inputwin.c:353)
==503529== by 0x1937D5: _inp_redisplay (inputwin.c:619)
==503529== by 0x61511B1: rl_forced_update_display (display.c:2693)
==503529== by 0x193F9D: _inp_rl_send_to_editor (inputwin.c:957)
==503529== by 0x614642F: _rl_dispatch_subseq (readline.c:916)
==503529== by 0x6146C85: _rl_dispatch_callback (readline.c:823)
==503529== by 0x616739F: rl_callback_read_char (callback.c:241)
==503529== by 0x1923DB: inp_readline (inputwin.c:188)
==503529== by 0x149860: prof_run (profanity.c:117)
==503529== by 0x2283E8: main (main.c:186)
==503529== Uninitialised value was created by a stack allocation
==503529== at 0x1928B1: _inp_write (inputwin.c:334)
```
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
`data_dir` would have been leaked if directory creation failed.
`editor_argv` was leaked at some point, no idea why.
```
==1244734== 118 (32 direct, 86 indirect) bytes in 1 blocks are definitely lost in loss record 6,299 of 7,824
==1244734== at 0x4846CC3: realloc (vg_replace_malloc.c:1451)
==1244734== by 0x5E85AD0: g_realloc (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x5E4A004: ??? (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x5E4A7B1: g_ptr_array_add (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x5EA4235: g_strsplit (in /usr/lib/libglib-2.0.so.0.7600.1)
==1244734== by 0x1F143C: get_message_from_editor (editor.c:92)
==1244734== by 0x193F6B: _inp_rl_send_to_editor (inputwin.c:950)
==1244734== by 0x614642F: _rl_dispatch_subseq (readline.c:916)
==1244734== by 0x6146C85: _rl_dispatch_callback (readline.c:823)
==1244734== by 0x616739F: rl_callback_read_char (callback.c:241)
==1244734== by 0x1923DB: inp_readline (inputwin.c:188)
==1244734== by 0x149860: prof_run (profanity.c:117)
==1244734== by 0x2283E8: main (main.c:186)
```
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
