This DEBUGINFOD_HEADERS_FILE environment variable names a file to supply
HTTP headers to outgoing requests. Notably, this allows for
Authorization headers to be added from a file under OS access control.
Signed-off-by: Daniel Thornburgh
---
NEWS| 3 +++
debuginfod/Ch
Hi elfutils-devel@,
I've been working on adding debuginfod support to various LLVM utilities,
while simultaneously setting up production use of debuginfod for a managed
developer environment.
One issue that keeps cropping up is that there's often quite a few places
to get debug files from locally
On Wed, May 31, 2023 at 3:35 PM Frank Ch. Eigler wrote:
> > [...]
> > It would be really nice if there were, a DEBUGINFOD_LOCAL_PATH
> environment
> > variable that provided a colon-separated list of directories in the GDB
> > `.build-id//` [...]
>
> Please note that $DEBUGINFOD_URLS can already
Hmm, how would the effective behavior of this differ from directly
returning the path? The symlink could become invalid at any time, and it
would become invalid in precisely the same scenarios that the original file
would. A further request would in both cases stat the original file, and if
it were
SGTM; I'll see if I can write a patch to do this when I get some spare
cycles.
On Thu, Jun 1, 2023 at 2:21 PM Frank Ch. Eigler wrote:
> Hi -
>
> > Hmm, how would the effective behavior of this differ from directly
> > returning the path? The symlink could become invalid at any time [...]
>
> Eff
Hello elfutils-devel@
I'm working on a use case for debuginfod (in LLVM) that needs a solution
for authentication and authorization of users when accessing source and
debug information. I've put together a short RFC for how this might work,
based on how git and Docker CLIs handle credentials. It s
>
> 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 wi
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
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=. This
would avoid storing credentials
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
On Mon, Aug 8, 2022 at 1:41 PM Frank Ch. Eigler wrote:
> So-so ... if the file contents are modified, but the environment
> variable that points to the file is fixed, then one may get into parse
> race conditions as different debuginfod client objects in the process
> may be active at the same ti
11 matches
Mail list logo
