If you care about security, you're already auditing all your vendored/dependency code, right?

Overriding rand.Reader in useful in tests, for example.

Yes, if you care about security, you're already auditing all vendored/dependency code. However, there's a difference in required effort between auditing for packages that e.g. make calls to unsafe, try to make system calls, or load DLLs, and auditing for packages that try to sneak in a single write to a global variable.

I don't think the benefits of overriding crypto/rand.Reader globally for tests outweigh the downsides of having one package's crypto be breakable by another package. It is easy enough to plumb through an io.Reader through the code you want to test.

Just wanted to add that, one of the many reasons that Go is fantastic is that it makes good choices and sane defaults for many things, so people don't make mistakes even if they don't have the awareness to, for example, audit vendoring.

This is similar to saying a class has secure member variables because they're private in other languages. Most operating systems don't even support this kind of security in the same user context, let alone process or package scope. If you're running untrusted code there are bigger things to worry about than package variables.

Well, it depends what you mean by 'secure', and what other languages you're talking about. I agree that, say, private variables in C++ are easy to work around, as well as dynamic languages like Ruby/Python/Javascript. However, for example, in Go, unexported variables are inaccessible outside of package scope by code that doesn't use unsafe, cgo, reflect, or some other similar magic, and assuming there isn't some bug in the go runtime/compiler. In that sense one could say that unexported variables are 'safer' than exported ones.

Note that my threat model isn't arbitrary untrusted code, so the comparison to OS-level security isn't really applicable -- it's third-party code that has to be audited before inclusion in a project. It's reasonably easy to audit the dependencies of a package, i.e. to check that it doesn't use unsafe, cgo, reflect, etc., and to perform greater scrutiny if so. It's a bit harder to audit its access of external package variables, and this bug demonstrates that the potential consequences of something slipping through the cracks isn't just weird stuff happening (like setting io.EOF to nil), but a compromise of a RNG that packages depend on for security.

Someone else mentioned that this has been brought up before for e.g. http.DefaultClient. The difference in this case is that one could create their own instance of http.Client and be diligent about using that. However, that's impossible in the case of crypto/rand.

On the other hand, it's not infeasible to write a tool that automates looking for code that modifies external package variables (except for reflection, unsafe, etc.). Although it's unfortunate that such a tool has to be written.

If you're truly worried about this, check it once in a while.

Maybe for Go 2 we could change the declared type of Reader so that there was nothing you could reassign to it.

With five and half years of additional experience seeing software supply chain attacks increase, hopefully the stance expressed by the language team here can be softened. Sometimes even an extensive dependency audit is not enough, when things like typosquatting, dead repository resurrection, and renamed repository hijacking can change the underlying landscape. A lot of attacks are low-effort, target low-hanging fruit, and go undetected for a while. While module sums nowadays can protect against some of these attacks, there is a fundamental tension between never updating dependencies (and thus knowing exactly what you're using) and ensuring that critical security issues get addressed (which often requires updating dependencies ASAP).

For a sophisticated attacker with the ability to inject arbitrary code, there are other, better ways to break the security of a Go program. However, thinking in terms of defense-in-depth, just because all of the problems cannot be fixed easily does not mean an obvious and fairly easy-to-fix (or at least, easy-to-address) problem like this should be dismissed.

All that having been said, I think this is mostly a specific case of a more general problem, which is the lack of a way to protect global variables from modification by other packages/modules. Though functions can be used instead of variables, they are often not as ergonomic or discoverable as variables.