Re: debuginfod Credential Helper RFC

[Daniel Thornburgh <dthorn@google.com>]

On Thu, Aug 4, 2022 at 10:02 AM Mark Wielaard <mark@klomp.org> wrote:

> I wonder if we should generalize that for other DEBUGINFOD_envs. But
> instead of adding more environment variables have a debuginfod control
> file like we already have for cache_clean_interval, max_unused_age and
> cache_miss.
>
> So as an alternative to setting any of the DEBUGINFOD_frob environment
> variables you could put an urls, cache_path, progress, verbose
> retry_limit, timeout, maxtime, maxsize or headers file under
> XDG_CONFIG_HOME (~/.config) debuginfod_client that would be used if the
> corresponding environment variable isn't set.
>
> The downside of course is that it would cause more file stats when
> creating a debuginfod_client handle, but the overhead is probably
> minimal especially if programs just reuse the debuginfod_client
> objects.
>
> Or maybe it should just be one control file that can have entries for
> all of the variables.
>
Generalizing our use case, configuration files help when you're looking to
put permissions on part of the debuginfod configuration. Not sure if that
generalizes beyond supplying headers, but maybe in the future?

I could also see file-based config being useful if some aspect of the
debuginfod configuration can change from moment-to-moment. Environment
variables could be used for that, but it would require either changing
those variables in the calling shell or wrapping each debuginfod client
utility.

Or maybe just if the number of environment variables grows unwieldy.

For the permissions and mutable configuration cases, it would be desirable
to point debuginfod at different paths, so that these could be kept in e.g.
tmpfs. These might be machine generated, which also means there may be
multiple sources of such files. So, something like a
DEBUGINFOD_CONFIG_FILES list might work well there; each file could
contain, say, a list of environment_variable=value pairs, (or a more
debuginfod-specific format), and all the files in the list could be
concatenated together. Then, a service set up in bashrc could append or
prepend its moment-to-moment configuration runfile to the list of config
files.

You could also do this more granularly: DEBUGINFOD_HEADERS_FILES would work
for us, and other lists could be created for other dynamically controllable
aspects of the system. This wouldn't compose as well if you needed to do
hackery to say, remove a source of config from the list, though, as then
you'd have to find and remove n sources of config from n lists.
-- 

Daniel Thornburgh | dthorn@google.com