Bug 1009730 - 'Sensitive' information logic too dumb to be much use
Summary: 'Sensitive' information logic too dumb to be much use
Alias: None
Product: Fedora
Classification: Fedora
Component: libreport
Version: rawhide
Hardware: All
OS: All
Target Milestone: ---
Assignee: Jakub Filak
QA Contact: Fedora Extras Quality Assurance
: 896246 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2013-09-19 02:29 UTC by Adam Williamson
Modified: 2016-12-01 00:45 UTC (History)
11 users (show)

Fixed In Version: libreport-2.1.10-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-01-08 06:52:05 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2013-09-19 02:29:32 UTC
libreport's handling of 'sensitive' information in reports is a good idea, but the current implementation is kinda useless in practice.

There's a couple of major problems:

i) It has a fairly generous definition of 'possibly sensitive'
ii) It doesn't distinguish between different types of potentially-sensitive information at all

So in practice, almost every single report you ever submit has the 'possibly contains sensitive data!' stuff come up, which trains you in short order to ignore it, which means when you hit a report which *really does* have your password in plain text, you've been trained to click straight through and you go ahead and post it on Bugzilla. This has actually happened to real people, more than once.

Specific details on i): for instance, every single crash I've submitted in the last few months has had my username in the 'environ' data, and this is flagged as sensitive. libsecret.so is very frequently loaded, and the string 'secret' is flagged.

Either we need to get more strict about the flagging, and maybe 'whitelist' things that are _always_ there or just drop the username from the data (is it really any use to anyone?), or implement some kind of concept of 'sensitivity levels', or probably both. I can see it being a much better system if we don't submit your username in just about every report, and something that looks like a password sets off much more serious alarms than something that looks like a username.

Comment 1 Adam Williamson 2013-09-19 02:29:57 UTC
this may be gnome-abrt not libreport; please re-assign if so. I don't know where the 'sensitive data' stuff is handled.

Comment 2 Jiri Moskovcak 2013-09-19 21:15:11 UTC
So I've implemented the whitelist, so far I have this words:

login.so  #rhbz#896246

Do you have any other candidates for this list?

Comment 3 Adam Williamson 2013-09-19 23:10:21 UTC
As mentioned above, the 'environ' tab of the 'sensitive data' dialog always/almost always highlights the line:


amusingly, the line:


right before it is *not* highlighted. Outright *suppressing* that may be better than whitelisting it, though, I suppose.

Comment 4 Jiri Moskovcak 2013-09-20 06:13:14 UTC
Filtering the saved information will require more code changes, so for now I'm going to put it to the whitelist (and hope, that noone considers their username as sensitive information).

Comment 5 Adam Williamson 2013-09-20 06:54:08 UTC
well if you're going to take that approach you may as well just take 'username' out of the list of strings that trigger the 'sensitive info' path, rather than listing it in both the blacklist *and* the whitelist :)

Comment 6 Nicolas Mailhot 2013-09-20 08:15:59 UTC

Comment 7 Jiri Moskovcak 2013-09-23 08:30:46 UTC
commit 6fcea5a51c4a25d8d756dde6f15bee8aee11585e
Author: Jiri Moskovcak <jmoskovc@redhat.com>
Date:   Fri Sep 20 14:44:35 2013 +0200

    added whitelist for sensitive data - rhbz#1009730 rhbz#896246
    Signed-off-by: Jiri Moskovcak <jmoskovc@redhat.com>

Comment 8 Kamil Páral 2013-09-25 11:42:23 UTC
More lines to filter out:

... /lib64/libsystemd-login.so.0
... /lib64/libaccountsservice.so.0
... /usr/lib64/girepository-1.0/AccountsService-1.0.typelib

Comment 9 Jiri Moskovcak 2013-09-27 11:26:29 UTC
*** Bug 896246 has been marked as a duplicate of this bug. ***

Comment 10 Michael Catanzaro 2013-10-25 01:28:59 UTC
The other major usability issue is that although possibly sensitive text is highlighted, you usually have to horizontal scroll in order to see it, which is not practical in combination with the required vertical scrolling: you'd have to spend ages doing some sort of checkerboard pattern to inspect all the data and ensure you haven't missed anything highlighted.

Ideally there would be a quick way to jump between highlighted terms, but simply removing horizontal scrolling would help a ton.

Comment 11 Adam Williamson 2013-10-25 01:54:54 UTC
"Ideally there would be a quick way to jump between highlighted terms"

There actually is one - I forget the details, but there is a button somewhere in the window which simply jumps from highlighted term to highlighted term. I missed it for a while too, but once I found it it looked pretty obvious.

Comment 12 Jakub Filak 2013-10-25 07:34:46 UTC
(In reply to Adam Williamson from comment #11)
> "Ideally there would be a quick way to jump between highlighted terms"
> There actually is one - I forget the details, but there is a button
> somewhere in the window 

The hidden jump buttons are located on the right bottom corner of the window right after the search text entry.


Comment 13 Michael Catanzaro 2013-10-25 13:02:07 UTC
Oh that's good.  It really ought to be much clearer, though.

Comment 14 Adam Williamson 2013-12-04 01:20:37 UTC
'accountsservice' in various forms (it's a GNOME lib) is still a problem in current F20. and yeah, it'd be nice to make the 'jump to next sensitive item' arrows a LOT more obvious somehow.

Comment 15 Jakub Filak 2013-12-06 16:24:03 UTC
I've created a pull request [1] which adds 'accountsservice' to the sensitive white list.

1: https://github.com/abrt/libreport/pull/221

Comment 16 Jakub Filak 2013-12-11 11:00:35 UTC
Upstream commit ffcca2e498bfbf761c8398a82c15e2b4dd1a6043 fixes this bug.

Note You need to log in before you can comment on or make changes to this bug.