16 Commits (847bbc51b61b4222503ae089f78124c2d18d5f22)

Author	SHA1	Message	Date
Carla Schroder	80a9a7d15f	correct typo in mimetypealiases.dist.json	10 years ago
Carla Schroder	7dbba520f0	correct occ command for mimetypealiases	10 years ago
Martin	998da2acd3	Adding mimetypes for m4a and m4b	11 years ago
Faruk Uzun	6ffd8f3e0d	Introduce some mimetypes for richdocuments ... * application/vnd.lotus-wordpro * application/vnd.visio * application/vnd.wordperfect * application/msonenote	11 years ago
Lukas Reschke	4db5638505	Add proper line ending	11 years ago
Lukas Reschke	a06b62f901	Use intermediate root authority ... Danimo proposed to use an intermediate root authority for signing purposes which makes sense considering that we may also sign updates this way in the future. So this uses now an intermediate authority.	11 years ago
Lukas Reschke	1d27a53338	Use newly generated certificate authority	11 years ago
Lukas Reschke	c0640f7998	Sync certificates with upstream	11 years ago
Lukas Reschke	4971015544	Add code integrity check ... 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.	11 years ago
Lukas Reschke	983dfebb5d	Update certificate bundle ... Syncs with ca-certificates version 2.5. - Removes expired TURKTRUST Certificate Services Provider Root 1 (https://bugzilla.mozilla.org/show_bug.cgi?id=1165992) - Removes obsolete TC TrustCenter certificates (https://bugzilla.mozilla.org/show_bug.cgi?id=1159070) - Removes ComSign Secured certificate as it is not used for websites (https://bugzilla.mozilla.org/show_bug.cgi?id=1160208) - Adds updated TURKTRUST certificates as the old ones are expired (https://hg.mozilla.org/integration/mozilla-inbound/rev/2f1a37cb43ac) - Add Certinomis as root certificate (https://bugzilla.mozilla.org/show_bug.cgi?id=1169083)	11 years ago
Roeland Jago Douma	57ceee13a9	Updated some mimetypes ... * c++ and cpp now both map to code	11 years ago
Robin McCorkell	cd7aff47e1	Introduce a few new mimetypes for code	11 years ago
Lukas Reschke	63b2bc136a	Move mimetype files into /resources/config/	11 years ago
Lukas Reschke	a8e8a9dfb9	Move certificate bundle into resources/config/	11 years ago