-1 to the proposed solution. I think it adds more problems than it solves.
However, I agree with the premise that private apport crash reports could use some improvements.
1. Stripping of private data (core dumps) to make bug public. This has the problem that _sometimes_ you want to re-examine the core dump (such as if the retracer failed or you want to poke around more interactively via gdb.)
2. Setting bugs private when there is no actual private data present. Apport follows a "better safe than sorry" approach to keeping personal data private, but in practice this is needed in a very small fraction of the cases. But perhaps by sharpening our pencil we could make apport a bit smarter in differentiating when a bug report must be private? By simply making fewer bug reports private, this would more directly reduce the scope of the original problem stated in this bug report.
-1 to the proposed solution. I think it adds more problems than it solves.
However, I agree with the premise that private apport crash reports could use some improvements.
1. Stripping of private data (core dumps) to make bug public. This has the problem that _sometimes_ you want to re-examine the core dump (such as if the retracer failed or you want to poke around more interactively via gdb.)
2. Setting bugs private when there is no actual private data present. Apport follows a "better safe than sorry" approach to keeping personal data private, but in practice this is needed in a very small fraction of the cases. But perhaps by sharpening our pencil we could make apport a bit smarter in differentiating when a bug report must be private? By simply making fewer bug reports private, this would more directly reduce the scope of the original problem stated in this bug report.