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
- 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
> 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
> I don't understand how one would switch between those 2 modes,
In the ABRT Preferences window. See:
> 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:
> > > 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
More information about the desktop