Closed isdnfan closed 9 months ago
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".
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..
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 overwrite.cli.url
.
So no, I don't think we need to handle them all the same way.
I'm sorry I have to disagree. Eeach piece of information removed from the config makes it harder to troubleshoot but current implementation when trusted_proxies
is sensitive and trusted_domains
+ overwritehost
not sensitive makes no sense. the opposite is true.
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 cloud.nextcloud.com
with cloud.<HIDDEN>.com
keeps enough details for troubleshooting but improves privacy. same could be done for internal hostnames and IPs - replacing 3-5 characters of the string for every possible config e.g. redis host db host, imaginary URL.
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
overwrite.cli.url
.
@nickvergessen I think there is one big difference. The bug reports you (the company) receive are not public. The reports we (the forum) receive are publicly visible.
hopefully to be addressed with #45085
⚠️ This issue respects the following points: ⚠️
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