While you can create and build a local package with U+FE0E in its file name, you cannot create or download a module using that character in a file name. So you could run this attack in someone's top-level repo but not in any of their dependencies. That's something at least.<p><a href="https://go.googlesource.com/mod/+/refs/heads/master/module/module.go#58" rel="nofollow">https://go.googlesource.com/mod/+/refs/heads/master/module/m...</a>
<a href="https://go.googlesource.com/mod/+/refs/heads/master/module/module.go#272" rel="nofollow">https://go.googlesource.com/mod/+/refs/heads/master/module/m...</a>
> I am not employed at the University of Minnesota so I don’t go around sending malicious patches just to see what would happen.<p>Lol, they will never live that one down.
A vulnerability illustrated here is that of packages having global state which is both security-critical and world-mutable. Such a vulnerability exists in the standard library, most notably (crypto/rand).Reader which is <i>usually</i> fed by the system CSPRNG but can be overwritten to any io.Reader value. There has been some discussion around different ways to address this issue, but fixing it has generally been rejected by the language maintainers,
e.g. <a href="https://github.com/golang/go/issues/42713">https://github.com/golang/go/issues/42713</a>, with the argument that fixing it directly just provides an illusion of security.