Re: [PATCH 0/4] libdwfl: make dwfl_addrmodule work for Linux kernel modules

2019-12-18 Thread Mark Wielaard
On Thu, 2019-12-12 at 21:03 -0800, Omar Sandoval wrote: > Reading the kernel code, the main sections are indeed contiguous. So > this was entirely my bug. Sorry for the noise! > > On the bright side, patch 2 ("libdwfl: remove broken coalescing logic in > dwfl_report_segment") does seem like a legi

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

2019-12-18 Thread Mark Wielaard
Hi Frank, On Thu, 2019-12-12 at 12:18 -0500, Frank Ch. Eigler wrote: > > I like this idea but have a bit of a security concern about the ability > > to set it to any file. If someone manages to set it then they can > > overwrite anything a process using the library can write to. > > That's not t

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

2019-12-18 Thread Mark Wielaard
Hi Frank, On Fri, 2019-12-13 at 11:57 -0500, Frank Ch. Eigler wrote: > Pushed the following additional patch to fche/debuginfod-progress-env. > Hand-tested on a ginormous download with various length timeouts; hard > to test reliably within the elfutils testsuite (esp after removal of > that induc

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

2019-12-18 Thread Frank Ch. Eigler
Hi - > > That's not that serious a category of concern. Environment variables > > are not under control of untrusted agents. FWIW, $DEBUGINFOD_CACHE is > > considerably more dangerous in that regard (cache cleaning!). > > You have a way to make me even more scared of security issues than less >

Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var

2019-12-18 Thread Frank Ch. Eigler
Hi - > The code looks good in general, do note that if you rebase/squash to > onto master there is a slight conflict with the curl_res/curlm_res > fixlet. Since GCC10 isn't out yet, just yell if this gives you trouble > and I do/test it for you. I'll figure it out and merge. > [...] > I would a