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
* lostpassword.css is unneeded since #11696 is merged - 1b50d4f7ce
* js is already in core/js
* css is moved to core/css/lostpassword
* template is moved to core/templates/lostpassword
Integers, doubles, booleans and even arrays can now be set, with the
--type=... option. Array setting can be specified by passing multiple
name arguments, e.g. `./occ config:system:set redis port --value=123
--type=integer`
Fixes#21533
Before we just assumed that the passed path was a file. This does not
have to be the case. Thus check if it actually is a file before doing
any more tests.
We used to get the numeric value of the entrire md5 string which is a
128bit integer. We would then devide this by the maxval of a 128bit int.
There is no need for such huge computations. As we just require a value
between 0 and 255. Thus using two 16 bit values is more than enough to
get the precision we need. By just taking the MSB we get nearly
identical results.
Instead of prepending the token as username in the URL, use the
Authorization header instead. This is because IE9 considers this a
cross-domain call and refuses to do it in the first place.
When clicking on the unshare link (trash icon), the correct link element
needs to be used instead of whatever child was clicked. Then, that
element might contain a visible loading icon.
This fixes the spinner detection and also prevents a full page reload in
case the spinner was visible.
Whenever link share is not allowed, it was outputting a bogus sharing
field which name would conflict with the regular sharing field.
This fix makes sure that the bogus sharing field with "Resharing not
allowed" message only appears when triggered by removed share
permissions.
Old code first dit an ajax request to the avatar. Then a new image
object with the same src was created and since we do not cache avatars
yet :( this resulted in 2 sequential requests to the exact same URL
Now if you set the displayname it will first set the placeholder and
then load the avatar in the background. Only once this time!
This changeset allows ownCloud to run with pretty URLs, they will be used if mod_rewrite and mod_env are available. This means basically that the `index.php` in the URL is not shown to the user anymore.
Also the not deprecated functions to generate URLs have been modified to support this behaviour, old functions such as `filePath` will still behave as before for compatibility reasons.
Examples:
http://localhost/owncloud/index.php/s/AIDyKbxiRZWAAjP => http://localhost/owncloud/s/AIDyKbxiRZWAAjPhttp://localhost/owncloud/index.php/apps/files/ => http://localhost/owncloud/apps/files/
Due to the way our CSS and JS is structured the .htaccess uses some hacks for the final result but could be worse... And I was just annoyed by all that users crying for the removal of `index.php` ;-)
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.
In case the update server may deliver malicious content this would allow an adversary to inject arbitrary HTML into the response. So very bad stuff.
While signing the response would be better and something we can also do in the future (considering the code signing work), this is already a good first start.
Lukas Reschke
Morris Jobke
Jenkins for ownCloud
Vincent Petry
Joas Schilling
Thomas Müller
Robin McCorkell
Robin Appelman
Erik Pellikka
Christoph Wurst
Roeland Jago Douma
Jörn Friedrich Dreyer
Jan-Christoph Borchardt
Björn Schießle
Renaud Fortier
Victor Dubiniuk
Hendrik Leppelsack
Clark Tomlinson
