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: