When a setting is set it locks the Settings mutex and emits a signal for that
setting. If a slot is connected to that signal and lives on the same thread as
Settings, it is executed immediately with the Settings mutex still locked. That
slot can then lock a series of other mutexes. During this time another thread
can lock a mutex and then try to read settings, which will cause a deadlock due
to the opposite order of multiple mutex locking. By always emitting signals
after unlocking the Settings mutex, we avoid holding the Settings mutex while
executing slots.
Fix#6218
Profile is required to load personal settings, and Profile was creating the
bootstraplist using personal settings. Instead create the bootstraplist in
initCore, after personal settings have been loaded. This avoids using an
uninitialized proxy type on every profile load.
- Seed random in Core Thread. Core Thread didn't seed random, resulting
in always using the same bootstrap nodes, even when you restart qTox
or change profiles.
- Use QDateTime::currentMSecsSinceEpoch() for seeding random. It
provides a bigger range of numbers than QTime::currentTime().msec()
does, and the latter somehow managed to result in approximately the
same first random number being generated, within a certain range.
- Use something a it more sensible than a mod operation to bound random
numbers within a range. It's not perfect either, but a lot better.
Using mod on random skews its distribution too much.
- Use QRandomGenerator's bounded() function to generate random values
within a range.
- Enable QRandomGenerator's usage starting with Qt 5.10.0.
QRandomGenerator is present since Qt 5.10.0, not 5.15.0.
- Bootstrap off every 5th node instead of two consecutive nodes. It's
likely that two consecutive nodes will have the same owner, which
makes some attacks more likely. The node selection algorithm should be
scraped and redone from scratch to be honest though.
This is a feature/fix to improve notification behavior when we receive
over 3 messages.
SnoreNotify prevents over 3 notifications from being displayed before a
user clears the notification. This is presumably to avoid infinite
notification spam.
Unfortunately this results in the notifications just coming in _after_
the user clears them. This means if there are 100s of messages built up
the user has to clear their notifications N messages / 3 times.
This feature/fix folds all notifications into a single notification
representing the current qTox notification state. See
notificationgenerator_test.cpp for what the new messages look like.
Previous exif transformations were not valid. The exif spec defines the
orientations as where the 0th row and the 0th column should end. The
previous mappings used in qTox did not respect these mappings and needed
to be updated.
We need to be lenient when reading from db because of ToxIds being saved in the
db from a bug introduced in e07d8d358f, which
used self ID rather than self Pk. Was subsequently fixed in
033f28e67e.
https://en.cppreference.com/w/cpp/numeric/random/random_device
"A notable implementation where std::random_device is deterministic is old
versions of MinGW (bug 338, fixed since GCC 9.2)."
Although time is less random off Windows, we don't need a strongly random
number for this, and using time avoids having to use platform specific code.
Fix#2917
