Those functions set proper content-types that prevent rendering of
data. Therefore it's safe to mark them as sanitizers.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Previously there was no (platform) dependency check for an app that was
installed before. So Nextcloud happily upgraded an app that now requires
a php version newer than the current one. Which means in the lucky case
you see a failing upgrade due to the language incompatibility, or in the
unlucky case you see unexpected errors later in production.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* 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>
Christoph Wurst
Roeland Jago Douma
Julius Härtl
Lukas Reschke
Joas Schilling
Roeland Jago Douma
Morris Jobke
Christoph Wurst
Joas Schilling
Vincent Petry
Robin Appelman
J0WI
Jan C. Borchardt
John Molakvoæ (skjnldsv)