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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
