When loading an encrypted profile, not entering the password and switching directly to a plaintext profile could have overwritten the plaintext profile with the encrypted one
It would only trigger when multiple instances where running in parallel,
with one having enough privilege to block the other from accessing the shared memory (e.g. root)
We returned a shallow copy of the delete[]'d salt buffer
As a result the history consistently failed to decrypt and was removed as corrupted. This is now fixed.
Profile encryption should be fairly stable. History encryption was *NOT* tested yet and as such may not work, cause profile corruption, or invoke nasal daemons.
what happened was- When message exceeded TOX_MESSAGE_LENGTH, the whole message was inserted in sender's chatlog X times.
if length of message is N,
X = (N/TOX_MESSAGE_LENGTH) + 1
There is no bug in recieving end. Receving end gets X messages (splitted).
In the sample case provided, the message had whitespaces in the end, so the reciever thought the message is empty.
* added copyright header to src/platform/statusnotifier/enums.c
* 'switch(' → 'switch ('
* use Allman style
----
for / if / while / switch () {
↓
for / if / while / switch ()
{
----
----
for / if / while ()
{
1_line;
}
↓
for / if / while ()
1_line;
----
----
for / if / while ()
1_line;
line_out_of_loop;
↓
for / if / while ()
1_line;
line_out_of_loop;
----
* Removed waitUntilProcessed() because waitUntilAccepted() fits the job. They were nearly identical too so decreased code duplication
* Global events are set as processed only by instance that accepts them. Solves issue where global event would be consumed by first instance that saw it even if that instance ignored that event
* Fixed bug where running qtox instance would not properly exit after sending window activation event that was accepted by already running instance