Re: patch 2/2 debuginfod server etc.

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

> It simply splits the paths into those scanned for rpms, those scanned
> for files and (optional) paths that are extra trusted prefixes for
> source files. The paths that are scanned for files are trusted source
> prefixes by default. There is a new option to also remove those using
> -N, --no-files-sources). And you can switch back to allowing all files
> on the file system with -A, --all-sources.

If the perceived problem is that build tree scans (-F) may contain
binaries that refer to source files that are not appropriate for
later sharing, then IMO this is too much change, and unnecessarily
complicates other valid usage.

If you are certain that source file censorship needs to be in the
code, I'd do it instead by adding just one option -S PATH to the code,
which would act like a whitelist for -F source file retrievals.
(There is no point to filtering -R rpm source files; those are only
serviced from other indexed RPMs.)

So:

    debuginfod -S /usr/src/debug -S /usr/include -F PATH1 PATH2 ... PATHn

would restrict -F source service to the given paths, and

    debuginfod -F PATH1 PATH2 

would not, because normal people have trustworthy build systems etc.

If you like, the above two -S paths can be made part of the default
for the debuginfod.service.  There is no need to compile-in a
restrictive default (such as making the non-S case mean "no source for
you!"), because there is no compiled-in default for any file paths to
search, so this issue just does not arise.

Would you like me to prototype this quickly?

- FChE