Re: [bug-buddy]: Custom scripts for your application

[Shaun McCance <shaunm gnome org>]

On Fri, 2006-12-01 at 17:58 +0000, Andrew Sobala wrote:
> Brian Cameron wrote:
> > Let's say some program generates a log file, and because this log file
> > is useful for debugging the maintainer specifies that the logfile should
> > be added to the bug report when it is created.  This sounds good, but
> > what if there is some way that sensitive or private data can get into
> > the log.  Then when the program crashes, this sensitive data gets put
> > in a public forum for all to see (if they know where to look).
> >   
> 
> #3  <signal handler called>
> #4  0x00000005 in ?? ()
> #5  0xb487cc71 in show_password_dialog (site=0x83ff2c0 "www.hotsexychicks.com", user=0x3777fef "bcameron")
> #6  .....
> 
> 
> Now, if it's not immediately obvious to anyone, *I just made that trace 
> up*. It is not real.
> 
> But the nature of a stack trace is that absolutely anything could be 
> leaked to bugzilla. This is why bug buddy makes it clear that you should 
> review the data sent for personal or private information. Adding data 
> from scripts to bug buddy has two ways it could go wrong - it can leak 
> data by accident, or it can be malicious. In the former case, I'd argue 
> for adding no more options because it's no more likely than leaking data 
> in the stack trace, and that's the reason that we ask the user to review 
> all data sent anyway.

I think most (non-hacker) users will look at a stack trace and not
even bother trying to figure out where their personal information
might be inside it.  Maybe adding a find dialog/bar would make them
a bit more likely to do so ("Does it say hotsexychicks.com in here
anywhere?"), but I doubt it would make much of a difference.

> PS. Just for reference, people *do* leak private data onto bugzilla 
> regardless.

Maybe we should find a way to make files submitted from Bug Buddy
private.  A trusted few would have access to them.  We'd have some
nice interface for reviewing submitted files, and the trusted few
could look through them for anything that looks, well, bad.  If a
file is clean, it gets marked public.  Otherwise, it is completely
deleted from the server.

--
Shaun