Turns out that when we added a new e2e folder during sync, we were
passing the wrong path to the e2e object. We have several path
convention in the sync code, just happened to be the wrong one.
I still long for the day when we'll use the type system to deal with
paths. All those strings are error-prone.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Other clients seem to allow creating empty encrypted folders with no
metadata associated to them, so let's get ready to handle it. In case of
a 404 to get the metadata, we create an empty metadata payload and pass
it further down.
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>
We need to finish deleting the file before we can actually unlock. Also
the token will be necessary for the delete to succeed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The headers() method is used to pass extra headers to the PUT jobs for
instance, definitely needed for uploads now.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
- The default displayed was not in sync with the server because
the client was setting permissions when creating a share while it
should get the default permissions from the server to display it to the
user first.
Signed-off-by: Camila <hello@camila.codes>
This is in line with other bools of that struct and gets rid
of clang-tidy's modernize-use-default-member-init warning.
(The trivial alternative to get rid of that warning would be
to use default member init for that bool variable, but I think
it is better to have it as a bitfield.)
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
The value gets already initialized by default member initialization,
so there is no need to set it again in the constructor.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
The value gets already initialized by default member initialization,
so there is no need to set it again.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
The value gets already initialized by default member initialization,
so there is no need to set it again in the copy constructor.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
PR #1451 changed the behavior of makeDbName which now returns an
absolute path. This obviously then failed in nextcloudcmd which
prepended to it the path to the local folder to sync. We just stop doing
this to have the journal db end up at the right place in that case as
well.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
If we try to produce the avatar before we managed to connect we'd end up
trying to paint in a null image. Just return early, which will allow the
caller to do something else instead.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The XML we get as reply has href entities properly percent encoded.
Since we didn't go through QUrl next we didn't get a properly decoded
version. Make sure we decode it before storage.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
The menus may become too large if they have too many items
(the account menu has this in case of many accounts, the apps
menu in case of many apps). This commit limits the maximum
height such that the menus do not hide the header.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Turns out that the ListView embedded in the Menu (reachable via
contentItem) would create a binding loop if we're using its
childrenRect. But really we're interested in the total width for the
instantiated delegate *inside* the ListView. That's why we go one level
deeper and get the childrenRect of the inner contentItem instead.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
- Use QEventLoop for synchronous exec()
- Rename startAwait() to exec()
- Add code for auto deletion
- Add new DeleteJob class
- Cleanup, tweaks
Signed-off-by: Michael Schuster <michael@schuster.ms>
When specified in the config file, the Proxy password will be migrated
to the keychain, for backward compatibility and to allow admins to
overwrite an existing password by rolling out updated config files.
Once migrated to the keychain, the password will be removed from the
config file.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Awaits completion with no need to connect some slot to the finished() signal first,
inspired by the ProxyAuthHandler class.
Also add:
- Job dtor to safely erase passwords
- textData() method
- New ctor overloads to work with arbitrary keys (without Account ptrs)
Signed-off-by: Michael Schuster <michael@schuster.ms>
Originally this was in the WebFlowCredentials class. Since we've abstracted everything
from there already, let's also move this in case some other code may use
KeychainChunk::ReadJob prior to WebFlowCredentials.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Ultimately we would avoid the code duplication by creating our own
proper QQC2 style instead of directly tuning everything. That's a battle
for another time (more elements would need to be adjusted for that, I
don't want to dilute this branch too much).
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
If the file has a mangled name or will end up in a parent directory
known to be encrypted, we stick to the CSYNC_INTRUCTION_NEW instead of
going for CSYNC_INSTRUCTION_RENAME. This way we'll have a delete and an
upload instead of a move command.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
When the ClientSideEncryption object is fed, also serialize the
encryption info of the folders inside the metadata table.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This will allow to exploit the information of a directory being
encrypted or not during the discovery phase.
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>
We used to do it when the propagation starts, let's do it even before
the discovery starts. This way we'll have a chance to exploit the
information during the discovery phase.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
- The code handling the api response was not up to date with the latest
api changes.
- Unlimited quota display: use qint64 to avoid data loss
- Change total with quota: total holds the quota total and not the storage total.
Signed-off-by: Camila <hello@camila.codes>
Update systray behavior and context menu:
- left click brings up the new QtQuick based dialogs on all latforms
- right click brings up the new QtQuick based dialog on Mac OS only
- right click brings up a context menu on all other platforms than Mac OS
- "Quit Nextcloud" => "Exit Nextcloud"
- Add "Open main dialog" option.
Signed-off-by: Camila <hello@camila.codes>
With the current design of the file upload this necessarily pushed to a
lock starvation on the folder. Indeed you could end up with N jobs
asking for the lock at the same time. So just avoid parallelizing for
now even though it will be slow.
We could try to optimize but that'd require some serious changes to the
sync logic on the jobs... let's stabilize first and optimize later.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
During the wizard we currently don't have much information about the
encrypted folders. In particular we can only display their mangled names
which is far from ideal for the user to make an informed choice.
That's why in the wizard we now forbid creation of subfolders in e2ee
folders and we also don't display subfolders of e2ee folders.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Since the e2e oracle works only in term of absolute remote paths and
that our model x._path was relative, we need to properly convert.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
In such cases we get a download for which _file is already the demangled
name and _encryptedFileName has the mangled information. This is
different to what we encountered so far where initially _file was
mangled and _encryptedFileName was empty. Let's deal with that case
properly.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise on second sync we wouldn't find anything under a mangled path
and just end up thinking said files were removed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise, after a first sync all the mangled entries would be removed
from the journal. On second sync it would be fine because we'd then have
seen the unmangled names because of the local files. Unfortunately
that'd mean reuploading them for nothing or trying to mkdir again on the
server for nothing... with a chance of using differently mangled names
(although I didn't spot it, I can't exclude it never happened).
This also led to weirdly getting stuck during sync when there was more
than one sync point.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Yes... I still wish this would be all driven by the type system, would be
much less error-prone.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
I wish this would be all driven by the type system instead of
error-prone string concatenation everywhere. That will be for a (much)
later refactoring hopefully.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
It turns out this job expected an absolute remote path even in the case
of a subfolder sync point.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This was half broken before that commit and the previous one since some
of the categories would not be captured.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Otherwise it was a bit confusing and annoying for filter rules:
e.g. "nextcloud.sync.*" vs "sync.*".
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This means adjusting PropagateDownloadEncrypted so that it knows where
the file will end (otherwise it would create temporary files in non
existant paths for instance).
In turn we have to adjust PropagateDownloadFile accordingly so that it
resolves the local folder the file will end up in.
And last we adjust PropagateLocalMkdir to resolve paths as well and
demangle as needed.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We give them a parent to make sure they will be destroyed when the jobs
which created them are destroyed themselves.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
PropagateUploadEncrypted made the assumption of the folder names never
being mangled. This is not true since the previous commits so make sure
we properly deal with that using the journal db.
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>
We ensure the PROPFIND Depth is infinity by explicitly specifying the
header (turns out our implementation just doesn't assume infinity
otherwise). This way we have a clear picture about *all* the folders of
the user, otherwise ClientSideEncryption couldn't be a trustable oracle
on the encryption state for any folder not on the root and all the
encryption code assumes it has a full picture of encryption.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
We catch when a directory is inside a known encrypted folder and in such
a case we now do the following:
1) we encrypt the folder meta data (its name) properly and create it
under that mangled name on the server side
2) we mark the new folder itself as encrypted
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
It was assuming we'd encrypt only files but directory names also need to
be encrypted. We just skip the writing to temp file part in that case.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This way this whole logic isn't stuck into the settings dialog anymore.
Also cleaned up the unused "decrypt folder" logic.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
This is a much better place than the GUI, this way we ensure the
propagator is always operating of up to date information. Previously if
the propagator kicked in without user interaction from startup (not
showing the settings dialog) it would have no E2E information available
whatsoever... unsurprisingly it would thus take wrong information at
every turn.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Since we want to move to a place where the encryption of subfolders is
always enforced it makes no sense to leave it in control of the user.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
