We were sequentially checking for errors from 'curl_easy_perform',
'ftell', and 'fclose'. Each time overwriting the last one, resulting in
a leak. This commit ensures that 'err' is only set if it is currently
NULL, preserving the first and most specific error encountered.
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).
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
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>
`http_dl->bytes_received` was already free'd when it was accessed inside
`aesgcm_file_get()`.
Change `http_file_get()` to optionally return the number of bytes received
so we know how much data we have to decrypt.
This fixes#1994
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
* use `calloc()` to allocate zero-initialized structs.
* order the allocation of members by their declaration.
* order the freeing of members in reverse order.
* move init of `silent` flag in plugin case.
* fix double free of `tmpname` in `aesgcm_file_get()`.
* make some functions static.
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
```
==500714== Invalid free() / delete / delete[] / realloc()
==500714== at 0x484A78B: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==500714== by 0x5BDCD58: g_free (in /usr/lib64/libglib-2.0.so.0.8200.2)
==500714== by 0x49016B: http_file_put (http_upload.c:175)
==500714== by 0x5F613B1: start_thread (in /usr/lib64/libc.so.6)
==500714== by 0x5FE63D3: clone (in /usr/lib64/libc.so.6)
==500714== Address 0x86f6510 is 0 bytes inside a block of size 53 free'd
==500714== at 0x484A78B: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==500714== by 0x5BDCD58: g_free (in /usr/lib64/libglib-2.0.so.0.8200.2)
==500714== by 0x490299: http_file_put (http_upload.c:324)
==500714== by 0x5F613B1: start_thread (in /usr/lib64/libc.so.6)
==500714== by 0x5FE63D3: clone (in /usr/lib64/libc.so.6)
==500714== Block was alloc'd at
==500714== at 0x48477C4: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==500714== by 0x5F548A7: __vasprintf_internal (in /usr/lib64/libc.so.6)
==500714== by 0x5C2DD1D: g_vasprintf (in /usr/lib64/libglib-2.0.so.0.8200.2)
==500714== by 0x5BF8D97: g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.8200.2)
==500714== by 0x5BF8E58: g_strdup_printf (in /usr/lib64/libglib-2.0.so.0.8200.2)
==500714== by 0x490264: http_file_put (http_upload.c:318)
==500714== by 0x5F613B1: start_thread (in /usr/lib64/libc.so.6)
==500714== by 0x5FE63D3: clone (in /usr/lib64/libc.so.6)
```
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
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>
* destroy/free/shutdown/close in reverse order of allocation
* more static/auto_Xfree
* less variables/strlen/GString
* properly `\0`-terminate string of testcase
Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
## Summary
Partial fix for https://github.com/profanity-im/profanity/issues/1939
> When doing the same in an unencrypted (no e2ee) chat there is no Downloading… message at all but the file is downloaded.
Download a file twice with `/url save`, the second download will not print download progress to the window.
The cause is `HTTPDownload`'s `silent` variable is not initialized; so, `silent` points to a second-hand stack memory address with old data. `silent` references data, so the `if` statement will fail in **src/tools/http_download.c:206** and download progress will not print to the window.
The fix is to initialize `silent` in both encrypted and unencrypted file download scenarios.
## Testing
Valgrind: Yes
- `/url save` without OMEMO
**SUCCESS**: Try three times with the same URL and download status will display every time.
- `/url save` with OMEMO
**SUCCESS**: Try three times with the same URL and download status will display every time.
- `/plugins install https://raw.githubusercontent.com/profanity-im/profanity-plugins/master/stable/sounds.py`
**SUCCESS**: Try once and download progress is hidden.
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>
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
`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>
* Make editor executable into a string to be able to support
(multiple) flags.
* Change /help executable to suit this new feature
Signed-off-by: Daniel Santos <dacs.git@brilhante.top>
Fixes https://github.com/profanity-im/profanity/issues/1794
Explanation
The problem is the download's identifier. Downloads are given an ID so they can be referenced later when their progress changes. Currently, the download's ID is the download's URL. When you download the same file twice, you have two downloads with the same ID. Download progress updates are shown on the first of both downloads with the same ID.
Solution
Change the download's ID from its URL to a random number. A random ID is generated when get_random_string() is called from cmd_funcs.c. Several other functions are updated to cope with the new ID format.
After adding MAM quote and url autocompletion wouldn't pick up messages
from MAM or history(from DB) or would have them in the wrong order. This
commit fixes that.
Fixes https://github.com/profanity-im/profanity/issues/1770
"" used to become " now it just becomes an empty argument.
Also if quotes appeared after a token started then if the number of
quotes in the token is n the resulting one would be a token with the
n last characters cut off, now it's fixed.
Fixes https://github.com/profanity-im/profanity/issues/497
