While BREACH requires the following three factors to be effectively exploitable we should add another mitigation:
1. Application must support HTTP compression
2. Response most reflect user-controlled input
3. Response should contain sensitive data
Especially part 2 is with ownCloud not really given since user-input is usually only echoed if a CSRF token has been passed.
To reduce the risk even further it is however sensible to encrypt the CSRF token with a shared secret. Since this will change on every request an attack such as BREACH is not feasible anymore against the CSRF token at least.
Storage status is saved in the database. Failed storages are rechecked every
10 minutes, while working storages are rechecked every request.
Using the files_external app will recheck all external storages when the
settings page is viewed, or whenever an external storage is saved.
From https://github.com/owncloud/core/issues/16287:
> This is caused by XCache at 8e59d4c64b/lib/private/util.php (L1276) where we are trying to reset the opcode cache with `XC_TYPE_PHP`.
> I suspect that while XCache is installed its opcode component is not used. Unfortunately, the XCache API is not really properly documented and thus I don't know what API we would have to call to check whether the `XC_TYPE_PHP` cache is populated. In fact, there is an [open XCache bug](http://xcache.lighttpd.net/ticket/176) since 7 years that discusses this problem and is likely to never get fixed since XCache is abandonware.
Fixes https://github.com/owncloud/core/issues/16287
This removes the hard-dependency on output buffering as requested at https://github.com/owncloud/core/issues/16013 since a lot of distributions such as Debian and Ubuntu decided to use `4096` instead of the PHP recommended and documented default value of `off`.
However, we still should encourage disabling this setting for improved performance and reliability thus the setting switches in `.user.ini` and `.htaccess` are remaining there. It is very likely that we in other cases also should disable the output buffering but aren't doing it everywhere and thus causing memory problems.
Fixes https://github.com/owncloud/core/issues/16013
Nobody reads the warnings anyways and so we should enforce it at installation time... Also allows us to get rid of some duplicated code.
To test change the `default_charset` to something other than `utf-8` or `UTF-8`, both should work fine with that change here. An error should then get shown.
We already set those default charsets in the shipped .user.ini and .htaccess
This changeset removes the static class `OC_Request` and moves the functions either into `IRequest` which is accessible via `\OC::$server::->getRequest()` or into a separated `TrustedDomainHelper` class for some helper methods which should not be publicly exposed.
This changes only internal methods and nothing on the public API. Some public functions in `util.php` have been deprecated though in favour of the new non-static functions.
Unfortunately some part of this code uses things like `__DIR__` and thus is not completely unit-testable. Where tests where possible they ahve been added though.
Fixes https://github.com/owncloud/core/issues/13976 which was requested in https://github.com/owncloud/core/pull/13973#issuecomment-73492969
HHVM seems to have problems with this at the moment (even setting those values in the php.ini of HHVM doesn't have helped much) and thus the unit test execution failed.
So it's better if we disable this check for now for HHVM.
Apparently `normalizer_normalize` is not verifying itself whether the string needs to be converted or not. Or does it at least not very performantly.
This simple change leads to a 4% performance gain on the processing of normalizeUnicode. Since this method is called quite often (i.e. for every file path) this has actually a measurable impact. For examples searches are now 200ms faster on my machine. Still not perfect but way to go.
Part of https://github.com/owncloud/core/issues/13221
Issue #9885 appears to be triggered by ownCloud invalidating the entire
PHP opcache. Testing indicates it can be avoided by only invalidating the
single file that was written from the opcache, instead of clearing the
whole thing. In general it is more efficient to invalidate only the single
file that was changed, rather than the whole cache.
This adds a deleteFromOpcodeCache() function which invalidates a single
file from the opcache if possible, returning true if the underlying
function returns true (which may mean 'success', or 'file does not exist',
or 'file exists but is not in opcache', all of which are OK to treat as
good for our purposes). It also changes writeData() in config.php to try
using deleteFromOpcodeCache() and only fall back on clearOpcodeCache() if
that fails.
Added addTranslations and fixed de.js file
Fixed de.js to use OC.L10N.register() and use to correct expected
format.
Added JS unit tests for OC.L10N class
Include translations JS script for all apps
This commit will make the supported DBs for installation configurable within config.php. By default the following databases are tested: "sqlite", "mysql", "pgsql". The reason behind this is that there might be instances where we want to prevent SQLite to be used by mistake.
To test this play around with the new configuration parameter "supportedDatabases".