public inbox for
 help / color / mirror / Atom feed
From: Daniel Thornburgh <>
To: Mark Wielaard <>
Subject: Re: debuginfod Credential Helper RFC
Date: Thu, 4 Aug 2022 11:04:54 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Aug 4, 2022 at 10:02 AM Mark Wielaard <> 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

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

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 |

  reply	other threads:[~2022-08-04 18:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26 22:50 Daniel Thornburgh
2022-07-28 16:23 ` Mark Wielaard
2022-07-28 17:47   ` Daniel Thornburgh
2022-07-29 18:58     ` Mark Wielaard
2022-07-29 21:08       ` Daniel Thornburgh
2022-08-02 20:36         ` Daniel Thornburgh
2022-08-04 17:02           ` Mark Wielaard
2022-08-04 18:04             ` Daniel Thornburgh [this message]
2022-08-08 20:41               ` Frank Ch. Eigler
2022-08-09 18:13                 ` Daniel Thornburgh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).