## 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
In case the user decides to ignore the validity-state of certificates
we also have to configure libcurl accordingly.
`tls.policy` can be set via
```
/account set <account> tls trust
```
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
The profanity-internal mechanism to allow connecting to a server isn't
easily portable to cURL. Therefor introduce a profanity-specific CAfile
which is managed individually and will be configured in libcurl calls.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
* use GLib functions to write&read compose file
* trim trailing new-line characters from compose file
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
In case we're not connected yet and press Alt+c a segfault occurred
since `conn.xmpp_conn` is dereferenced while it's still `NULL`.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
This bug was introduced in 1ec606540e when
`g_strdup_printf` was used instead of `asprintf`.
Problem discoverd by raspeguy.
Mistake discovered by optmzr and Martin.
Thanks to everybody involved!
Through asprintf() we can get rid of malloc() + sprintf().
Also we don't need to calculate the strlen() again since asprintf()
returns the bytes printes.
Only non UTF-8 characters. But that was true before already.
Main changes:
1. Attributes instead of tags
2. Read the optional <header> tags and send them in the HTTP PUT header:
* Authorization
* Cookie
* Expires
Co-authored-by: Martin Dosch <martin@mdosch.de>
