Hi - >> > [...] 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. https://sourceware.org/bugzilla/show_bug.cgi?id=17547 >> OK, in my experiments, ^C did work, so something must have broken here. >> We will follow up with gdb folks. > > [...] > (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) https://sourceware.org/bugzilla/show_bug.cgi?id=27911 > [...] Interesting, I wasn't aware of such a debuginfod proxifying > mode. Yes, we refer to it as "federation", and designed into debuginfod from the beginning, so that one can establish a tree of servers, e.g. along personal/group/corporate/public sorts of lines. > Are there noticeable advantages over a simple caching http proxy > (e.g. squid) besides serving off in-house binaries debuginfo along the > way? [...] It should be about the same, except cache management policy is different, and that debuginfod will pass requests to its upstream peers *concurrently*, so this can create more redundancy and possibly performance. By design, squid proxies or CDNs should interoperate just fine with debuginfod and within federation trees. > [...] >> 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: Right, I'm referring only to that if the per-file signatures were built & packaged, we could trick the debuginfod client/server to use that for manual signature checking, vs. relying on selinux/kernel enforcement. > 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), (Good point!) - FChE _______________________________________________ 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
