Provide a fuse-like share as an alternative to the retrace server.

[jfilak]

Bastien Nocera:

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

[https://lists.fedoraproject.org/pipermail/desktop/2014-August/010088.html]

[mtoman]

http://fedoraproject.org/wiki/Features/DebuginfoFS

[hadess]

This is important because the core dump should never leave the user's machine. There are plenty of details inside the core dump that wouldn't appear in a backtrace, such as identifiers, passwords, and other sensitive data.

As the server currently handles arbitrary data from the clients (the core dump) vulnerabilities could lead to unauthorised access and privilege escalations. It would also mean that we'd need a privacy policy for the server (which I don't believe it currently has).

[jfilak]

https://lists.fedoraproject.org/pipermail/security/2014-August/001969.html

[mtoman]

Unless the service providing the "Debuginfo filesystem" exists or is at least proof of concept, this is a theoretical solution. The DebuginfoFS project has been abandoned because of several reasons - missing features in GDB, storage issues (note that not only debuginfos, but all the binaries and libraries need to be there unpacked as well), security, scalability and probably more.

At the moment ABRT explicitely asks for confirmation to send coredump. If user does not want to send it, you do not need to. If Gnome does not want ABRT to be asking, they can completely disable remote retracing.

[hadess]

Asking the user doesn't make it more secure when they could end up losing passwords, identifiers or credit card information.

This is a potential liability for Fedora...

[mtoman]

While not sending the coredump anywhere is probably "more secure", it does not eliminate the security risk either. The sensitive information may be contained in the backtrace itself whether you generate it locally or remotely.

It is a liability for Fedora and it is user's decision whether he trusts Fedora enough to send a coredump or not. And I am repeating myself - if you do not want to give users the chance to make that decision, that is absolutely fine, it is a configuration detail.

[wgwoods]

@mtoman - there does exist a proof-of-concept. It was part of the original design of ABRT, actually.

Read http://fedoraproject.org/wiki/Features/DebuginfoFS. (Yes, that was five years ago.)

[mtoman]

@wgwoods I know, I have already been working on ABRT at that time. But I believe it was never working - has the WebDAV client ever been started? There are also non-trivial requirements on the server side - koji now holds around 10TB of packages and you would need almost all of them unpacked on the Debuginfo server. Another thing is that DebuginfoFS assumes that the correct libraries/binaries are installed on the system and it only needs to provide debuginfos, which is a false assumption (we have hit that in ABRT soooo many times).

[hadess]

Just like you install debuginfo packages on-demand when doing remote backtracing with gdb, you could do so with the debuginfo-fs. Not all packages have to be installed at the same time.

You could share the installed debug packages between sessions, keep the most used packages installed to speed up processing (say, keep glibc, glib2, gtk+ and Qt's debug packages installed at all times), or based on retrace results.

If the local libraries are missing, ABRT could also warn us, when it sees that the library is used in the stack trace that a newer version of the library is available, for example.

If the process is fast enough, the stack traces currently gathered at crash time by coredumpctl could be augmented without user confirmation when the problem occurs rather than when the user chooses to report it.

[mtoman]

I am sorry if it sounds that I am against DebuginfoFS. I am well aware of the advantages and actually I would love to integrate ABRT with such service. The fact however, is that the service does not exists and argumenting against Retrace Server will not make it magically appear.

So long story short - there is nothing to do on ABRT side right now. The service does not exist. We (ABRT) do not have resources to implement it on our own (at least at the moment). But as soon as somebody has it up and running, we will be happy to integrate.

We can keep this ticket open to track the issue.

[hadess]

Sure. I filed bug #834 about removing the remote retracing.

[sorki]

Here's another attempt to solve this using FUSE - https://clearlinux.org/features/all-debug-information-all-time

Probably worth exploring (disregard misinfo about Fedora).

[ernestask]

This might be easier to implement now with debuginfod (https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server/).