patch 2/2 debuginfod server etc.
Thu Nov 21 16:37:00 GMT 2019
On Thu, 2019-11-21 at 10:57 -0500, Frank Ch. Eigler wrote:
> > 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.
Yes, that (and references to any other source files, whether those
scanned by -F or -R or simply because they are reachable on the file
system) is the problem that is being solved.
> 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.)
By default all -F directories are already whitelisted. -S is just for
extra places where source could be found.
> 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.
I guess we differ on how trustworthy generated debug files are.
But in my patch by default any files under PATH1 and PATH2 would not be
restricted by default (unless -N is given).
> 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
> 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?
What I would like is:
- By default only restrict the files served to those under the
directory that the file-scanner uses (that is why I split the
-R and -F cases).
- Have a more restrictive mode that simply doesn't add anything
to the sources white list (that is -N in my patch).
- Have an anything goes mode (that is -A in my patch).
- Be able to whitelist more selectively (that is -S).
If I understand you correctly (given your other email in reply to why
adding globbing support isn't enough), you also want a mode where all
extra arguments on the command line are interpreted as "scannable"
(either file based or rpm based).
So I think the real issue is the splitting of -R and -F argument
parsing. If that is the case, maybe just picking a default for how to
interpret the extra arguments, as dirs for the file scanner or dirs for
the rpm scanner or both, might make us both happy?
More information about the Elfutils-devel