For most image formats, the header specifies the width/height.
PHP allocates an image object from that size, even if the actual
image data is much smaller. This image object size is not limited
by the limit configured in PHP.
The memory limit can be configured through "config.php" setting
"preview_max_memory" and defaults to 128 MBytes which should be
enough for most images without filling up all memory.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
This avoids fatal errors on PHP>=8, and warnings on older versions.
Log should also be clearer.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
Using escapeshellcmd to get current locale causes error
if the function is disabled.
Add fallbacks to prevent the error.
Signed-off-by: Naoto Kobayashi <naoto.kobayashi4c@gmail.com>
When php version = 8, basename('§') does not bug even if LC_ALL is non-UTF-8 locale.
This cause OC_Util::isSetLocaleWorking() to skip setlocale("C.UTF-8").
Fix it by using escapeshellcmd instead of basename.
Signed-off-by: Naoto Kobayashi <naoto.kobayashi4c@gmail.com>
Including handling in OC_Image
But also a preview provider
Of course only works if your php actually supports webp
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
