Hi Frank, On Tue, Nov 19, 2019 at 11:13:48AM -0500, Frank Ch. Eigler wrote: > > > > 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 :) > > If we have legitimate concerns about the correctness of toolchains > that the build the OS with, then we have much bigger problems than > leaking /usr/include header files. Would you like me to scan some > distro binaries for questionable source paths to ease your mind?
The problem isn't me believing toolchains can generate buggy debug data. The problem is that debug data generation is a complex process that involves a lot of moving part, some of which a user might not immediately realize. What I want is simply make it easy for the user to say where they expect the sources are. So there is no surprises. > > 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. > > The -F mode is suitable for sharing build trees. By definition, the > content is going to be up to the runtime whims of the system, because > even non-/usr/include files may change between one build and the next. > This is okay, it is just like running gdb on an older binary when the > source trees have changed. (We even propagate mtimes to the client, > so gdb can notice it the same way as if it were local.) -F mode does indeed seem suitable for sharing local build trees. If we add a big warning about it possibly sharing all local files. It doesn't seem suitable for sharing things like /usr/lib/debug and /usr/debug/src directories. When a user does that I don't expect to share anything other than the files under those directories. > > 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. > > (Note that we don't find/index source files for -F build trees at all. > We simply check outbound filesystem references from ELF/DWARF files > that we found/indexed.) People who wish to share their build trees > for debugging on a nearby machine should not be forced to install > their code to privileged directories like /usr/src/debug. I do agree with that. You should be able to share your build tree and even allow sharing sources outside the build tree. If you choose to. The issue I am concerned about is the other way around. If you don't choose to share your build tree and any other file on your system that might be referenced from it. > > > 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. > > The compiled-in default for the binary is off. The systemd service > default, it happens to be on, but it's configured to serve only > privileged directories that people with bad compilers cannot sneak > binaries into. People running personal servers can/should use -F as > they see fit. In the context of a normal workgroup - it's fine. So -F seems fine for the later, just not for the former. > > Is that deliberate? What would it take to let it use the system certs > > for authentication? > > System certs do not serve to authenticate clients. Client > certificates are per-user things that come with their own management > headaches. Will think about authentication matters in the future. I thought ca-certificates.crt were normally used to authenticate remote servers. Cheers, Mark
