public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: Daniel Thornburgh <>
Subject: Re: debuginfod Credential Helper RFC
Date: Fri, 29 Jul 2022 20:58:05 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Thu, 2022-07-28 at 10:47 -0700, Daniel Thornburgh via Elfutils-devel 
> > 
> > I think this could work for a standalone program like debuginfod-find,
> > but not for a library like libdebuginfod. I would rather not have to
> > fork and exec from libdebuginfod.
> > 
> Could this functionality be made optional? Something a client could call to
> fork out to a credential helper, but with a notice on the tin? Or just a
> way to pass through credentials to libcurl, and libraries for
> parsing/producing the helper format?

I am not sure how useful an optional feature like this is.

> Can't this be handled through e.g. the underlying libcurl library by
> > setting a proxy environment variable so the requests goes through a
> > local proxy that is setup to do some kind of authentication
> > transparently?
> It would be at least somewhat undesirable for any process capable of making
> loopback requests to gain access equivalent to any user using debuginfod on
> that system. A credential helper would only have the ambient authority
> available to the user running the debuginfod client.
> That being said, I'm not opposed to this idea of an authenticating proxy,
> so long as there's a way of scoping access to it appropriately. I'm pretty
> far from a UNIX/Windows networking wizard, so if you know of a reasonable
> way to do this, please let me know.

I don't know how people "scope" this. But it feels a little paranoid to
restrict access to debuginfo and sources. So I wouldn't really mind
other users also having access.

You don't even need a real httpd proxy, you could even run a federating
local debuginfod server that knows how to do authorization requests.

> > Or by simply defining the base DEBUGINFOD_URL with
> > ?
> > 
> The specific use case we had in mind uses OAuth2 bearer tokens, not
> username/password pairs. This is increasingly common for the sorts of cloud
> hosting one might like to use for things like debug binaries.

A bearer token is really just an Authorization header key with a random
string as value. We already have:

/* Add an outgoing HTTP request  "Header: Value".  Copies string.  */
int debuginfod_add_http_header (debuginfod_client *client, const char*

So we could maybe have a DEBUGINFO_HEADERS environment variable that
then contains something like "Authorization: Bearer mF_9.B5f-4.1JqM"
Which would simply make sure debuginfod_add_http_header is called with
that value (or multiple if we can agree on a separator character).

That way you can run any program using libdebuginfod and get the
authorization for free by just running it something like:

export DEBUGINFO_HEADERS="$(credential-helper $DEBUGINFOD_URLS)"
gdb --args ./hack frob frob

Somewhat simplified, since it assumes you just have one DEBUGINFOD_URL
that needs the Authorization, but that seems fine, it seems an obscure
enough feature that it doesn't really matter if other servers get the
Authorization header too, they will just ignore it and don't even know
against what other server they could use the Bearer token.

Would any of the above work for your use case?



  reply	other threads:[~2022-07-29 18:58 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 [this message]
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
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 \ \ \ \ \

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