On 10/21/2016 11:29 PM, Chris Murphy wrote: > 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. > Thank you for the tip. An optional automatic data sanitization before submitting crash details to a public bug tracker make sense to me [1] However, the feature must be optional. Dealing with bugs opened by ABRT is already complicated enough to discourage maintainers from reading those reports. Hence, I cannot imagine making ABRT Bugzilla bugs less informative by default. Regards, Jakub ABRT 1: https://github.com/abrt/libreport/issues/458 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
