Show a link to the docs instead of a button on the untrusted domain page
Before there was a button to "quickly" add the untrusted domain to the config. This button often didn't worked, because the generated URL was often untrusted as well. Thus removing it and providing proper docs seems to be the better approach to handle this rare case.
Also the log should not be spammed by messages for the untrusted domain accesses, because they are user related and not necessarily an administrative issue.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Implemented visual feedback if a user is disabled in admin user menu.
Implemented visuals for enabling/disabling user from admin user list.
Added the controller functions for enabling/disabling a user.
Added the route for changing user status (enabled/disabled) and added an additional route handler in the user controller.
Finished the visuals to reflect current user status and changed user status respectively.
Changed the single icon for enabling/disabling a user into a menu where deletion and state toggling of a user is selectable.
Added displaying of disabled user count.
Improved style of user action menu.
Added proper counting of disabled users.
Removed visual indicator for disabled users.
Moved pseudo-group detection for disabled users from frontend to the controller.
Changed units for newly introduced css values from em to px.
Removed unnecessary png and optimized svg with scour.
Changed the userlist template to display the user action menu with correct width.
Style fixes for better readability and coding style conformity.
Changed the icons for enabling, disabling and deleting a user in the action menu.
Persist personal settings federated sharing scopes
Show new settings fields in read-only mode too
Insert values on page load
Return updated values; show inline success feedback
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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 :wink:). 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.
Let users configure security headers in their Webserver
Doing this in the PHP code is not the right approach for multiple reasons:
1. A bug in the PHP code prevents them from being added to the response.
2. They are only added when something is served via PHP and not in other cases (that makes for example the newest IE UXSS which is not yet patched by Microsoft exploitable on ownCloud)
3. Some headers such as the Strict-Transport-Security might require custom modifications by administrators. This was not possible before and lead to buggy situations.
This pull request moves those headers out of the PHP code and adds a security check to the admin settings performed via JS.
add logSettingsController
add download logfile button
move getEntries to LogSettingsController
move set log level to logsettingscontroller.php
add warning if logfile is bigger than 100MB
add unit test for set log level
fix typecasting, add new line at EoF
show log and logfile download only if log_type is set to owncloud
add unit test for getFilenameForDownload
Mail address of users is now changable in the user management
* introduced new route settings/users/{id}/mailAddress
* kept old responses
* better error messages
* dropped lostpassword.php from settings/ajax
* cleaned up the UserList.add() and hand in user object instead of
each attribute as another parameter
* check for change permission of mail address
* proper response messages
First step of a somewhat testable user management. - I know, the JSON returns are in an ugly format but the JS expects it that way. So let's keep it that way until we have time to fix the JS in the future.
filter installed and not-installed apps properly
kill unneeded file
load category 'Installed' on page load
adding documentation links
new apps mgmt: first style adjustment
apps mgmt: only show license and preview if they exist
adding buttons
new apps mgmt: fix for mobile
use app icon if available
new apps mgmt: position enable/disable toggle to the right
new apps mgmt: proper display of icons or previews
new apps mgmt: fix loading spinner
reenable group selection for apps
new apps mgmt: position enable button normally again
new apps mgmt: clarify wording from 'Installed' to 'Enabled'
reintroduce enable/disable
Move rating image path generation to client-side
Move expression outside of l10n
fix group handling
add buttons for 'More apps' and 'Add your app' again
disable changed date of app for now
adding recommended label
style 'Recommended' app tag
fixing php warning
sort by rating
adding meta-category 'Recommended'
Only show existing documentation links
lacy loading of screenshots
making group based app activation work again
adding support to get the app icon not only by the app name but also simply by the fixed name 'app.svg'
adding app.svg for all core apps
query string '?installed' is not longer needed
update and uninstall is back + error feedback
remove unneeded parameter
fix alignment of 'recommended' label
Moved WebDAV and internet checks to client side JS
- Added setup checks in JavaScript
- Moved isWebDAVWorking to JS using SetupChecks
- Moved internet connection checks to an ajax call that goes through the
server
John Molakvoæ (skjnldsv)
Morris Jobke
Julius Härtl
Arthur Schiwon
Joas Schilling
Thomas Pulzer
Bjoern Schiessle
Roeland Jago Douma
Björn Schießle
Christoph Wurst
Lukas Reschke
Lukas Reschke
Thomas Müller
Robin Appelman
Roeland Jago Douma
Vincent Petry
Jenkins for ownCloud
Georg Ehrke
Clark Tomlinson
