- Jun 19, 2018
-
-
Roeland Jago Douma authored
Fixes #9867 Signed-off-by:
Roeland Jago Douma <roeland@famdouma.nl>
-
- Jun 13, 2018
-
-
Morris Jobke authored
* renamed hasMissingIndexes to missingIndexes Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Jun 06, 2018
-
-
Morris Jobke authored
* gives the admin a chance to discover the missing indexes and improve the performance of the instance without digging through the manual * nicely integrated in the setup checks where this kind of hints belong to * also adds an option to integrate this from an app based on events * fix style of setting warnings Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Apr 05, 2018
-
-
Roeland Jago Douma authored
Signed-off-by:
Roeland Jago Douma <roeland@famdouma.nl>
-
- Feb 15, 2018
-
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Feb 14, 2018
-
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Dec 13, 2017
-
-
Roeland Jago Douma authored
Signed-off-by:
Roeland Jago Douma <roeland@famdouma.nl>
-
- Dec 08, 2017
-
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Nov 06, 2017
-
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Oct 17, 2017
-
-
Bjoern Schiessle authored
Signed-off-by:
Bjoern Schiessle <bjoern@schiessle.org>
-
- Apr 20, 2017
-
-
Joas Schilling authored
Signed-off-by:
Joas Schilling <coding@schilljs.com>
-
- Mar 16, 2017
-
-
Ko- authored
-
- Feb 23, 2017
-
-
Morris Jobke authored
Signed-off-by:
Morris Jobke <hey@morrisjobke.de>
-
- Sep 06, 2016
-
-
Joas Schilling authored
-
- Aug 15, 2016
-
-
Lukas Reschke authored
-
- Aug 09, 2016
-
-
Arthur Schiwon authored
* interfaces for the Admin settings (IAdmin) and section (ISection) * SettingsManager service * example setup with LDAP app
-
- Jul 26, 2016
-
-
Morris Jobke authored
-
- Jul 21, 2016
-
-
Joas Schilling authored
-
Derek authored
-
- May 26, 2016
-
-
Lukas Reschke authored
-
- Apr 06, 2016
-
-
Lukas Reschke authored
-
- Feb 12, 2016
-
-
Lukas Reschke authored
Our issue template states that users should post the output of `/index.php/settings/integrity/failed`, at the moment it displays that all passes have been passed if the integrity checker has been disabled. This is however a wrong approach considering that some distributions are gonna package Frankenstein releases and makes it harder for us to detect such issues. Thus if the integrity code checker is disabled (using the config switch) it displays now: `Appcode checker has been disabled. Integrity cannot be verified.` This is not displayed anywhere else in the UI except these URL used for us for debugging purposes.
-
- Feb 01, 2016
-
-
Vincent Chan authored
fixes #20199
-
- Jan 12, 2016
-
-
Thomas Müller authored
-
- Dec 01, 2015
-
-
Lukas Reschke authored
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.
-
- Oct 26, 2015
-
-
Lukas Reschke authored
-
- Oct 20, 2015
-
-
Robin McCorkell authored
-
- Oct 08, 2015
-
-
Lukas Reschke authored
This change makes the check return a positive result when: - The instance has been configured to not use the internet AND/OR - S2S AND the appstore is disabled
-
Lukas Reschke authored
-
- Oct 06, 2015
-
-
Morris Jobke authored
-
- Oct 05, 2015
-
-
Morris Jobke authored
-
- Sep 02, 2015
-
-
Morris Jobke authored
-
- Aug 10, 2015
-
-
Robin McCorkell authored
-
- Jul 29, 2015
-
-
Roeland Jago Douma authored
-
- Jul 28, 2015
-
-
Lukas Reschke authored
This will detect old NSS and OpenSSL versions and show appropriate errors in the admin interface. Fixes https://github.com/owncloud/core/issues/17901
-
- Jun 25, 2015
-
-
Morris Jobke authored
-
- May 26, 2015
-
-
Lukas Reschke authored
Without /dev/urandom being available to read the medium RNG will rely only on the following components on a Linux system: 1. MicroTime: microtime() . memory_get_usage() as seed and then a garbage collected microtime for loop 2. MTRand: chr((mt_rand() ^ mt_rand()) % 256) 3. Rand: chr((rand() ^ rand()) % 256) 4. UniqId: Plain uniqid() An adversary with the possibility to predict the seed used by the PHP process may thus be able to predict future tokens which is an unwanted behaviour. One should note that this behaviour is documented in our documentation to ensure that users get aware of this even without reading our documentation this will add a post setup check to the administrative interface. Thanks to David Black from d1b.org for bringing this again to our attention.
-
- Apr 07, 2015
-
-
Joas Schilling authored
-