Re: debuginfod Credential Helper RFC

[Daniel Thornburgh <dthorn@google.com>]

>
> 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
> https://user:pass@debuginfod.example.com/ ?
>
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 | dthorn@google.com