We deliver our builds to users with debug logging enabled to have an
easier time finding problems. However, logging all the encryption data
in this loop is too much and should not be done in release mode.
Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>
This account object was really only used during the initialization phase
or for forgetting the sensitive data. So let's receive it as parameter
there and pass it on from job to job as needed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
QtKeychain provides Qt5KeychainConfig.cmake and friends nowadays, so no
need to have a less reliable and outdated find module on our end.
Also this shows that we were including keychain.h in the wrong way and
were not using the link target, so both got fixed as well.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This way we avoid the expensive SQL query on the server at the price of
more round-trips since we're doing the recursive traversal by hand now.
Also it turns out this depth was used for all the other propfind calls
during sync when we want fresher information regarding a folder. This
was very inefficient in all cases and won't happen anymore.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We don't do much with that mimetype on our end, but other clients
somehow don't expect inode/directory to let's lie. ;-)
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
If we receive data without base64 encoding for encryption, it makes
sense to get it without base64 encoding out of decryption.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
It used to be a base64 encoded '|', now it is still a '|' but not
encoded, let's adjust accordingly.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This will turn useful for other consumers of that data. The alternative
would be to expose a method breaking all form of encapsulation.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This is not only a question of performances in our case (complexity
being better on look ups). It also provides a few more services.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The E2E application allows creating unencrypted subdirectories
in an encrypted parent. This is a big privacy problem.
This patch shows a red broken lock icon for these subdirectories
in the NC client UI.
Signed-off-by: Ivan Čukić <ivan.cukic@kde.org>
Due to usage of early-returns, combined with malloc/free,
several buffers that get allocated are leaked when an error
occurs.
Several functions had potential leaks:
- `encryptStringSymmetric` leaked `ctext`
- `EncryptionHelper::fileDecryption` leaked `out`
- `EncryptionHelper::fileEncryption` leaked `out`
Most of the functions had leaks of the cypher context.
This patch uses `QByteArray` as the handler for the dynamically
allocated buffers for openssl to operate on. This also removes
the need for conversions from malloc'd buffers to `QByteArray`
variables previously present in the code.
It also introduces a `CypherCtx` thin wrapper class to provide
a leak-free handling of `EVP_CIPHER_CTX`.
Instead of immediately popping up the mnemonic dialogue,
only show a notification bar on the account setup page.
For the cases where the user does not want to use E2E,
this is significantly less intrusive than the old approach.
When populating the tree from the filesystem we need to fill
the e2eMangledName from DB and we when trying to find another
match on the oposite tree we need to take in account that names
don't match and search with the mangled name information
Felix Weilbach