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