* It was documented as deprecated.
* The app code checker warned about it
* It's been three years
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This adds the Psalm Security Analysis, as described at
https://psalm.dev/docs/security_analysis/
It also adds a plugin for adding input into AppFramework.
The results can be viewed in the GitHub Security tab at
https://github.com/nextcloud/server/security/code-scanning
**Q&A:**
Q: Why do you not use the shipped Psalm version?
A: I do a lot of changes to the Psalm Taint behaviour. Using released
versions is not gonna get us the results we want.
Q: How do I improve false positives?
A: https://psalm.dev/docs/security_analysis/avoiding_false_positives/
Q: How do I add custom sources?
A: https://psalm.dev/docs/security_analysis/custom_taint_sources/
Q: We should run this on apps!
A: Yes.
Q: What will change in Psalm?
A: Quite some of the PHP core functions are not yet marked to propagate
the taint. This leads to results where the taint flow is lost. That's
something that I am currently working on.
Q: Why is the plugin MIT licensed?
A: Because its the first of its kind (based on GitHub Code Search) and
I want other people to copy it if they want to. Security is for all :)
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
The personal info section of the personal settings is querying the
storage quota information. For this it requires the FS to be setup which
is not always guaranteed.
This fixes an issue where refreshing the settings page would cause it to
fail after Redis caches are full. It is likely that when Redis cache is
populated, some code path is initializing the FS, so it works so far.
But when the cache is populated, that code path is skipped so the FS is
not guaranteed to be setup...
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Because often we catch the exception at some point and then the trace is
misleading. What's really interesting is the trace of the *previous*
exception.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The getAppPath will always return the same data for the same appId. It
is actually already cached. However we do some cleanup of the appId
(again). Same for the autoloading it is actually already checked.
This just removes the unneeded calls. Which can add up if you have a lot
of incomming shares.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Otherwise you might end up calling a lot of functions unneeded.
And while the individual calls are cheap if you multiply them by 20k
they still get somewhat expensive.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
instead of showing the generic 'Your storage is full' message, better explain that it's the group folder/external storage that is full
Signed-off-by: Robin Appelman <robin@icewind.nl>
* introduces a new IRootMountProvider to register mount points inside the root storage
* adds a AppdataPreviewObjectStoreStorage to handle the split between preview folders and bucket number
Ref #22033
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
This translation was done in each call. Over and over and over again.
All while it was probably not used in 99.99999% of the cases. A small
gain. But still.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Some apps require the composer autoloader from app.php. If we run boot
before including that file, classes and functions from dependencies
won't be found.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
while this scan *should* never be triggered, it's good to have some failsafe to ensure
that the users home contents don't end up getting scanned in the root storage
Signed-off-by: Robin Appelman <robin@icewind.nl>
Christoph Wurst
Morris Jobke
Roeland Jago Douma
Lukas Reschke
Christoph Wurst
Joas Schilling
Vincent Petry
Roeland Jago Douma
Robin Appelman
Julius Härtl
Jan C. Borchardt
John Molakvoæ (skjnldsv)