Both deprecated since NC 23
IAppManager is the replacement for OCP\App unfortunately it can't be
dependency injected in classes used by the installed otherwise the
database connection is initialised too early
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
The command is meant to be used when the fonts used to render texts
("core/fonts/NotoSans-Regular.ttf" and "core/fonts/NotoSans-Bold.ttf")
are changed (for example, to add support for other scripts). The avatar
and text file previews will be removed, so they will be generated again
with the updated font when needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* removes the ability for users to import their own certificates (for external storage)
* reliably returns the same certificate bundles system wide (and not depending on the user context and available sessions)
The user specific certificates were broken in some cases anyways, as they are only loaded if the specific user is logged in and thus causing unexpected behavior for background jobs and other non-user triggered code paths.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Encrypt the keys with the instance secret
* Store them as json (so we can add other things if needed)
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* `php occ preview:repair` - a preview migration tool that moves existing previews into the new location introduced with #19214
* moves `appdata_INSTANCEID/previews/FILEID` to `appdata_INSTANCEID/previews/0/5/8/4/c/e/5/FILEID`
* migration tool can be stopped during migration via `CTRL+C` - it then finishes the current folder (with the previews of one file) and stops gracefully
* if a PHP memory limit is set in the `php.ini` then it will stop automatically once it has less than 25 MiB memory left (this is to avoid hard crashes in the middle of a migration)
* the tool can be used during operation - possible drawbacks:
* there is the chance of a race condition that a new preview is generated in the moment the folder is already migrated away - so the old folder with the newly cached preview is deleted and one cached preview needs to be re-generated
* there is the chance of a race condition during access of a preview while it is migrated to the other folder - then no preview can be shown and results in a 404 (as of now this is an accepted risk)
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
getRepairSteps is quite expensive (because every repair step is
initialized and their dependencies are injected). Should not
call it during register.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
This adds persistence to the Nextcloud server 2FA logic so that the server
knows which 2FA providers are enabled for a specific user at any time, even
when the provider is not available.
The `IStatefulProvider` interface was added as tagging interface for providers
that are compatible with this new API.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Fixme:
- Install and update of apps
- No revert on live systems (debug only)
- Service adjustment to our interface
- Loading via autoloader
Signed-off-by: Joas Schilling <coding@schilljs.com>
* success on SQLite and Postgres
* failure on MySQL due to the limited charset that only supports up to 3 bytes
Add config option to update charset of mysql to utf8mb4
* fully optional
* requires additional options set in the database
only disable unicode test on mysql
Fixing ctor call
Adding docker based unit test execution for mysql utf8mb4
Add mysqlmb4 test configuration to Jenkinsfile
fix collation on utf8mb4
Properly setup charset and collation in the doctrine connection
Allow files containing 4-byte chars in case the database supports it
During setup of a mysql database we try to detect if charset 'utf8mb4' can be used
Fix mysql settings
Add console command to migrate the charset
Set ROW_FORMAT before setting collation to mb4
Also select tables with wrong collation
Faster MySQL docker
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Single user mode basically disables WebDAV, OCS and cron execution. Since
we heavily rely on WebDAV and OCS also in the web UI it's basically useless.
An admin only sees a broken interface and can't even change any settings nor
sees any files. Also sharing is not possible.
As this is at least the case since Nextcloud 9 and we haven't received any
reports for this it seems that this feature is not used at all so I removed it.
The encryption commands now rely on the well tested maintenance mode.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Don't parse info.xml but reuse already cached app infos - fixes#25603
* Use === in InfoParser. Fixes test
* InfoParser should not depend on UrlGenerator - fixes issue with session being closed too early
- Updated the config sample to point to log_type='file'
- Renamed the Class for logfile logging to File in namespace 'OC\Log\'.
Changed the occurrences of 'OC\Log\Owncloud' to 'OC\Log\File'.
- Renamed the Class for log:file command to File in namespace 'OC\Core\Command\Log\File'.
Changed registration of the command to use 'OC\Core\Command\Log\File'.
- Changed default Syslog tag to Nextcloud
- Retained backwards compatibility for configs with 'logtype' => 'owncloud'
- Adjusted tests for the new file log.
Closes#490.
The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur
l` entry and then derives the `RewriteBase` from it.
This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc.
This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…)
Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if
admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`.
For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master.
Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9.
Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
This change requires the usage of a path instead of the App ID when signing code. This has the advantage that developers can also sign code under a different location to make it easier. (e.g. remove `.git`, …)
Also it adds an example command usage as well as a link to the documentation
This PR implements the base foundation of the code signing and integrity check. In this PR implemented is the signing and verification logic, as well as commands to sign single apps or the core repository.
Furthermore, there is a basic implementation to display problems with the code integrity on the update screen.
Code signing basically happens the following way:
- There is a ownCloud Root Certificate authority stored `resources/codesigning/root.crt` (in this PR I also ship the private key which we obviously need to change before a release 😉). This certificate is not intended to be used for signing directly and only is used to sign new certificates.
- Using the `integrity:sign-core` and `integrity:sign-app` commands developers can sign either the core release or a single app. The core release needs to be signed with a certificate that has a CN of `core`, apps need to be signed with a certificate that either has a CN of `core` (shipped apps!) or the AppID.
- The command generates a signature.json file of the following format:
```json
{
"hashes": {
"/filename.php": "2401fed2eea6f2c1027c482a633e8e25cd46701f811e2d2c10dc213fd95fa60e350bccbbebdccc73a042b1a2799f673fbabadc783284cc288e4f1a1eacb74e3d",
"/lib/base.php": "55548cc16b457cd74241990cc9d3b72b6335f2e5f45eee95171da024087d114fcbc2effc3d5818a6d5d55f2ae960ab39fd0414d0c542b72a3b9e08eb21206dd9"
},
"certificate": "-----BEGIN CERTIFICATE-----MIIBvTCCASagAwIBAgIUPvawyqJwCwYazcv7iz16TWxfeUMwDQYJKoZIhvcNAQEF\nBQAwIzEhMB8GA1UECgwYb3duQ2xvdWQgQ29kZSBTaWduaW5nIENBMB4XDTE1MTAx\nNDEzMTcxMFoXDTE2MTAxNDEzMTcxMFowEzERMA8GA1UEAwwIY29udGFjdHMwgZ8w\nDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANoQesGdCW0L2L+a2xITYipixkScrIpB\nkX5Snu3fs45MscDb61xByjBSlFgR4QI6McoCipPw4SUr28EaExVvgPSvqUjYLGps\nfiv0Cvgquzbx/X3mUcdk9LcFo1uWGtrTfkuXSKX41PnJGTr6RQWGIBd1V52q1qbC\nJKkfzyeMeuQfAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAvF/KIhRMQ3tYTmgHWsiM\nwDMgIDb7iaHF0fS+/Nvo4PzoTO/trev6tMyjLbJ7hgdCpz/1sNzE11Cibf6V6dsz\njCE9invP368Xv0bTRObRqeSNsGogGl5ceAvR0c9BG+NRIKHcly3At3gLkS2791bC\niG+UxI/MNcWV0uJg9S63LF8=\n-----END CERTIFICATE-----",
"signature": "U29tZVNpZ25lZERhdGFFeGFtcGxl"
}
```
`hashes` is an array of all files in the folder with their corresponding SHA512 hashes (this is actually quite cheap to calculate), the `certificate` is the certificate used for signing. It has to be issued by the ownCloud Root Authority and it's CN needs to be permitted to perform the required action. The `signature` is then a signature of the `hashes` which can be verified using the `certificate`.
Steps to do in other PRs, this is already a quite huge one:
- Add nag screen in case the code check fails to ensure that administrators are aware of this.
- Add code verification also to OCC upgrade and unify display code more.
- Add enforced code verification to apps shipped from the appstore with a level of "official"
- Add enfocrced code verification to apps shipped from the appstore that were already signed in a previous release
- Add some developer documentation on how devs can request their own certificate
- Check when installing ownCloud
- Add support for CRLs to allow revoking certificates
**Note:** The upgrade checks are only run when the instance has a defined release channel of `stable` (defined in `version.php`). If you want to test this, you need to change the channel thus and then generate the core signature:
```
➜ master git:(add-integrity-checker) ✗ ./occ integrity:sign-core --privateKey=resources/codesigning/core.key --certificate=resources/codesigning/core.crt
Successfully signed "core"
```
Then increase the version and you should see something like the following:
As you can see a failed code check will not prevent the further update. It will instead just be a notice to the admin. In a next step we will add some nag screen.
For packaging stable releases this requires the following additional steps as a last action before zipping:
1. Run `./occ integrity:sign-core` once
2. Run `./occ integrity:sign-app` _for each_ app. However, this can be simply automated using a simple foreach on the apps folder.
