patch 2/2 debuginfod server etc.

[Frank Ch. Eigler]

Hi -

> > I see where you're going with it, it's a reasonable concern.  For now,
> > we can consider it covered by the "debuginfod should be given
> > trustworthy binaries" general rule.
> 
> This does keep me slightly worried. Even "trustworthy binaries" could
> be produced by buggy compilers. 

Those would be untrustworthy binaries.

> I really think we should have some way to restrict which files on
> the file system can be served up. IMHO the default should be that no
> files outside directories explicit given to debuginfod should be
> allowed to be provided to the client. So it makes sense providing
> any extra source dirs, so you can check that any references to
> source files are actually correct/intended.

It's not so easy.  For build trees, source files can include
/usr/include/*, which do not contain executables and so don't need
indexing.  The use of symlinks in some configury/build systems makes
filtering after the fact difficult too - the realpath of object files
and source trees need not even be near, or in a single place.

Would you be satisfied if the -F / -R flags were restored, so that -F
would be required in order to start file-scanning threads (and similar
for -R)?  Then all this does not arise, because people who don't trust
their compilers wouldn't run debuginfod in -F mode.


> > I was thinkinng [300s] it's about right for a developer's live build tree.
> 
> OK, but those aren't included by default. 

A concern about the systemd service defaults can be addressed at the
systemd service / sysconfig level.  Would you prefer a day for that?



> > > So basically never, ever use [-G]? :)
> > > Can you add a hint when you should use it?
> > 
> > See also the DATA MANAGEMENT section. :-)
> 
> Which says:
> 
>    There is also an optional one-shot \fImaximal grooming\fP pass is
>    available.  It removes information debuginfo-unrelated data from the
>    RPM content index, but it is slow and temporarily requires up to
>    twice the database size as free space.  Worse: it may result in
>    missing source-code info if the RPM traversals were
>    interrupted.  Use it rarely to polish a complete index.
> 
> Which suggest to use it to polish by removing debuginfo-unrelated data.
> I am still not sure what that unrelated data is or when I really want
> to do this. It doesn't really list any quantifiable benefits.

OK, elaborating this point in the man page.


> > The text says that debuginfod does not provide https service at all,
> > so this is not relevant.  A front-end https reverse-proxy would have
> > to deal with this stuff.  I plan to cover this in a blog post later
> > on, and probably in the form of software baked into a container image.
> 
> But debuginfod might use HTTPS services itself for fallback. I think it
> is important to describe how/if those https ssl/tls connections are
> authenticated.

OK, will add a blurb.


- FChE