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