4

If I report a bug to launchpad using ubuntu-bug it usually adds a bunch of files about my system to the bug, it also adds a automatic generated bug summary to my bug report text. Both the summary and the attached files may potentially contain private imformation such as my user name, host name etc. I didn't find any option to edit the summary or the files. I just know how to delete the attachement.

So, how can I delete or change the private information in the summary and attached files?

Julia
  • 163

1 Answers1

2

I don't think there is any easy way of removing any private information from crash logs, but your files should be uploaded privately as it's well explained in Ubuntu Wiki at Triage:

Apport reports

A considerable number of bugs reported by Apport concern program crashes which are reported semi-automatically and get pre-processed automatically by bots in the Canonical data center. These bots try to generate a fully symbolic stack trace and check for duplicates.

In Feisty and early Gutsy, those bugs were public, so that everyone could see them. However, this created a privacy problem since core dumps and stack traces could potentially contain sensitive information. Also, crash reports generate a lot of bug mail noise. With the automatic duplicate checking, a fair amount of the reported bugs are completely irrelevant for triagers.

Since Gutsy, these problems have been mitigated: bugs are filed with the "private" flag enabled, i. e. only the reporter and subscribers can see it. The reprocessing bots will subscribe the ubuntu-bugcontrol team, but without sending bug email to the team members.

Thus crash bugs differ from other bugs in two important aspects: they need to be checked for sensitive data, and there will not be any initial bug mail for them until they become public. Triagers should check the following things:

  • If the crash still has a CoreDump.gz attachment, then it was not possible to automatically get a fully symbolic stack trace and check
    for duplicates. In this case, the bug will be tagged with apport-failed-retrace.

  • If the stack trace looks good enough, the CoreDump.gz attachment should be removed with the (edit) link in the attachment box. If the retrace failed completely, mark the bug as 'Invalid' and ask the reporter to refile the bug if the crash can be reproduced. Never mark a bug containing a Coredump.gz attachment as public. If there is no Stacktrace.txt (retraced) attachment, then the most probable reason is that the CoreDump.gz attachment is broken.
    Please check with Martin Pitt (pitti in IRC, martin.pitt@ubuntu.com)
    about the reason since he can look into log files.

  • Check if any of stacktrace attachments (original stacktraces, Stacktrace.txt (retraced) and ThreadStacktrace.txt (retraced)) have anything that looks like sensitive data passed as function arguments. Examples are passwords, things that look like bank account numbers, CSS keys, user names, server names, etc. If you don't find anything, you may mark the bug as public ("This report is public/private" in the top right of the bug report). This is not required though, it is fine to keep the bug private throughout its lifetime. Except for those privacy issues, crash reports should be handled like normal bugs in terms of duplicate searching/marking, upstream forwarding, etc.

If you don't want to send any private information, try to report the bug manually, without using ubuntu-bug tool.


More advanced method

Alternatively report the bug by logged in by different user or from the virtual machine.

Or scan the files before sending (if you know where they are) by cat/gzcat and strings, e.g.

find /var/log -name \*.gz -exec sh -c "gzcat '{}'|strings"  \;
find /var/log -name \*.log -exec sh -c "cat '{}'|strings"  \;

Where /var/log is the dir with compressed crash logs, use *.gz for compressed files, use *.log or whatever for non-compressed files. The command will print every string which is stored in these logs. You may also grep them for looking specific private data, if you know what you're looking for.

If you know which file it's, then just edit it or replace it by sed, e.g.

sed -i'.bak' s/private/XXXXXXX/g name_of_the_file.log

See also:

kenorb
  • 10,347