Re: New service: https://debuginfod.debian.net
On Wed, 2021-02-24 at 16:58 +0000, Ian Campbell wrote:
Ugh, sorry, the quoting seems to have gone quite wrong there, let me
try again...
> On Tue, 2021-02-23 at 22:53 -0500, Sergio Durigan Junior wrote:
> Hello there,
>
> I would like to announce a new service that I have just configured
> for
> Debian: https://debuginfod.debian.net.
>
> debuginfod is a new-ish project whose purpose is to serve
> ELF/DWARF/source-code information over HTTP. It is developed under
> the
> elfutils umbrella. You can find more information about it here:
>
> https://sourceware.org/elfutils/Debuginfod.html
Sounds interesting, thanks!
If you would like to use the service, and if the service supports the
Debian distribution you are using (see below), all you have to do is
make sure that the following environment variable is set in your shell:
DEBUGINFOD_URLS="https://debuginfod.debian.net";
Currently, the elfutils and GDB packages in unstable and testing have
native support for using debuginfod. I will soon propose a change to
the elfutils package in order to make it be configured with our
debuginfod instance by default, so that users will be able to use the
service transparently.
What are the security implications for users/clients of using this or
more importantly enabling it by default?
Presumably clients have to trust that the server is not going to feed
them malicious debug info. Are the tools which consume this information
written to operate on completely untrusted inputs? It seems like many
of them could have been written historically with the assumption that
their inputs are mostly to be trusted. I suppose the use https helps
mitigate this at least a bit when it comes to a debian.{org,net}
service.
What about information leakage? apart from debugids does this leak
anything else to the server? On a quick look it seems like it might
potentially leak source code paths (at least the leaf bits) to things
being debugged -- does this mean that if a user is debugging private
software (perhaps unpublished or perhaps proprietary software for
$work) on a Debian system they are at risk of leaking the source
filenames if they run gdb on one of their binaries while debugging?
This might be a problem if it comes to enabling this transparently.
Thanks,
Ian.
Reply to: