Hi Frank, 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. > 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. 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 > 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? 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? Cheers, Mark
