When a user added an account, set it as autoconnect and then removed
that account. It still was set as the autoconnect account.
```
/account add test
/autoconnect set test
/account remove test
/save
/quit
Start profanity
```
Fix https://github.com/profanity-im/profanity/issues/1976
libsignal does this properly, so there wouldn't be a real double free, but
it will `abort()`.
Instead of destroying the identity key on disconnect, already destroy it
after it has been put into the libsignal 'ratchet identity key pair'.
In the case where the key pair is initially generated, the public
and private parts are only `ref()`'ed once in [0].
In the case where the key pair is read from the disk, the public
and private parts are `ref()`'ed twice, first when decoded in [1] resp.
[2] and a second time in [3].
When `omemo_on_disconnect()` is called we were `unref()`'ing the parts
twice, before this patch. First in [4], a second time in [5] resp. [6].
Now we do the second `unref()` already when loading.
[0] `signal_protocol_key_helper_generate_identity_key_pair()`
[1] `curve_decode_point()`
[2] `curve_decode_private_point()`
[3] `ratchet_identity_key_pair_create()`
[4] `ratchet_identity_key_pair_destroy()`
[5] `ec_private_key_destroy()`
[6] `ec_public_key_destroy()`
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
When users receive a message and a subscription request from a new
contact, and they use `/blocked report-abse JID` or `/blocked
report-spam JID` they most likely want the subscription request to
vanish as well.
According to mdosch Conversations is behaving like this too.
Fix: https://github.com/profanity-im/profanity/issues/1970
## 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.
Revert "Merge pull request #1943 from H3rnand3zzz/gmainloop
This reverts commit 609fde099857d4d9b2bd8d421bdb0a5059a53dfc, reversing
changes made to 2ec94064ed341f0ea5b197a283c6ebfb15716bd0.
Revert "Merge pull request #1948 from H3rnand3zzz/fix/rl-less-refreshes"
This reverts commit 11762fd2b0cc9a82c08a32bb58e25bb6def0e597, reversing
changes made to 609fde099857d4d9b2bd8d421bdb0a5059a53dfc.
We have got several issues, that we don't quite see how to solve, with
the merge of the gmainloop PR.
* Slashguard is broken (#1955) (though #1956 could fix that)
* One person reported problems with copy paste selection via mouse
* Some input buffer seems not to be cleared correctly
It happened that I was debugging profanity used `/connect` and typed
the password. I then debugged so long that a time out occurred, so
profanity disconnected. Then it printed "unknown command: $password".
There was something else that I forgot now.
Bottomline is: so far we didn't get it right so we will undo these
changes until someone proposes a working solution.
We got a slight performance increase (apparently noticable when
alt+mouse scrolling) but got too many issues with this change.
When user was scrolling down using alt + mouse wheel/arrows, he would be
stuck in most of the cases after the buffer finishes
due to the part of code that moves the "cursor" up to show full last page.
New algorithm considers close to border cursor as passing for
DB loading condition,
at the same time it calculates offset, allowing flexible scroll size.
The problem was introduced by @H3rnand3zzz in the following commit:
23692fedff4ec3a8c01e61697893450995bcbd3d
The redisplay function in keyboard handling event was introduced by @rodarima
in the following commit:
7eac636fc80016dbf18eea60a7d59576dd2a4925
At the point first commit introduction it made sense, but later
the following commit added proper handling of input redisplay.
ccede06a658bf609ba5cf5b536740d4983b02603
This change was overlooked by me and introduced in #1943.
Potential solution for #1947.
Feature discovery was marked as finished once we received a reply to the
initial request. The discovery mechanism allows to delegate the real
feature discovery to another service running on different domain and those
requests are created dynamically.
This was another instance causing the warning message described in #1940Fixes#1940 (once more)
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Before there was a problem of overscrolling:
when messages longer than y axis of the terminal are fetched from the DB,
profanity scroll "jumps" to the top, skipping some messages.
It's resolved by keeping messages' starting and ending line in the
internal profanity buffer, which allows to track proper message positions
and to adjust window position accordingly.
Message size is now tracked as part of the buffer's record in `_line`
variable, which allows calculation of the total buffer size, which
might be a part of the improved solution for the "underscrolling" problem,
if we are going to limit profanity's buffer size by amount of lines as
opposed to the limitation based on the amount of message which is currently
used.
Before adding a limitation by amount of lines, careful consideration is
required, as some users don't use history and their temporary message
history can be cut to minimal limit because of 1 long received/sent message.
Underscrolling problem was fixed in a previous commit
d7e46d64fe6bc9926eb404dad6a4803e1fc2e8b2
Short recap of the problem:
Despite user scrolling to top/bottom of history,
factual position is offset from the intended location
Another feature of this commit is a minor change which adds fetching
message stanza IDs from the DB. It allows correcting messages
fetched from history.
Fixes https://github.com/profanity-im/profanity/issues/1934
* 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>
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>
1. close logfile as last action
2. Fix `plugins_shutdown()` accessing `((ProfPlugin*)curr->data)->lang`
after `curr->data` had already potentially been free'd.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Reset the `received_disco_items` flag when initializing the iq module.
This has caused the console error message "Server doesn't support MAM"
sometimes on reconnect.
Fixes#1940
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Before this patch the following scenario lead to a segfault:
1. open a window that sends a MAM request
2. fast enough close that window again before the MAM response was
processed
Once the MAM response is received we'd call `_mam_rsm_id_handler()`
from the `_iq_handler()` and `window` would point to a non-existant window
which leads to a segfault.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Fixup/revert of e55f6d7f4d831d370001999d55dafea9888a4a9f
This line had been added because an earlier release of libstrophe missed
the initialisation of that variable, which has since been fixed.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
