patch 2/2 debuginfod server etc.

[Frank Ch. Eigler]

Hi -

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


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


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


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

OK.


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

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.


- FChE