Description of problem: Abrt produces backtraces that can contain sensitive data such as passwords Abrt-gui should check them for sanity automatically (check for keywords such as variants on "password") and warn the user if it finds something that looks like sensitive data (highlight the result, focus on it, display if there are other suspicious matches, whatever) And *not* by adding yet another user-unfriendly popup Version-Release number of selected component (if applicable): abrt-gui-0.0.9-2.fc12.x86_64
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.
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.