-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: generate system report doesn't remove all sensitive values #42530
Comments
For the record, we don't consider domains sensitive values and in fact the overwrite.cli.url, turn server and others are often helpful to indicate or the actual cause of bugs in apps or configurations. The serverinfo token and imaginary url however should be removed. On that note please follow our security policy next time for reports like this https://github.com/nextcloud/server/blob/master/SECURITY.md and report at https://hackerone.com/nextcloud |
Thank you for your comment, in case I would report it via security procedure in the future - I was under impression this is not really sensitive as the issue itself exists for long time already. Definitely domains, IPs and hostnames are less sensitive than passwords. But all kind of information should be treated the same. I don't see any good reason why dbhost, dbname, mail_smtphost and redis host are "sensitive" and trusted_domains and overwrite* are not.. From my experience in help.nextcloud.com forum people tend to mask this data - I think implementing this by default would be "expected". |
Well the bug reports we received where dbhost, dbname, mail_smtphost and redis host where the root cause are single digit. trusted_domains and overwrite.cli.url are quite regularly the root cause (multiple times per month) because people change their domain, misconfigure a proxy or other things. Also quite regularly sub-paths cause issues in apps and that is also helpfully visible with |
I'm sorry I have to disagree. Eeach piece of information removed from the config makes it harder to troubleshoot but current implementation when I think this topic definitely requires broader view. there is valid requirement to understand the config from the system report and at the same time users don't want to publish their system data in public places like forum and Github. maybe there some good way to anonymize the data without loosing connections of different settings e.g. replace only a part of the setting e.g. the domain part of the FQDN - replacing |
@nickvergessen I think there is one big difference. The bug reports you (the company) receive are not public. |
hopefully to be addressed with #45085 |
Bug description
when looking for support and admin is expected to run https://cloud.tld/settings/admin/support > [Generate system report]. This report lists different settings and installed apps. It also replace sensitive values like passwords with predefined string "REMOVED SENSITIVE VALUE".
In NC27 and NC28 (likely all versions) some sensitive value remain unchanged. This are:
Steps to reproduce
comand tool
occ config:list system
has the same flow.Expected behavior
please include the mentioned values into the replacement mechanism to avoid leak of sensitive data.
Installation method
Community Docker image
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
No response
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: