Change default security/privacy setting that is automatically set by apport
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apport (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: apport
The current behavior of apport is to set the default security / privacy setting of the resulting bug to "Private." I understand that this may be a direct result of bug #132800.
To illustrate the poblem here's what I bumped into this morning:
1. Experienced problem
2. Apport generated an auto-report
3. I decide to submit the report to help
4. I check to ensure this bug is not a duplicate, it isn't.
5. I send the report
6. I learn the bug is a duplicate, through email
7. I attempt to check the duplicate, but access is restricted
The bug I generated is #196460, the "private" bug is #196335. The issue here is not the original bug I reported. I know it will be fixed even if I cannot check on it's status.
These are the issues as I see them:
1. Users will not change the status of their bugs to public, for whatever reason, they will remain private.
2. Users will come in afterwards and create duplicate bugs, and then be unable to track the original bug.
3. Those that care about what is reported will use the security/privace setting appropriate to them, or strip the offending portions, or just not report.
This issue is relative to #132800
Best regards,
Harvey
Thank you for your report. However, crash reports can have more information in them which potentially have sensitive information, in particular in the Tracebacks (python) or core dumps (SIGSEGV, etc.). Bug 132800 has been fixed, but (1) bugs were filed privately since long before already, and (2) we cannot filter core dumps like we can filter ProcCmdline, etc.
While I acknowledge that the weirdness you reported exists, we won't file bugs as public by default for above reasons. Developers usually set high-profile crashes like this to public after inspecting that there is no sensitive data (this already happened for bug 196335).
Thanks,
Martin