public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
* debuginfod Credential Helper RFC
@ 2022-07-26 22:50 Daniel Thornburgh
  2022-07-28 16:23 ` Mark Wielaard
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thornburgh @ 2022-07-26 22:50 UTC (permalink / raw)
  To: elfutils-devel

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 should be fairly
straightforward to implement and to generalize to new credential types.

Please take a look; it'd be good to have a consensus on how this should
work across interested debuginfod implementations before moving forward
towards implementation.

-- 
debuginfod Credential Helper RFCBackground

debuginfod is a simple HTTP-based protocol allowing clients to obtain debug
information from servers. The de-facto standard includes environment
variables for pointing clients at available debuginfod servers, but it
includes no mechanism to provide credentials.

This approach works well for fully open-source projects, but debuginfod is
also particuarly useful for the highly-stripped binaries and constrained
environments found in the embedded space. There, it’s common for licensing
constraints to require access to source and debug information to be
restricted to specific users.
Proposal

debuginfod clients could support a new DEBUGINFOD_CREDENTIAL_HELPER environment
variable. This would provide a command that a debuginfod client could run
to obtain credentials to supply to the server, much like Git or Docker
credential helpers do.

No modifications are proposed to generic debuginfod server implementations,
since specific authentication and authorization decisions are usually quite
domain-specific, and it’s fairly easy to write or configure a custom
debuginfod server to make them.

The proposal also omits any mechanism for the client to interactively
prompt the user for their credentials or to retrieve them from storage;
this is left to the credential helper.
Protocol

The behavior of the credential helpers broadly follows the example set by
Git and Docker.

The DEBUGINFOD_CREDENTIAL_HELPER environment variable contains a string
indicating the command to run. If the string begins with an absolute path,
the command is the verbatim string. Otherwise, the command is the string
prepended with debuginfod-credential-.

Once interpreted, the given command is executed in the shell with one
additional argument to indicate the operation type. This is always get.

The helper reads a description of the requested credential from stdin and
writes a description of the found credential to stdout. Errors may be
reported to stderr.
Credential Format

Credential requests and found credentials are both broadly described using
Git credential helpers’ input/output format
<https://git-scm.com/docs/git-credential#IOFMT>, with some modifications.

Only the http and https protocols are supported, since debuginfod only
operates over HTTP(S).

The url attribute is unsupported; URL components must instead be passed
separately.

An added bearer attribute can supply OAuth2 bearer tokens
<https://www.rfc-editor.org/rfc/rfc6750.html> in Base64
<https://datatracker.ietf.org/doc/html/rfc4648#section-4>. This attribute
is mutually exclusive with username and password.

Daniel Thornburgh | dthorn@google.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-07-26 22:50 debuginfod Credential Helper RFC Daniel Thornburgh
@ 2022-07-28 16:23 ` Mark Wielaard
  2022-07-28 17:47   ` Daniel Thornburgh
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Wielaard @ 2022-07-28 16:23 UTC (permalink / raw)
  To: Daniel Thornburgh, elfutils-devel

Hi Daniel,

On Tue, 2022-07-26 at 15:50 -0700, Daniel Thornburgh via Elfutils-devel 
wrote:
> 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 should be fairly
> straightforward to implement and to generalize to new credential types.
> 
> Please take a look; it'd be good to have a consensus on how this should
> work across interested debuginfod implementations before moving forward
> towards implementation.

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. We don't really know in what state
the program is and forking a big process is not cheap. The process
might be watching its own children (like when libdebuginfod is used in
a debugger or profiler) and suddenly get unexpected sigchilds or pids
from wait.

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? Or by simply defining the base DEBUGINFOD_URL with 
https://user:pass@debuginfod.example.com/ ?

Thanks,

Mark


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-07-28 16:23 ` Mark Wielaard
@ 2022-07-28 17:47   ` Daniel Thornburgh
  2022-07-29 18:58     ` Mark Wielaard
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thornburgh @ 2022-07-28 17:47 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: 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?

>

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-07-28 17:47   ` Daniel Thornburgh
@ 2022-07-29 18:58     ` Mark Wielaard
  2022-07-29 21:08       ` Daniel Thornburgh
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Wielaard @ 2022-07-29 18:58 UTC (permalink / raw)
  To: Daniel Thornburgh; +Cc: elfutils-devel

Hi,

On Thu, 2022-07-28 at 10:47 -0700, Daniel Thornburgh via Elfutils-devel 
wrote:
> > 
> > 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
> > 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.

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.

Would any of the above work for your use case?

Cheers,

Mark

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-07-29 18:58     ` Mark Wielaard
@ 2022-07-29 21:08       ` Daniel Thornburgh
  2022-08-02 20:36         ` Daniel Thornburgh
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thornburgh @ 2022-07-29 21:08 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: elfutils-devel

On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard <mark@klomp.org> 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
> > > 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.
>
> 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 | dthorn@google.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-07-29 21:08       ` Daniel Thornburgh
@ 2022-08-02 20:36         ` Daniel Thornburgh
  2022-08-04 17:02           ` Mark Wielaard
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thornburgh @ 2022-08-02 20:36 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: elfutils-devel

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 <dthorn@google.com> wrote:

> On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard <mark@klomp.org> 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
>> > > 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.
>>
>> 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 | dthorn@google.com
>
>

-- 

Daniel Thornburgh | dthorn@google.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-08-02 20:36         ` Daniel Thornburgh
@ 2022-08-04 17:02           ` Mark Wielaard
  2022-08-04 18:04             ` Daniel Thornburgh
  0 siblings, 1 reply; 10+ messages in thread
From: Mark Wielaard @ 2022-08-04 17:02 UTC (permalink / raw)
  To: Daniel Thornburgh; +Cc: elfutils-devel

Hi Daniel,

On Tue, 2022-08-02 at 13:36 -0700, Daniel Thornburgh via Elfutils-devel 
wrote:
> 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()?

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 alternative to setting any of the DEBUGINFOD_frob environment
variables you could put an urls, cache_path, progress, verbose
retry_limit, timeout, maxtime, maxsize or headers file under
XDG_CONFIG_HOME (~/.config) debuginfod_client that would be used if the
corresponding environment variable isn't set.

The downside of course is that it would cause more file stats when
creating a debuginfod_client handle, but the overhead is probably
minimal especially if programs just reuse the debuginfod_client
objects.

Or maybe it should just be one control file that can have entries for
all of the variables.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-08-04 17:02           ` Mark Wielaard
@ 2022-08-04 18:04             ` Daniel Thornburgh
  2022-08-08 20:41               ` Frank Ch. Eigler
  0 siblings, 1 reply; 10+ messages in thread
From: Daniel Thornburgh @ 2022-08-04 18:04 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: elfutils-devel

On Thu, Aug 4, 2022 at 10:02 AM Mark Wielaard <mark@klomp.org> 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 alternative to setting any of the DEBUGINFOD_frob environment
> variables you could put an urls, cache_path, progress, verbose
> retry_limit, timeout, maxtime, maxsize or headers file under
> XDG_CONFIG_HOME (~/.config) debuginfod_client that would be used if the
> corresponding environment variable isn't set.
>
> The downside of course is that it would cause more file stats when
> creating a debuginfod_client handle, but the overhead is probably
> minimal especially if programs just reuse the debuginfod_client
> objects.
>
> Or maybe it should just be one control file that can have entries for
> all of the variables.
>
Generalizing our use case, configuration files help when you're looking to
put permissions on part of the debuginfod configuration. Not sure if that
generalizes beyond supplying headers, but maybe in the future?

I could also see file-based config being useful if some aspect of the
debuginfod configuration can change from moment-to-moment. Environment
variables could be used for that, but it would require either changing
those variables in the calling shell or wrapping each debuginfod client
utility.

Or maybe just if the number of environment variables grows unwieldy.

For the permissions and mutable configuration cases, it would be desirable
to point debuginfod at different paths, so that these could be kept in e.g.
tmpfs. These might be machine generated, which also means there may be
multiple sources of such files. So, something like a
DEBUGINFOD_CONFIG_FILES list might work well there; each file could
contain, say, a list of environment_variable=value pairs, (or a more
debuginfod-specific format), and all the files in the list could be
concatenated together. Then, a service set up in bashrc could append or
prepend its moment-to-moment configuration runfile to the list of config
files.

You could also do this more granularly: DEBUGINFOD_HEADERS_FILES would work
for us, and other lists could be created for other dynamically controllable
aspects of the system. This wouldn't compose as well if you needed to do
hackery to say, remove a source of config from the list, though, as then
you'd have to find and remove n sources of config from n lists.
-- 

Daniel Thornburgh | dthorn@google.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-08-04 18:04             ` Daniel Thornburgh
@ 2022-08-08 20:41               ` Frank Ch. Eigler
  2022-08-09 18:13                 ` Daniel Thornburgh
  0 siblings, 1 reply; 10+ messages in thread
From: Frank Ch. Eigler @ 2022-08-08 20:41 UTC (permalink / raw)
  To: Daniel Thornburgh; +Cc: Mark Wielaard, elfutils-devel

Hi -

> [...]  I could also see file-based config being useful if some
> aspect of the debuginfod configuration can change from
> moment-to-moment. Environment variables could be used for that, but
> it would require either changing those variables in the calling
> shell or wrapping each debuginfod client utility.

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


> [...]  You could also do this more granularly:
> DEBUGINFOD_HEADERS_FILES would work for us, and other lists could be
> created for other dynamically controllable aspects of the system.
> [...]

I see some value in doing this sort of thing more broadly,
hypothetically, but it's vague/speculative enough that I'd be just as
glad to limit the concept to the present case ("also add all headers
in given file").  So how about a $DEBUGINFOD_HEADERS and perhaps
$DEBUGINFOD_HEADERS_FILE env vars for now?

- FChE


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: debuginfod Credential Helper RFC
  2022-08-08 20:41               ` Frank Ch. Eigler
@ 2022-08-09 18:13                 ` Daniel Thornburgh
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel Thornburgh @ 2022-08-09 18:13 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Mark Wielaard, elfutils-devel

On Mon, Aug 8, 2022 at 1:41 PM Frank Ch. Eigler <fche@redhat.com> 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 time.
>
Ah, that's a good point. To support dynamic updates you'd need to
completely reload config for each query, which is prohibitive, and you may
get inconsistencies in behavior. So that just leaves file permissioning as
a use case.

>
> > [...]  You could also do this more granularly:
> > DEBUGINFOD_HEADERS_FILES would work for us, and other lists could be
> > created for other dynamically controllable aspects of the system.
> > [...]
>
> I see some value in doing this sort of thing more broadly,
> hypothetically, but it's vague/speculative enough that I'd be just as
> glad to limit the concept to the present case ("also add all headers
> in given file").  So how about a $DEBUGINFOD_HEADERS and perhaps
> $DEBUGINFOD_HEADERS_FILE env vars for now?
>
Sounds good to me. If permissions are the only benefit to ..._FILE
environment variables, then headers are the only bit of config that it
makes sense to access control, so it makes sense as a special case.

-- 

Daniel Thornburgh | dthorn@google.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-08-09 18:13 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-26 22:50 debuginfod Credential Helper RFC 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
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

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