http.bzl should support authentication and not limit itself to "simple" when it does

[oakad]

Even when dealing with internal services it is unreasonable to assume that all build dependencies are "publicly" available. Moreover, the content of the packaged build dependencies, may, in general, be dependent on the authentication details passed to the remote server.

Tools like Maven and Gradle had support for providing a local set of credentials for use with http services for dependency download from the early on. Bazel should have one too (especially considering that it is not difficult to do with Java).

[aiuto]

This needs some design before simply adding. It feels to me like

• different repositories might require different credentials. You might go to a corporate one for some things and the public internet for the others.
• I am sure some shops store credentials in user & system keychains. Pulling those out is a nasty problem. We may not want to do that, but would have to write documentation around the issue.
• Once we start talking about authenticaion, proxies always come up. More than a few Windows shops need authentication to through proxies to the outside. So we have another level of credentials.

It's always great to hear about actual use cases.

• What is your particular setup where you need authenticated access to a repository?
• Since you are talking about remote servers and authenticated access, are you OK with the remote server fetching a secured artifact and leaving it cached indefinitely? Of course caching it is the right choice for performance, but now we have opened up a can of worms in that we have to what creds we used to get it, and unless a second user provides the exact same credentials, the build machine should not use a cached version, else we could be leaking.

[oakad]

I'd say, an optimal approach is to do something simple first, then elaborate further. I, personally, would be content with a Maven credentials model to start with (it's not the most secure model around but it served us well over the years).

Maven stores credentials in plain text in a "settings.xml" file - essentially it's a map of custom server ids (user specified - those must be matched by the ids in the actual build file) to authentication material (passwords, private keys, whatever). It is assumed that the settings.xml file will protected by OS permissions (on multi-user machines) or isolated in a container (when dealing with those).

Caching is also ok, per the above model - it is either localized to user's home dir and thus protected by the user's home dir permissions or ends up in a secure container.

For proxies, Maven maintains a separate map similar to the above.

https://maven.apache.org/settings.html

[dslomov]

@dkelmer wdyt?

[depthwise]

FWIW, here's how I solved this problem: by putting stuff on S3 and downloading it from there with this here rule: https://github.com/1e100/cloud_archive/blob/master/cloud_archive.bzl. Not super principled maybe, but it works.

[meisterT]

Is there anything left to do here?

[jin]

No. There's netrc support now.