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

> 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?


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.

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


Daniel Thornburgh |

  reply	other threads:[~2022-07-28 17:47 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 [this message]
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
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).