Hi Frank, On Wed, 2023-10-11 at 10:22 -0400, Frank Ch. Eigler wrote: > > I think this makes sense, but it would be good to see an example of the > > paths this now exposes. > > e.g: > % debuginfod-find -v debuginfo /bin/ls > [...] > x-debuginfod-size: 502024 > x-debuginfod-archive: > /mnt/fedora_koji_prod/koji/packages/coreutils/9.3/4.fc39/x86_64/coreutils-debuginfo-9.3-4.fc39.x86_64.rpm > x-debuginfod-file: /usr/lib/debug/usr/bin/ls-9.3-4.fc39.x86_64.debug > [...]
Ah, right. Thanks. > > Does this include the temporary dir that a file is extracted in? > > No. > > > Does it really make sense to provide the full (absolute?) path of > > the archive a source file was found in? > > As much sense as omitting the entire path information and returning > only the basename. Sometimes the path may matter, if e.g. the archive > file names are duplicate. And it turns out the archive paths were > already usually sent in their entirety, and the archived-file paths > were basename'd. Kinda the wrong way around. Anyway it's simplest to > do neither bit of elision at the tool level. OK. But I think you should add an explanation or example to "Front-end proxies can also elide sensitive path name components" paragraph. So the user is fully aware what those "sensitive path names" are. Maybe even add that debuginfod-find -v example so people can double check. Thanks, Mark
