Hi, I have added my answers below: On Mon Jul 13, 2026 at 6:06 PM BST, Abderrahim Kitouni wrote: > Hi Ed, > > please see my answers inline. > > Le lun. 13 juil. 2026 à 12:31, Ed Cope via dev > <[email protected]> a écrit : >> This follows the spec defined in >> https://github.com/EngFlow/credential-helper-spec/blob/main/spec.md >> >> This spec is used by existing tools such as bazel and buildbox: >> https://github.com/bazelbuild/proposals/blob/main/designs/2022-06-07-bazel-credential-helpers.md >> https://gitlab.com/BuildGrid/buildbox/buildbox/-/merge_requests/1115 >> >> To implement the spec, buildstream should provide: >> >> A bst flag --credential-helper <PATH> to specify the credential helper >> executable > > 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? >
This would apply to buildstream and buildstream plugins as well. The idea of these proposals is that buildstream and plugins would be able to use the same API to authenticate, which would make handling credentials for the user consistent without the need for re-implementating authentication for each plugin. When I made this issue / proposals, I was talking about handling credentials for buildstream sources: `tar` and `remote` and plugin sources. I had a quick look at buildbox-casd, and it seems like it can have multiple credential-helper arguments for different contexts. I'm not entirely sure in what context does each of the credential-helper arguments are used, but each of these entries could be under separate config entries. 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. Does the answer the question with more than one credential helper? >> BST user config entry auth.credential-helper = "<PATH>" >> API for plugins to use for retrieving credentials > > Yes, it makes sense to have an API for this. > >> For the credential helper, buildstream should: >> >> Timeout after 5 seconds of execution >> Provide the helper executable the same environment variables as bst >> Set the helper executable working directory to be the repository root > > How about buildbox-casd? > See previous reply. >> The API would be a utility function get_credentials(uri: str) -> dict[str, >> Any]: > > Why dict[str, Any] rather than dict[str, str]? Is there any usecase > where this shouldn't be a string? > I meant to type `dict[str, list[str]]`. This follows what is defined in the response schema's header: https://github.com/EngFlow/credential-helper-spec/blob/main/schemas/get-credentials-response.schema.json >> It is a new, isolated function rather than changes to >> DownloadableFileSource. > > I guess it's both :-) DownloadableFileSource should also be updated to > use the new API. > I would say DownloadableFileSource would be using the new API to authenticate. The new API would not be defined on the class itself is what I meant. >> The function will attempt authentication with a credential helper, and >> fallback to netrc. > > 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. >> This function would have to sometimes cache the result as specified in >> the get-credentials response schema: >> https://github.com/EngFlow/credential-helper-spec/blob/main/schemas/get-credentials-response.schema.json >> Cache would be stored in a global state > > I assume this would be just a dict in memory? > Yes. The dict would contain the `get` command argument as a key (which would be the URI), and the full `get` command response. >> Return value is a dictionary containing headers for making requests with. > > We should make sure to consider the interaction between this and > source mirror plugins. Currently the source mirror plugins have an > "extra_data" field they can set, and DownloadableFileSource (and other > plugins not deriving from it) recognize an "http-auth" extra data, > which when set to "bearer" causes them to use the netrc password as a > bearer token. > > We may need to have an `extra_data` dict be passed to the > `get_credentials()` method you're proposing to keep backwards > compatibility in this case. > 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? >> This change will not break existing projects using netrc for >> authentication. > > All in all, I think this is reasonable. We just need to make sure to > cover all corner cases. But I'd like to hear what others think. > > > Cheers, > > Abderrahim Regards, Ed
