Bug 525858

dup 525855 says:

Abrt produces backtraces that can contain sensitive data such as passwords
People are supposed to check they're safe before pushing them bugzilla side

However those traces are not decorated and presented in plain text, making them
hard to read (it's easier to post-check them in gnome bugzilla, where they
*are* decorated with useful colors, but by that's time it's to late for
sensitive data)

Please use the usual decorator libs to make the stacks pretty in abrt-gui

*** Bug 525855 has been marked as a duplicate of this bug. ***

The two bugs are not about the same thing:
- bug #525855 is about using one of the standard code prettyfiers to pretty-print stack traces in the abrt gui (prettyfy the trace structure and make it easy to read)
- this bug is about highlighting specific "dangerous" keywords such as password fields, that do not make sense in a standard code prettyfier but that abrt-gui can not ignore (make it easy to detect sensitive info)

*** Bug 525854 has been marked as a duplicate of this bug. ***

*** Bug 525853 has been marked as a duplicate of this bug. ***

*** Bug 525852 has been marked as a duplicate of this bug. ***

Dupes:

525854 "No usable way to display traces" - asks for bigger (maximizable) report window,

525853 "No obvious way to search traces" - asks for text search facility in backtrace, to search for "password" etc.

525852 "No obvious way to edit traces" - wants to edit backtrace in order to remove sensitive data.

Reading this bug and it dupes, I infer that users are supposed to search the backtrace to see whether it contains any passwords (this is far from obvious from within the abrt gui).  However, the popup asks permission to send a core dump, and the core dump contains all program memory, not just the stack.  I am experiencing a crash in gkrellm's mail check routines and am reluctant to have a core dump which is guaranteed to contain my email password posted to the public server.  Do these files become publicly downloadable?  If so, I bet there will be dozens of passwords sitting around just waiting to be downloaded by whoever does that sort of thing.

It would be nice to offer a search-and-replace feature that would allow me to type my password and then have all instances of it replaced with XXXXX or something.  Better yet, it would be nice if the core file could be encrypted with the developer's GPG key.

Also, I had said yes to sending the backtrace and no to sending the core dump.  It seems that abrt then submitted neither to bugzilla and the bug report was deemed useless.

(In reply to comment #8)
> Reading this bug and it dupes, I infer that users are supposed to search the
> backtrace to see whether it contains any passwords (this is far from obvious
> from within the abrt gui).  However, the popup asks permission to send a core
> dump, and the core dump contains all program memory, not just the stack.  I am
> experiencing a crash in gkrellm's mail check routines and am reluctant to have
> a core dump which is guaranteed to contain my email password posted to the
> public server.  Do these files become publicly downloadable?  If so, I bet
> there will be dozens of passwords sitting around just waiting to be downloaded
> by whoever does that sort of thing.
> 

Coredump is not send in BZ even if user press 'yes' this work only with the filetransfer plugin.

> It would be nice to offer a search-and-replace feature that would allow me to
> type my password and then have all instances of it replaced with XXXXX or
> something.  

Good idea, will look into it.

> Better yet, it would be nice if the core file could be encrypted
> with the developer's GPG key.
> 

Also good idea, but there is no information in the package about maintainer's gpg key and even if you had the key, you would had to trust the maintainer.

> Also, I had said yes to sending the backtrace and no to sending the core dump. 
> It seems that abrt then submitted neither to bugzilla and the bug report was
> deemed useless.  

This sounds like a bug, will try to reproduce this.

Thank you,
Jirka

(In reply to comment #9)
> Coredump is not send in BZ even if user press 'yes' this work only with the
> filetransfer plugin.

Ok, that is a relief then.  If it is just the trace, I don't mind having to manually look it over for personal information, although it would be nice to spell this out before the permission-to-send box is shown ("look over the information below to make sure it doesn't contain any sensitive information") and maybe allow it to be edited.  And if the core dumps are not sent the dialog box should not ask for permission to send them...

> > Better yet, it would be nice if the core file could be encrypted
> > with the developer's GPG key.
> 
> Also good idea, but there is no information in the package about maintainer's
> gpg key and even if you had the key, you would had to trust the maintainer.

I was suggesting this under the belief that the core dumps were publicly downloadable.  If the cores are not sent at all, that's even better.

> Thank you,
> Jirka  

Thanks,
Dan

Look like "reasonably improved" in new GUI? Ok to close this bug?

I find it VERY time-consuming to manually scroll and read through pages of traceback looking for one or two instances of my username and/or password.  A search-and-replace feature would make this MUCH faster, since I know the few phrases that I am interested in protecting.  I think this should remain open until you have a search-and-replace feature to ease the scrubbing of a traceback.

(In reply to comment #11)
> Look like "reasonably improved" in new GUI? Ok to close this bug?

what about cmdline field? it also can contain sensitive data

for example, 
I typed $ gftp some_site.org
got a crash

and now cmdline contains name of site, which I don't want to post in bugzilla

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I believe this bug is fixed in git. It's possible to edit any field and ABRT also automatically highlights sensitive words stored either in /etc/libreport/forbidden_words.conf and ~HOME/.abrt/settings/forbidden_words.conf


- the predefined list can be found here:http://git.fedorahosted.org/git/?p=libreport.git;a=blob;f=src/gui-wizard-gtk/forbidden_words.conf;h=effa4458e5cd96feede6831b7d5182ecc258c1a6;hb=HEAD

- if you think some words should be added to that list please don't hesitate and send an email to crash-catcher

commit 9db54c707ebca2b98d465b2358b1bd9228c73550
Author: Jiri Moskovcak <jmoskovc>
Date:   Fri Jan 13 13:23:49 2012 +0100

    wizard: automatically highlight known sensitive words rhbz#525858 trac#441

abrt-2.0.9-1.fc17, libreport-2.0.10-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.9-1.fc17,libreport-2.0.10-1.fc17

Package abrt-2.0.9-1.fc17, libreport-2.0.10-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.9-1.fc17 libreport-2.0.10-1.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4804/abrt-2.0.9-1.fc17,libreport-2.0.10-1.fc17
then log in and leave karma (feedback).

abrt-2.0.10-1.fc17,libreport-2.0.10-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.10-1.fc17,libreport-2.0.10-2.fc17

abrt-2.0.10-1.fc17, libreport-2.0.10-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.