patch 2/2 debuginfod server etc.

[Mark Wielaard]

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