Hi, On Thu, 2019-11-21 at 21:41 +0100, Mark Wielaard wrote: > I think what makes the discussion somewhat difficult is that there are > basically three cases: > > - Serving trees of rpms where only the contents of the rpms is shared. > - Serving of a build directory where it makes sense to share not just > what is in the build directory but basically everything that might > have been needed to create the artifacts in the build tree. > - Serving of specifically installed files. Which could be > exploded rpms of installed packages (e.g. the contents of > /usr/lib/debug and /usr/debug/src contents) or a specially prepared > installation of debugging artifacts to share with some developer > group. Where it makes sense to treat it like the first case and only > share what you specify.
Pondering some more it is this last scenario that really bothers me. But it might not be realistic to try to resolve this right now. We probably need a bit more feedback before introducing more arguments (which we then have to support forever). Lets see how people will try to use debuginfod in practice and fix things when a use case really doesn't work out. I think the solution for scenario three might actually be new tooling/packaging. The problem is that there are sources which currently don't make the (rpm) packaging, like /usr/include or generated files in /tmp. That makes the index incomplete and so we want to index also files outside what was packaged. But that is an information leak in a way. If we introduce a new debuginfo packaging format that includes everything that side channel might go away. I am a little concerned that we don't make a clear distinction between the paths/arguments used per scanner. I suspect we will introduce more scanners and it would be better if we could easily tell which paths are for which scanner. But given that the code is actually pretty clean I hope that when we do introduce more scanners we can fix up the command line parsing too. Or maybe none of the new scanners will have the issues that the -F has. I see you rebased and squashed most commits on the debuginfod-submit branch. Thanks. I'll pull them into master, but might tweak them a little to bring in fixes from the review-related commit into one of the others to make sure the test results keep clean and to prevent introducing and then backing out those big rpms from the first testcase. And there is one change I really want to make. The default settings of the debuginfod.service now include the /opt/ and /usr/local directories. I really don't think they should be because we don't know what the user has installed under that. Cheers, Mark
