Alan Meeson [Wed, 11 Aug 2021 18:34:23 +0000 (19:34 +0100)]
Fix truncation of files upon read when using object store and encryption.
When using and object store as primary storage and using the default
encryption module at the same time, any encrypted file would be truncated
when read, and a text error message added to the end.
This was caused by a combination of the reliance of the read functions on
on knowing the unencrypted file size, and a bug in the function which
calculated the unencrypted file size for a given file.
In order to calculate the unencrypted file size, the function would first
skip the header block, then use fseek to skip to the last encrypted block
in the file. Because there was a corresponence between the encrypted and
unencrypted blocks, this would also be the last encrypted block. It would
then read the final block and decrypt it to get the unencrypted length of
the last block. With that, the number of blocks, and the unencrypted block
size, it could calculate the unencrypted file size.
The trouble was that when using an object store, an fread call doesn't
always get you the number of bytes you asked for, even if they are
available. To resolve this I adapted the stream_read_block function from
lib/private/Files/Streams/Encryption.php to work here. This function
wraps the fread call in a loop and repeats until it has the entire set of
bytes that were requested, or there are no more to get.
This fixes the imediate bug, and should (with luck) allow people to get
their encrypted files out of Nextcloud now. (The problem was purely on
the decryption side). In the future it would be nice to do some
refactoring here.
I have tested this with image files ranging from 1kb to 10mb using
Nextcloud version 22.1.0 (the nextcloud:22.1-apache docker image), with
sqlite and a Linode object store as the primary storage.
Signed-off-by: Alan Meeson <alan@carefullycalculated.co.uk>
dependabot[bot] [Sat, 23 Oct 2021 01:04:34 +0000 (01:04 +0000)]
Update behat/behat requirement in /build/integration
Updates the requirements on [behat/behat](https://github.com/Behat/Behat) to permit the latest version.
- [Release notes](https://github.com/Behat/Behat/releases)
- [Changelog](https://github.com/Behat/Behat/blob/master/CHANGELOG.md)
- [Commits](https://github.com/Behat/Behat/compare/v3.8.0...v3.9.0)
Joas Schilling [Wed, 20 Oct 2021 08:29:45 +0000 (10:29 +0200)]
Fair use of push notifications
We want to keep offering our push notification service for free, but large
users overload our infrastructure. For this reason we have to rate-limit the
use of push notifications. If you need this feature, consider setting up your
own push server or using Nextcloud Enterprise.
Arthur Schiwon [Fri, 22 Oct 2021 20:03:29 +0000 (22:03 +0200)]
fix populating account array with missing default values
- both $userData and $defaultUserData have numeric indices
- each element contains at least the name and other fields
- appending the missing data array is sufficient
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Carl Schwan [Tue, 13 Jul 2021 15:11:48 +0000 (17:11 +0200)]
Add autocompletion for password reset
Using autocomplete="current-password" and autocomplete="new-password"
will help browser with integrated password managers to generate safe
password for the users.
See https://developer.apple.com/documentation/security/password_autofill/enabling_password_autofill_on_an_html_input_element
and https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input/password#allowing_autocomplete.
Also unify autocapitalize="none" autocorrect="off" behavior in a few
other places for password input fields.
Christoph Wurst [Fri, 22 Oct 2021 08:41:27 +0000 (10:41 +0200)]
Make the route name error more helpful
As a developer I have no clue what "Invalid route name" means. If the
exception gives me a hint I might find it easier to figure out why my
route triggers this error.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Christoph Wurst [Thu, 21 Oct 2021 12:12:36 +0000 (14:12 +0200)]
Prevent duplicate auth token activity updates
The auth token activity logic works as follows
* Read auth token
* Compare last activity time stamp to current time
* Update auth token activity if it's older than x seconds
This works fine in isolation but with concurrency that means that
occasionally the same token is read simultaneously by two processes and
both of these processes will trigger an update of the same row.
Affectively the second update doesn't add much value. It might set the
time stamp to the exact same time stamp or one a few seconds later. But
the last activity is no precise science, we don't need this accuracy.
This patch changes the UPDATE query to include the expected value in a
comparison with the current data. This results in an affected row when
the data in the DB still has an old time stamp, but won't affect a row
if the time stamp is (nearly) up to date.
This is a micro optimization and will possibly not show any significant
performance improvement. Yet in setups with a DB cluster it means that
the write node has to send fewer changes to the read nodes due to the
lower number of actual changes.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Carl Schwan [Thu, 21 Oct 2021 14:57:07 +0000 (16:57 +0200)]
Fix security issues when copying groupfolder with advanced ACL
Using advanced ACL, it is possible that an user has access to a
directory but not to a subdirectory, so the copying use
Common::copyFromStorage instead of Local::copyFromStorage.
Christoph Wurst [Wed, 20 Oct 2021 10:15:56 +0000 (12:15 +0200)]
Prevent duplicate CalDAV availability slots for recurring slots
If there is the same time slot for more than one day, then we wrote two
recurring AVAILABILITY components before. With this patch equal blocks
are combined into one recurring component. This makes the generated
rules more compact and easier to work with.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Jonas Meurer [Thu, 8 Jul 2021 16:26:27 +0000 (18:26 +0200)]
Respect user enumeration settings in user status lists
So far, the functions to find user statuses listed didn't respect user
enumeration settings (`shareapi_allow_share_dialog_user_enumeration`
and `shareapi_restrict_user_enumeration_to_group` core app settings).
Fix this privacy issue by returning an empty list in case
`shareapi_allow_share_dialog_user_enumeration` is unset or
`shareapi_restrict_user_enumeration_to_group` is set.
In the long run, we might want to return users from common groups if
`shareapi_restrict_user_enumeration_to_group` is set. It's complicated
to implement this in a way that scales, though. See the discussion at
https://github.com/nextcloud/server/pull/27879#pullrequestreview-753655308
for details.
Also, don't register the user_status dashboard widget at all if
`shareapi_allow_share_dialog_user_enumeration` is unset or
`shareapi_restrict_user_enumeration_to_group` is set.
Fixes: #27122 Signed-off-by: Jonas Meurer <jonas@freesources.org>
projects / nextcloud-server.git / log