patch 2/2 debuginfod server etc.

[Mark Wielaard]

Hi,

On Mon, 2019-11-18 at 13:41 -0500, Frank Ch. Eigler wrote:
> > > 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.

But then every binary could be untrustworthy :)

> > 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.

The /usr/include/* thing is precisely why I think it is wrong to
provide those files. Those just happen to be the versions of the
include file installed on the machine the server is running on. They
might be completely different. Some debug files might have references
to (generated) files in /tmp. You wouldn't want to provide those, even
if they existed on the file system.

Yes, there might be source files outside the sources tree you provided,
but that doesn't mean you want to just hand them out.

In particular I believe that if we find source files under
/usr/src/debug then we should only provide those source files, not any
others on the file system.

> 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.

That would be helpful, but then -F should not be used by default. And I
don't think we should recommend people use it.

> > > 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?

Something between an hour and a day seems appropriate for that.

> > 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.

Thanks. OK, so this is mainly about purging indexed source files that
are never actually referenced.

> > > 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.

Thanks.
So we don't do any authentication right now even when using https?
Is that deliberate? What would it take to let it use the system certs
for authentication?

Cheers,

Mark