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

So, I put together a design with this approach, and it passed a security
review, so the approach broadly seems to work for us.

It came up in review that it'd be considerably more usable to have the
environment variable point to a file: DEBUGINFOD_HEADERS_FILE=<file>. This
would avoid storing credentials in environment variables, and it would
allow you to set up the path to the header file in your shell config at the
beginning of a session.

Would this work for libdebuginfod? We'd also want to standardize on the
format of such a file; probably a newline-separated list of headers in the
format accepted by debuginfod_add_http_header()?

On Fri, Jul 29, 2022 at 2:08 PM Daniel Thornburgh <> wrote:

> On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard <> wrote:
>> 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.
> The only use I know of for a feature like this (which is our use case) is
> to allow debuginfod to work with closed source software. Even if most of
> the system is open source, there may be binary blobs where manufacturers
> may share source/debug info with developers under a restricted license that
> requires access control to the information.
>> > > 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*
>> header);
>> 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.
> Ah, I hadn't really looked much at libdebuginfod's interface yet, but
> that's very very interesting. Combining this with the idea above, you could
> write a nonce to a file only visible to the given user, then write an
> authorizing http proxy on localhost that would make sure the incoming http
> connection has the matching nonce. Then, the server could supply whatever
> credentials are necessary to any outbound servers it federates to. Then,
> you'd just need to pass the nonce in DEBUGINFOD_HEADERS and set
> DEBUGINFOD_URLS to the local server.
> I'll spend some time trying to prototype this and see if it works out like
> I think it would. It would be more work for integrators, but that's
> generally what I think you'd want for something that's arguably a pretty
> niche feature as far as things go, and a good reference implementation
> could also be built that supports credential helpers and could be extended
> with whatever access mechanisms you like.
>> Would any of the above work for your use case?
>> Cheers,
>> Mark
> --
> Daniel Thornburgh |


Daniel Thornburgh |

  reply	other threads:[~2022-08-02 20:36 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 [this message]
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).