ABRT?

[Bastien Nocera]

----- Original Message -----
> Dear Bastien,
> 
> Thank you for the quick response!
> 
> 
> On Mon, 2014-08-11 at 05:20 -0400, Bastien Nocera wrote:
> > Hello Jakub,
> > 
> > ----- Original Message -----
> > > Hello,
> > > 
> > > I am working on a new version of ABRT which should have Bugzilla disabled
> > > in GNOME by default. So, it won't be necessary to remove any package,
> > > everything will be done on ABRT side. Unfortunately, I cannot release
> > > the updated packages until we upgrade the Fedora's ABRT server. And I
> > > would
> > > rather hear some feedback before I push those changes to upstream.
> > > 
> > > See: https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
> > 
> > Could you please explain what the differences are in the workflow?
> 
> My intention was to describe the new workflow on the page I sent in the
> first email:
> 
> https://github.com/abrt/abrt/wiki/GUI-Shortened-Reporting
> 
> Can you see the differences between "Shortened Reporting ON" (the new
> workflow) and "Shortened Reporting OFF" (the old workflow)?

I can see the difference, but I don't understand why I can't comment again after
the first time I've commented. The process to skip commenting the first time is
also sub-par. Given that the window is only there to show progress, maybe it
doesn't need to be there at all, and progress can be shown in the main window.

Are you after a UI review after that?

> > One of the
> > problems of having to input comments before the report is done is still
> > there,
> > and users still need to wait in front of the dialogue when reporting bugs
> > against the ABRT server.
> 
> If you click "Report" in the notification bubble, no input is required
> and the reporting finishes immediately.

Why is the work-flow different in this case? Why would the user want *not*
to report the bug? Either do it automatically, or simply cache it all so that
they can be reported by hand later, in the UI.

> If you click "Report" in the GUI, the reporting window allows you to
> provide a description, informs you about processing and tells you that
> the reporting is done. The workflow is almost the same as the workflow
> for New Report in Normal mode at:
> https://wiki.gnome.org/Design/Apps/Oops

I don't see any windows besides the main window in those mockups. The
"add comment" variant is only there for developers.

> I guess the problem is that the reporting window isn't closed right
> after the click on "Send" button. I will try to fix it.

You could start reporting the backtrace straight away when clicking report,
and appending a comment after that if the user deemed it necessary to do so.

> > I also note that the core dump uploading, which gdb engineers advised
> > against,
> 
> Pardon? I am not sure I understand you. Where gdb engineers advised such
> a thing?

The gdb engineers, as well as security engineers, I talked to thought it
was a bad thing for the core dump to even travel to a remote machine. The
remote gdb could be vulnerable to a carefully crafted core dump, potentially
gaining access to the server, and also other user's core dumps.

Even if the core dump generation using gdb on the remote server is secure,
other services that it offers could be compromised and attackers could
harvest passwords and other data from the core dumps.

> > is still there for all the reports sent to the ABRT server.
> 
> No, the new workflow doesn't upload the core dump. If ABRT uploads the
> core dump, it is a bug or you don't have Shortened Reporting ON:
> 
> https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting

Right, but that's still available when doing "shortened reporting off", no?
I don't understand how one would switch between those 2 modes, or how they
might know the difference.

> >  I think that ABRT
> > should be able to setup a fuse-like share to gather the debuginfo from,
> > without
> > having to upload a potentially huge core file. That also means that the
> > process
> > of unpacking/preparing the packages for gdb can be started much earlier
> > (before
> > the core dump would have reached the server in the old case).
> 
> Please, excuse my ignorance, but what is fuse-like share? How should it
> work together with ABRT?

User-space filesystem. You'd have a remote server offering installed
debuginfo packages on-demand. They would appear as local files for the user's
machine, allowing gdb to provide better backtraces and no core dumps would
travel outside the user's machine.

> > Finally, I'd still prefer a way for the stack traces with mini-debug that
> > should
> > already be available on the system to be uploaded without interaction. Full
> > debug
> > traces could be sent out as additional information to those reports
> > (whether they
> > end up in Bugzilla or just on the ABRT server).
> 
> Yes, if you use the notification bubbles for reporting, then ABRT works
> as you describe. You can also enable the Auto-reporting to get rid of
> necessity to click "Report" button in the notification bubble:
> 
> https://github.com/abrt/abrt/wiki/Configuration#autoreporting
> 
> The new workflow disables Bugzilla (and all the tings before opening a
> new Bugzilla bug) when Shortened Reporting is ON for the reporting
> process started from the GUI.

This should probably be integrated in the Privacy Settings of the desktop instead
of being in the bug reporting application's preferences.

Cheers