**Before:**
> Your PHP version (5.4.16) is no longer supported by PHP. We encourage you to upgrade your PHP version to take advantage of performance and security updates provided by PHP.
**After:**
> You are currently running PHP 5.4.0. We encourage you to upgrade your PHP version to take advantage of performance and security updates provided by the PHP Group as soon as your distribution supports it.
Fixes https://github.com/owncloud/enterprise/issues/1170
The notification tests were not restoring the clock properly, but
indirectly helped other tests pass.
Since now we're restoring the clock properly, the other tests were fixed
to still work.
Permission text now doesn't appear when all permissions are there, or
shows as "invisible" or "not assignable", which should better cover all
use cases.
Changed select2 style to use boxes in the input field.
Does not disrupt the UX whenever a tag or association was created
concurrently. The input field will adjust itself as if the tag was
already there in the first place.
For admins: display the namespace behind the tag name.
For users: no namespace, don't display non-assignable tags in the
dropdown, display already assigned non-assignable tags with a different
style
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.
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:
![2015-11-04_12-02-57](https://cloud.githubusercontent.com/assets/878997/10936336/6adb1d14-82ec-11e5-8f06-9a74801c9abf.png)
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.
- Rely on class names instead of global ids
- When global ids are needed for label+checkbox, append the view id
(cid) to the element's id
This fixes the checkboxes when multiple sidebars exist in the DOM.
If the password is enforced we can't create a link share right away but
just show the password field. Untoggling the link sharing should not try
to remove the share.
* Added unit test
We used to display the response from the server. Which is in non ISO8601
format. Now this is weird since the datepickers shows us 'DD-MM-YYYY'
once a date is chosen.
Now use momentJS to properly format the date.
* Unit tests updated
The shares array is based on what the server returns and can contain
share info for parent folders.
hasUserShares is now fixed to ignore parent folders and only checks for
shares on the current item.
In some cases the ajax/share.php will return the share time as string.
If this is the case it would get parsed completely wrong and cause the
share dropdown to not work anymore. This change will properly cast the
string to an interger and also fallback if this is not possible.
This makes it possible to retrieve the icon for mimetypes in javascript.
It makes no additional queries to the server to retrieve the mimetype.
* config/mimetypealiases.json added
* mimetype.js: this is where the logic resides to convert from mimetype
to icon url
* mimetypelist.js: generated file with a list of mimetype mapping (aliases)
and the list of icon files
* ./occ maintenance:mimetypesjs : new command for occ to gernerate
mimetypes.js
* unit tests updated and still work
* javascript tests added
* theming support
* folder of the theme is now present in javascript (OC.theme.folder)
This aligns the recommended setting with the max-age of `15768000` as described in our documentation. Furthermore it fixes some logical problems with the code, unit tests has been added as well.
Fixes https://github.com/owncloud/core/issues/16673
* A list of recipients can now be properly formatted with remote shares.
Before the shares where simply shown in full in the "Shared with others"
section.
* Unit tests updated and added
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.
This did not happen correctly when the password was enforced since a
different code path was taken.
* moved generation of the default date string to separate function
* added unit test