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.
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.
If you wish to completely opt out of this service, clear $DEBUGINFOD_URLS. You can do this in your .bashrc file, depending on shell.
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.
While we intend to operate the fedora debuginfod server in a secure manner, some concerns naturally arise.
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.
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 would be stored temporarily in the general system-wide logs in fedora-infra, along with usual web server and other logs.
Note that once information is cached locally, or if installed debuginfo is found, no HTTPS requests are made at all.