patch 2/2 debuginfod server etc.
Frank Ch. Eigler
Mon Nov 18 18:41:00 GMT 2019
> > 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
OK, will add a blurb.
More information about the Elfutils-devel