On Fri, Oct 21, 2016 at 1:16 PM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote: >> Bugzilla is specifically not designed for keeping sensitive stuff > > Really? Every Bugzilla that I regularly work with (GNOME, WebKit, Red > Hat) has this feature. If you have a mailing list auto-CCed to a > component, well yeah that screws it up, but otherwise it seems to work > fine? > > Now, ABRT's heuristic for whether to make the bug private is really > terrible; you can imagine that any application that uses hash tables > will have "key" in the backtrace, and those all get set to private > unless the reporter decides to uncheck the box. So I never bother to > check what ABRT thinks is possibly-sensitive because it's *almost* > always wrong. Nor do I ever ask users for permission to set their bugs > public; the bug is usually never going to get fixed unless upstream can > see the backtrace, and there's almost never anything sensitive in the > backtrace. I do sanity-check the backtraces to check for obvious > sensitive data before setting them public. Nobody has complained yet. > > So I think the default is bad, but the functionality really is useful > to have if used more sparingly. Occasionally people will file a WebKit > bug and ooops there's a porn URL in the command line or the backtrace, > which can be embarrassing. Sometimes users don't care, sometimes they > do, and it's good to be able to mark those as private. Adam had another > example with passwords. Does it makes sense to have something sanitize URLs and paths that start with /home by default? Seems like a scalpel vs backhoe is needed. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
