ABRT?

Jakub Filak jfilak at redhat.com
Mon Aug 11 17:13:05 UTC 2014


On Mon, 2014-08-11 at 08:31 -0400, Bastien Nocera wrote:
> 
> ----- 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.

I thought it would be a good idea to somehow indicate that the problem
is completely handled (reported & commented). There were complains about
"Report" button enabled for already reported problems. Should I make
"Comment" button always enabled?

>  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.

I am going to be completely honest with you: I want/need/have to reuse
the reporting window for several reporting work-flows because we have
one for Fedora (ABRT Server/Bugzilla), SELinux AVCs, Anaconda
(Bugzilla/Upload), RHEL and another distro in the near future.

> 
> Are you after a UI review after that?

You are the reviewer :) Thank you very much indeed!

> 
> > > 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?

Our vision is the following:

The notification bubbles:
  - fast and simple reporting for users who don't want to go through the
full reporting process but want to let maintainers know about crashing
applications

The GUI:
  - for advanced users, they know the purpose of "Automatic Bug
Reporting Tool", who wants to participate in the bug resolution process

>  Why would the user want *not*
> to report the bug? 

OK, I wasn't precise, the reporting finishes immediately after sending
an uReport.

> 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.

Although I would really love to make ABRT's workflow completely the
same, I cannot do it because I need to reuse the reporting window for
other work-flows (Fedora, SELinux, Anaconda, RHEL).

> 
> > 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.

Excellent idea, thank you! I'll give it a try.

> 
> > > 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.

ABRT warns users before uploading core dump and they can generate
backtrace locally if they have concerns about security.

> > > 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?

Yes, exactly. And GNOME user will do "Shortened reporting ON" by
default.

> I don't understand how one would switch between those 2 modes,

In the ABRT Preferences window. See:
https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting

>  or how they might know the difference.

It will be documented in the ABRT Preferences window, on the online
documentation and in man pages.

> 
> > >  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.

I understand and we can implement it in the next step. IMHO it would
required a broader discussion and some security expert should declare
that this is acceptable solution.

Anyway, it is a very good idea. Thank you!

I have filed an upstream ticket for it:
https://github.com/abrt/abrt/issues/832

> 
> > > 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.

Sure, what should I do to get this done?

I have attempted to develop a custom ABRT panel for control-center but I
failed:
https://mail.gnome.org/archives/gnomecc-list/2012-October/msg00017.html



Kind regards,
Jakub



More information about the desktop mailing list