dmalcolm wrote:
[...]
Something that occurred to me about this change is that as well as
sources and DWARF data, some of our debuginfo files contain python
scripts.
Because these files are stand-alone .py files rather than elf/dwarf
files, debuginfod has no way of serving those. If they were embedded
inside the DWARF file as a special section, then it could travel
implicitly.
[...]
Having the sources and DWARF on-demand via debuginfod sounds great, and
hopefully means never having to manually install debuginfo rpms again -
but what about those .py files?
If we were interested in serving them, we could do it by extending the
webapi protocol with a way to refer to a buildid-indexed
debuginfo-related file. Like
/buildid/BUILDID/debuginfo-gdb.py
[...] I'm much more nervous about arbitrary python scripts being
supplied over this service, as the barrier to entry for bad guys to do
Bad Things would be so much lower as compared to malformed DWARF [...]
Perhaps ... I'm not sure bad DWARF is inherently safer than bad Python.
Nevertheless, all this is based on the proposition that the files are
coming from a generally trusted build system, serving trusted artifacts
maintained by trusted individuals. If malevolent enough files get in
there, the service can be degraded and/or clients can be affected.
- FChE