我认为没有简单的方法可以从崩溃日志中删除任何私人信息，但是你的文件应该以私密方式上传，这在
Ubuntu Wiki at Triage中有很好的解释。
《Apport报告》
Apport报告的相当一部分错误是关于程序崩溃的，这些错误会被半自动地报告，并通过Canonical数据中心的机器人进行自动预处理。这些机器人试图生成完全符号化的堆栈跟踪并检查重复项。
在Feisty和早期的Gutsy版本中，这些错误是公开的，所以每个人都可以看到它们。然而，这造成了隐私问题，因为核心转储和堆栈跟踪可能包含敏感信息。此外，崩溃报告会产生大量的错误邮件噪音。通过自动检测重复项，报告的大部分错误对于处理人员来说是完全无关紧要的。
从Gutsy开始，这些问题已经得到缓解：错误会带有"private"标志，即只有报告者和订阅者能够看到。重新处理机器人将订阅ubuntu-bugcontrol团队，但不会向团队成员发送错误邮件。
因此，与其他错误不同，崩溃错误在两个重要方面存在差异：需要检查是否存在敏感数据，并且在成为公开之前不会有任何初始错误邮件。处理人员应该检查以下事项：
- 如果崩溃仍然附带有CoreDump.gz附件，则无法自动获取完全符号化的堆栈跟踪并检查重复项。在这种情况下，将使用apport-failed-retrace标记该错误。
- 如果堆栈跟踪看起来还不错，则应使用附件框中的（编辑）链接删除CoreDump.gz附件。如果重新跟踪完全失败，请将错误标记为"Invalid"并要求报告者在可重现崩溃的情况下重新提交错误报告。永远不要将包含Coredump.gz附件的错误标记为公开。如果没有Stacktrace.txt（重新跟踪），则最有可能的原因是CoreDump.gz附件损坏。请与Martin Pitt（IRC上的pitti，martin.pitt@ubuntu.com）核实原因，因为他可以查看日志文件。
- 检查任何堆栈跟踪附件（原始堆栈跟踪、Stacktrace.txt（重新跟踪）和ThreadStacktrace.txt（重新跟踪））是否存在看起来像敏感数据传递给函数参数的内容。例如密码、类似于银行账号的信息、CSS密钥、用户名、服务器名等。如果找不到任何内容，可以将错误标记为公开（在错误报告的右上角选择"此报告是公开/私有的"）。但这不是必需的，保持错误的私有状态也是可以的。除了隐私问题，崩溃报告在重复搜索/标记、上游转发等方面应该像普通错误一样处理。
如果您不想发送任何私人信息，请尝试手动报告错误，而不使用
ubuntu-bug工具。
更高级的方法
或者通过不同的用户登录或从虚拟机中报告错误。
或者在发送之前扫描文件（如果你知道它们的位置）使用`cat`/`gzcat`和`strings`命令，例如。
find /var/log -name \*.gz -exec sh -c "gzcat '{}'|strings" \;
find /var/log -name \*.log -exec sh -c "cat '{}'|strings" \;
/var/log是包含压缩崩溃日志的目录，使用*.gz表示压缩文件，使用*.log或其他格式表示非压缩文件。该命令将打印存储在这些日志中的每个字符串。如果你知道你要查找的特定私人数据，你也可以使用grep进行筛选。
如果你知道具体文件，可以使用sed进行编辑或替换，例如：
sed -i'.bak' s/private/XXXXXXX/g name_of_the_file.log
另请参阅：
