Correctly verify that the reply to a secrets request is actually coming
from a verified device. While we did verify that it was us who replied,
we didn't properly cancel storing the secret if the sending device was
one of ours but was maliciously inserted by the homeserver and
unverified. We only send secret requests to verified devices in the
first place, so only the homeserver could abuse this issue.
Additionally we protected against malicious secret poisoning by
verifying that the secret is actually the reply to a request. This means
the server only has 2 places where it can poison the secrets:
- After a verification when we automatically request the secrets
- When the user manually hits the request button
It also needs to prevent other secret answers to reach the client first
since we ignore all replies after that one.
The impact of this might be quite severe. It could allow the server to
replace the cross-signing keys silently and while we might not trust
that key, we possibly could trust it in the future if we rely on the
stored secret. Similarly this could potentially be abused to make the
client trust a malicious online key backup.
If your deployment is not patched yet and you don't control your
homeserver, you can protect against this by simply not doing any
verifications of your own devices and not pressing the request button in
the settings menu.
* First draft of unread line feature.
* Minor visual fix.
* Removed unnecessary ternary operator.
* Extended unread line functionality to work on minimised window or focusing another window.
* Fix for unread line not showing when last read message is hidden.
* Minor performance improvement. Fix for misbehaving event2order DB at application start.
* Fix for possible performance issues when user has joined a large number of rooms.
* Fix for breaking macos and clazy builds.
* Changed on windows focus function to refresh unread line if room is unread.
* Unread line is removed when user sends a message.
* Linting.
* Fixed unread line to work in standalone room windows.
* Switch isRoomUnread for index 0.
* Merged try/catch blocks.
* Fix for crash on opening a room invite.
* Call fullyReadEventId function when used instead of storing it and passing it through.
* Function that was meant to sync the unread line was relying on an async function, oops.
* Linting again.
* More linting...
* Minor changes.
Nheko is very chatty in its log output, generating log noise (which
complicates diagnostics) and needless disk writes (which affect power
consumption and SSD life). This patch introduces command line options
and environment variables to control log levels and output type.
The old --debug command line option still works, at least for now.
It is overridden by the new command line options when they are used.
Partially addresses #665.
Experimentally, setting the database size to 2GB didn't work.
These values are quite arbitrary, and should probably be settings or
automatically adjusted.
Resolves#1069
The Matrix spec requires servers to provide thumbnails at (96x96, crop) and (320x240, scale) among others. [1] The avatars in Nheko's global/room profile and room settings are sized 130x130 on normal scaling and 260x260 on 2x scaling like on a HiDPI device. In both cases the avatar is requested as cropped and that way displayed at 96x96, making it look blurry.
This can be solved by requesting scaled avatars rather than cropped where appropriate, and cropping to the requested size afterwards.
HiDPI can be simulated in Qt by setting QT_SCALE_FACTOR=2.
[1] https://spec.matrix.org/v1.3/client-server-api/#thumbnails
