Avoid plaintext warning when .netrc doesn't contain uri of HTTP cache

Description of the problem / feature request:

We have a .netrc that does not contain the uri of our HTTP cache. The .netrc only contains credential for other purposes.

We use a HTTP cache without authentication. We are not using HTTPS for performance reasons.

We don’t want the new warning printed by bazel: “Username and password from .netrc is transmitted in plaintext. Please consider using an HTTPS endpoint.”

The new warning was introduced:

commit ae28ab7d911460839c1db65c0c325717fdeaa13b Date: Sun Oct 11 21:05:27 2020 -0700

here:

https://github.com/bazelbuild/bazel/blob/ae28ab7d911460839c1db65c0c325717fdeaa13b/src/main/java/com/google/devtools/build/lib/remote/RemoteModule.java#L1006-L1016

Feature requests: what underlying problem are you trying to solve with this feature?

Avoid the warning message when the .netrc does not contain the uri for the remote http cache.

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Enable --remote_cache with HTTP (not HTTPS) Have .netrc with other credentials, but not for the remote cache uri

What’s the output of bazel info release?

3.7.0

[bjacklyn]

Yeah I just ran into this when attempting to upgrade the bazel version. This prints a scary warning message which is wrong since I don’t have any creds to the remote cache in my .netrc: if you use an remote cache with http and have a .netrc that has no entry for the remote cache url (or even an empty .netrc file) this warning is printed.

I would have figured out where this warning was coming from faster if the warning also printed the url it is complaining about. I originally thought it was coming from some http_archive dependency in my WORKSPACE.

@coeuvre Is there any flag that can disable this warning? This is going to cause a lot of users to worry when they see it.

[BalestraPatrick]

@coeuvre We did use 4.0 but possibly we didn’t see this warning due to the fact that we were using a gRPC cache until some time ago. I guess we switched to an HTTP cache right at the same time we switched to 4.1.