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
