Opened 4 years ago
Closed 4 years ago
#16160 closed bug (no change required)
Shell commands - critical data option
Reported by: | lelldorin | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | - General | Version: | R1/Development |
Keywords: | Private data, critical data | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
After many discussions about my besly system analysis tool i thinking about to reactivate it. But the Problem is the same, we need to remove or grey out critical data.
Is there the possability to make option into the system scripts to output informations without critical data?
Things like: Ip address Wan address Mac address Password ...
I think this will close the Problem of private data in reports here in the bug tracker too.
Change History (5)
comment:1 by , 4 years ago
Description: | modified (diff) |
---|
comment:2 by , 4 years ago
comment:3 by , 4 years ago
Ok this is a useful Info, only smal changes needed. And removing other Infos from the old entry.
Is there critical Infos included usind listdev and listusb?
My tool can help end-user to get infos for the bug tracker too, so i need to see syslog included informations.
Thanks
comment:4 by , 4 years ago
listdev and listusb just list the hardware in the computer: vendor ID and device ID of USB and PCI devices. This I don't think is personal data.
The syslog is the main problem here because any application can write anything to it (using the syslog() function), crashing applications will be listed, IP address will be listed by the DHCP client, etc. It is hard to know what exactly is in there.
comment:5 by , 4 years ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
Just don't call the commands which list these. If you stick with listdev and listusb that's all the info we need in a system analysis tool.
syslogs are sometimes useful in a bugtracker when trying to pinpoint the exact cause of a problem and fixing it. But that usually takes several runs of adding extra tracing to the driver, asking the bug reporter to try again and get more info, until the problem can be identified and solved.
In the case of a hardware database, all we need is the list of hardware, and the user should report if it works or not, because you can't know this from the syslog in most cases.