patch 2/2 debuginfod server etc.

Mark Wielaard mark@klomp.org
Wed Nov 20 11:53:00 GMT 2019


On Tue, 2019-11-19 at 16:15 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> 
> > [...] What I want is simply make it easy for the user to say where
> > they expect the sources are. So there is no surprises.
> 
> If this were a mandate, it would be a hassle, for any build that's
> more than one directory wide.

It wouldn't be mandatory. It just wouldn't be the default.

> > > 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.
> 
> IMHO, even the former seems okay and even desirable:
> 
>     debuginfod -F /usr/lib/debug
> 
> is a safe & easy way to relay the contents of all the debuginfo rpms
> that were installed, to nearby clients.  All those binaries come from
> packages/distros, so are at least as high quality & trustworthiness as
> the user's own.  Again I offer to do an audit of some distro debuginfo
> that all their source refs are milquetoast like /usr/include or
> /usr/src/debug.

Sure, you could use that if you wanted to share your whole build/source
trees and don't mind serving any other files on some local network. I
just think it shouldn't be the default. If you go look for odd paths in
.debug files you probably will find them. We already know some builds
generate and/or build files in /tmp or outside the src/builddir.

I'll look to see what is necessary to make sure none of those leak out
by default.

> > > 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.
> 
> ca-certificates.crt types of files (or /usr/share/pki/ files) are the
> trust roots for validating the *servers'* certificates.  They are
> generally provided by the distro, so can't possibly serve as unique
> *client* authentication.

I think we are talking past each other here. I am not really interested
in "client certificates". I am simply interested in knowing what is
done for outgoing https connections to be authenticated. What would it
take to use the trust roots for validating the server certificates?

Thanks,

Mark



More information about the Elfutils-devel mailing list