Make get_random_string() return a gchar*.
This is part of the effort to migrate string declarations and
allocations from char to gchar, replacing standard C allocators
(malloc/calloc/strdup) with their glib equivalents
(g_malloc/g_new0/g_strdup).
The primary goal is to prevent mismatched allocator bugs. While char and
gchar are binary compatible, mixing their respective deallocators is
dangerous:
* Freeing malloc'd memory with g_free() (or vice versa) can lead to
memory corruption, double-frees, or crashes.
* This is seems to be the case especiall on non Linux platforms or when
using hardened memory allocators where the GLib slice allocator or
wrappers may differ from the system heap.
By standardizing on gchar, we ensure that our automatic cleanup macros
(like auto_gchar) always invoke the correct deallocator (g_free).
Also refactor the function so we pass it the current version
and don't rely on the define inside of it.
This function only allows version format in the style of "x.y.z".
* Add new TLS policy `direct` as a replacement for `legacy`.
* Document that `/[command]?` prints the help of a command.
* Add option to get help via `/command help`.
* Fix `my-prof.supp` generation and tests for out-of-source builds.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Several users have reported segfaults when starting up profanity which
has OMEMO support, but OMEMO is not set up yet.
@StefanKropp has been able to reproduce this and tracked it down to
`_load_identity()` calling `omemo_known_devices_keyfile_save()`.
The latter then calls `save_keyfile()` which calls
`g_key_file_save_to_file()`. This can then fail if one of the first two
strings is NULL and won't set the `error` on return. In its error handling
`save_keyfile()` unconditionally dereferences `error` which leads to the
segfault.
Fix this and also go through the entire codebase and verify that the usage
of `GError` is done correctly.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
Instead of adding stuff to `_shutdown()`, we can now register a shutdown
routine from the respective `init()` function of our modules.
This also has the advantage, that we're sure they're called in reverse
order from how the initialization happened.
I didn't simply use `atexit()` because POSIX says that the number of
possible callbacks is limited (min 32) and I was not sure whether
we will maybe extend this number at one point.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
* Fix missing destruction of `session_store` and mutex
* Replace `glib_hash_table_free()`
The glib API `g_hash_table_destroy()` does exactly the same.
* Use the default libsignal `destroy_func` instead of doing that manually
* Set internal state to `0` after everything is cleaned up
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>
Move `p_sha1_hash()` from `common.c` to `xmpp/stanza.c` as it is only
used in this file and now depends on libstrophe so xmpp is a better
namespace folder.
Renaming it as `_stanza_create_sha1_hash()`. And making static since
only used here.
The function cannot be tested in the unit tests anymore.
Once functional tests are working again we should write a test for the
sha1 functionality.
create_unique_id() was changed to use UUIDs instead of a counter in the
last commit. Since now it depends on connection_create_uuid() which is
in the xmpp subfolder the function should also be moved there.
Renamed it to connection_create_stanza_id() and moved it to
src/xmpp/connection.c.
Discussion happened in https://github.com/boothj5/profanity/pull/1010
Message IDs should be unique so they can be used by XEPs like delivery receipts, chat markers, message correction.
So far it used a counter so restarting profanity will cause the counter
to be 0 again.
Let's rather use an UUID since we have such a function in the
xmpp/xmpp.h already.
Closes https://github.com/boothj5/profanity/issues/998
