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
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
