Introduce meaningful color feedback for background tasks like file
downloads and uploads. Progress is displayed in a neutral color,
while successful completions turn green and failures turn red.
We reuse the existing THEME colors for now.
Add new UI flags ENTRY_COMPLETED and ENTRY_ERROR to
the buffer entry system. So we don't misuse delivery receipts anymore.
Fixes: https://github.com/profanity-im/profanity/issues/1758
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
Use the original aesgcm:// URL when downloading OMEMO downloads. Then
in the final message use the decrypted file destination instead of the
internal temporary path.
Use the unique download ID instead of the URL for message updates to
have proper progress reporting.
Unify the final transfer status to "done" across both downloads and
uploads.
Fixes: https://github.com/profanity-im/profanity/issues/1939
Signed-off-by: Michael Vetter <jubalh@iodoru.org>
```
==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>
* 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>
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
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>
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!
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>
