Whenever the server returns true for the can-assign Webdav property of
a system tag, it means the current user is allowed to assign,
regardless of the value of user-assignable.
This commit brings the proper logic to the web UI to make it possible
for users to assign when they have the permission.
**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.