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
