Re: PATCH PR30962, debuginfod

[Mark Wielaard <mark@klomp.org>]

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