Frank Ch. Eigler wrote on Tue, May 25, 2021 at 02:57:54PM -0400: > > [...] Most of these libraries are nothing I care about. [...] but > > could it be possible to not download anything at this point and only > > download debuginfos when they are really used [...] > > This sounds like a worthwhile suggestion for upstream gdb. We will > follow up with them. Thanks! > > [...] - None of ^C, ^\, ^Z work, when I grew tired of waiting I had > > to switch to another terminal and kill the gdb process. [...] > > OK, in my experiments, ^C did work, so something must have broken here. > We will follow up with gdb folks. I just tried on fedora34, this works here so that must be related to the version used on debian, thanks for pointing out it works. (For others: ^c cancels the download of a single object file, so might need quite a few of these to eventually get to a gdb prompt if there are many objects to download, but it works) > By the way, consider operating your own debuginfod (rawhide or 0.185) > server, federating to upstream. The gdb-gui-download-series process you > experienced could be maybe twice as fast, due to http connection > keepalive improvements. Maybe even faster, once gdb itself takes direct > advantage (patches there are pending). Plus you get a shared cache for > your network. Interesting, I wasn'te aware of such a debuginfod proxifying mode. Are there noticeable advantages over a simple caching http proxy (e.g. squid) besides serving off in-house binaries debuginfo along the way? In my usecase this was a one-off thing for now, but I can see the point if using it a lot. > > [... re. security ...] (distributing just checksums of all debug files > > in the main package, so when debuginfod downloads something it can > > compare with the checksum that was installed and verified locally by > > signed rpm? > > That sounds like something that could fall out from this effort [1], when/if > comes to fruition. We in debuginfod land could naturally follow up with > interfacing & checking glue code. > > [1] https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents Hm, I guess debuginfod could distribute the signature files together with the dwarf files straight from the rpm, but I'm a bit pessimistic whether everyone will have IMA enabled even at relatively long term. The change proposal does state that they won't actually enforce anything: > Note explicitly that we do not intend to install a default policy as > part of this change, and users will need to deploy their own policy > before anything is measured or appraised. This means that after this is > done, users will have the option to enable a policy and have that be > enforced, but there will be nothing automatic. We will, however, > document various example policies people can adapt to their needs. Even when it does become standard many machines with developers will want to continue letting users compile their own code, and these are users likely to rely on debuggers/debuginfod to debug what they just wrote, so would they be protected? (I'm not familiar with how that works, now I'm reading up it looks possible to integrate with selinux to require appraisal by context, but there are still many many machines without selinux or equivalent in enforcing mode nowadays) I guess I'd be fine with that if the debuginfod client implements the signature verification in userspace regardless of the policy if configured for it (I almost wrote if the server sends it, but that'd let malicious server just pretend there is no signature available... heh), other distros will probably take a bit more time to deploy but I guess it will come together eventually. Anyway, thanks a bunch for following up, it's appreciated. -- Dominique _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
