Re: patch 2/2 debuginfod server etc.

[Mark Wielaard <mark@klomp.org>]

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