From Fedora Project Wiki

DEBUGINFOD server

This server provides ELF or DWARF debugging information, plus associated source code, covering all packages and architectures of recent versions of Fedora. It works by periodically indexing all relevant RPMs from Koji, and extracting any needed file on the fly. Debugger-type tools automatically request files one by one. After being downloaded, each file is stored in a cache under your home directory, where the tools can immediately use it.

Configuration

On Fedora 32 or later, set an environment variable.

% export DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/

On Fedora 35 (rawhide) or later, this environment variable is automatically set via /etc/profile.d/debuginfod.* files.

If you operate your own debuginfod server for local projects, add its URL to $DEBUGINFOD_URLS (space-separated). If you'd like to see progress diagnostics during downloads, set:

% export DEBUGINFOD_PROGRESS=1

If you want to see exactly which network requests are being made and which cached files are used you can also set $DEBUGINFOD_VERBOSE (warning: very verbose):

% export DEBUGINFOD_VERBOSE=1

Then, enjoy using gdb, stap, perf, eu-stack, and many other debugging-related tools without the interruption of % sudo yum debuginfo-install XYZZY.

Disabling

If you wish to completely opt out of this service, clear $DEBUGINFOD_URLS. You can do this in your .bashrc file, depending on shell.

unset DEBUGINFOD_URLS

If you have a local debuginfod cache that you'd like to use, but don't want to attempt any upstream debuginfod queries, set $DEBUGINFOD_URLS to something non-empty but ineffective, such as /dev/null.

Clients automatically clean the cache of files not accessed in a while. You may also remove the debuginfod cache directory $HOME/.cache/debuginfod_client at any time.

Security

While we intend to operate the fedora debuginfod server in a secure manner, some concerns naturally arise.

Integrity

The fedora debuginfod server extracts files verbatim from koji-built RPMs, usually signed RPMs. However, since there exist no per-file signature facilities in effect, debuginfod cannot really assure the clients that the files are correct. (RPM signatures operate at the RPM package level, not at the file level.) Crafted or modified debuginfo files could in theory lead consumer tools to perform unintended or dangerous operations.

On the other hand, integrity in transit is protected by HTTPS (TLS). Integrity of the files at rest is improved by conservative file permissions to prevent accidental modification. We constantly monitor and update the server itself, so that we can reduce the risk of its exploitation.

Privacy

Whenever a debuginfod client tool needs information it cannot find locally, it sends an HTTPS request containing:

  • inherently, the client machine's IP address
  • the hexadecimal buildid of the binary it is interested in
  • if requesting a source file (usually if the debuginfo has already been found), then that source file's name
  • a User-Agent: string identifying its version of fedora and elfutils, and the architecture name

This could disclose the existence of debugging activity to the servers. It is stored temporarily in the general logs in fedora infrastructure. These logs are not made public.

Note that once debuginfo information is cached locally, or if installed debuginfo is found, no HTTPS requests are made at all.

See also

See Also

For more information see elfutils status page and Changes/DebuginfodByDefault.