Hi,

Credential helper support seems sensible to me.

On Tue, 2026-07-14 at 16:57 +0100, Ed Cope via dev wrote:
> On Mon Jul 13, 2026 at 6:06 PM BST, Abderrahim Kitouni wrote:
> > How would this apply? Does it only apply to buildstream plugins? Does
> > it get passed to buildbox as well? This gives a question: how does
> > buildbox-casd use the credential helper? does it need to be passed on
> > the command line? or can it be passed in the
> > GetInstanceNameForRemotes?
> > 
> > I guess the question I'm asking is can there be more than one
> > credential helper? and if so, how do we configure them?

Bazel supports multiple credential helpers, a default one and domain-
specific ones [1]. I don't think we need to support domain-specific
credential helpers right from the start, however, it would be good to
structure the config in a way that it allows adding support for domain-
specific credential helpers in the future.

And it seems reasonable to at least consider configuration for
buildbox-casd credential helper support as well, which may need an
extension to GetInstanceNameForRemotes. This also doesn't need to be
implemented for the first iteration but we want to be able to implement
it in a follow-up.

> There seems to already be auth configuration that is passed into
> buildbox-casd in buildstream:
> https://docs.buildstream.build/2.7/using_config.html#cache-servers ,
> so the `servers.auth` could have extra keys for each of the
> credential-helper entries.

Adding a credential helper key to the server `auth` section in the user
config seems reasonable. I'm not sure whether it's acceptable to always
require this for use with cache servers, or whether there should be a
possibility to specify that globally (and/or use the default credential
helpers that is used for source fetching) without having to specify the
helper path for every server. It may not be possible to auto-detect
this.

> > In which cases would it fall back? Obviously it would if no credential
> > helper is configured, but what about other cases? (e.g. if it doesn't
> > return any credentials? returns an error? times out?)
> > 
> 
> I would say if there are no credentials returned or any failures
> happen, there should be a warning for the user and fallback.

As I understand it, returning no credentials should mean that no
credentials are required and should not trigger a fallback. Only an
error return should trigger a fallback. I'm not completely sure,
though. The spec says "When seeing unsupported input (e.g., an
unexpected protocol or domain of the provided URI), the Credential
Helper SHOULD return an error indicating the unsupported input instead
of returning an output.". And I think Bazel falls back only in case of
error.

> When I meant backwards compatibility, even if all netrc usage is
> replaced with `get_credentials()`, projects won't be affected with
> this change until the user uses credential-helper for credentials
> instead.
> 
> If I'm understanding this correctly, if `extra_data` received in
> `DownloadableFileSource` contains `http-auth: "bearer"`, it currently
> uses netrc for grabbing credentials.
> 
> So if `get_credentials()` is going to respect `extra_data` and force
> netrc usage with that flag, in what scenario would you want to force
> netrc for authentication, when the user asks buildstream to use
> credential-helper?

If a credential helper is configured, I think `http-auth: "bearer"` in
`extra_data` should use the credential helper, falling back to netrc
only if the credential helper returns an error.

Cheers,
Jürg

[1] 
https://bazel.build/reference/command-line-reference#common_options-flag--credential_helper

Reply via email to