| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Since this object has to be verified against a signature it also carries
there's a rather specific procedure described in The Spec for that.
That procedure basically assumes handling the signed one-time key
object as a JSON object, not as a C++ object. And originally Quotient
E2EE code was exactly like that (obtaining the right QJsonObject from
the job result and handling it as specced) but then one enthusiastic
developer (me) decided it's better to use a proper C++ structure -
breaking the verification logic along the way. After a couple attempts
to fix it, here we are again: SignedOneTimeKey is a proper QJsonObject,
and even provides a method returning its JSON in the form prepared for
verification (according to the spec).
|
|
|
|
This is mainly to plug the definition of a string-to-variant map
for one-time keys (see
https://spec.matrix.org/v1.2/client-server-api/#key-algorithms) into
the CS API generated code (see the "shortcut OneTimeKeys" commit for
gtad.yaml); but along with it came considerable streamlining of code
in qolmaccount.cpp. Using std::variant to store that map also warranted
converters.h to gain support for that type (even wider than toJson()
that is already in dev - a non-trivial merge from dev is in order).
|
|
As mentioned in the commit introducing `Expected`, `QOlmExpected` is
simply an alias for `Expected<T, QOlmError>`. This simplifies quite
a few function signatures in `QOlm*` classes and collapses unwieldy
`std::holds_alternative<>`/`std::get<>` constructs into a neat
contextual bool cast and an invocation of `operator*` or
`value()`/`error()` accessors that don't need to specify the type.
While refactoring the code, I found a couple of cases of mismatching
`uint32_t` and `qint32_t` in return values; a couple of cases where
`decrypt()` returns `QString` which is in fact `QByteArray` (e.g., in
`QOlmSession::decrypt()`); there's a repetitive algorithm in
`Connection::Private::sessionDecryptPrekey()` and
`sessionDecryptGeneral()`
|
|
Making Qt signals const is an impossible commitment - once the signal
is out, you can't control if any called slot will change the emitting
class or not. The code compiles but const-ness is not preserved.
|
|
|
|
We don't seem to need sorted associative containers in those cases.
|
|
A note on switching to QLatin1String for JSON key constants - this is
more concise and barely affects (if at all) runtime performance (padding
each QChar with zeros is trivial for assignment; and comparison can be
done directly with the same performance as for two QStrings).
|
|
Co-authored-by: Alexey Rusakov <Kitsune-Ral@users.sf.net>
|
|
|
|
|
|
|
