Malte Poll

@flurie I took the liberty to submit a fix upstream with [rules_go](https://github.com/bazelbuild/rules_go/pull/4099). That will not immediately help you but should be the (slow and painful) way forward.

Disclaimer: not a maintainer - just another user. I think adding support for invoking a credential helper (similar to Bazel's `--credential_helper` flag) would be better, so that most header-based authentication...

I agree with a part of your request: the client should be allowed to specify multiple equivalent hashes (using different algorithms), and the server should be allowed to pick any...

> There is no central list of valid qualifiers, only some suggested ones. Clients could specify hashes with different qualifiers instead of multiple checksum.sri qualifiers. I agree. That is my...

> Is this not already the case, but with whitespace separation instead of commas? The [SRI spec](https://www.w3.org/TR/SRI/) linked from the qualifier lexicon allows for multiple qualifiers in one entry. Today...

> It also specifies that the user-agent in the case of multiple integrities provided, is to pick the one with the strongest hash, not just any. This is what the...

> Since there are other algos in the mix, I suggested that we add language to tie the two together (Request.DigestFunction -> Response.{Digest,DigestFunction}) distinct from any qualifiers, if a server...

> [Response already contains a Qualifier field](https://github.com/bazelbuild/remote-apis/blob/main/build/bazel/remote/asset/v1/remote_asset.proto#L232-L233) for population with the utilized checksum.sri. That's correct, but right now it's hard to reason about it in the case of `checksum.sri`: If...

I think it would be permissible by the current spec to introduce a new qualifier that is only used to convey validated checksums (`checksum.sri.validated`). Since it is new, we could...

Sorry! Was an automated close from the PR in another repo