This already happened to Twitter[1], Telegram[2], and even the PGP key infrastructure[3], not to mention obvious suspects like GitHub.
[1] https://pentestlab.blog/2017/09/26/command-and-control-twitt... [2] https://www.blazeinfosec.com/post/leveraging-telegram-as-a-c... [3] https://torrentfreak.com/openpgp-keyservers-now-store-irremo...
(I am a former Google SAD-SRE [Spam, Abuse, Delivery])
From long enough ago that I should apologize to you for libgmail: https://libgmail.sourceforge.net ? :D
Now I've definitely seen customized distributions of python from package managers that have taken steps to prevent you from using pip. IIRC, the python you get from `apt-get install python` in Debian does this? I.e., it's designed to support system utilities, not as a user's general purpose python environment, and they want `apt-get` to control this environment, not pip. So they've removed pip and ensure_pip and easy_install from your core system python environment.
TLDR: In my experience, that requirement doesn't come from pip, it's your distro taking steps to prevent https://xkcd.com/1987/
or even proprietary binaries, pip install nvidia-cudnn-cu12
* Very likely to be installed already on Linux and probably Mac too.
* Doesn't require root to install. You can even have isolated installs via pyenv.
* I don't have to ask anyone's permission to publish a package.
* I only have to make one package.
If any can think of a better option I'm all ears but until then I'm fairly happy with this hack.
As a user, the npm usage doesn't seem very prominent. On an npm's web page, there's a checkmark next to the version number on the right side that I hadn't paid any attention to before, with more information at the very bottom of the page. Here's an example. [3]
[1] https://blog.sigstore.dev/npm-provenance-ga/ [2] https://blog.sigstore.dev/homebrew-build-provenance/ [3] https://www.npmjs.com/package/fast-check
Perfect for the purpose.
In the end, there is no definition of "a source control repository that is a Go module" that is robust to this sort of "attack"... although calling it an "attack" is kind of dubious, the reasons why this is a bad thing strike me as very strained and relatively weak. Mostly it hurts Google by hosting too much stuff, but, good luck bringing them down that way.
This issue is kind of curious because Athens already uses the go mod download -json command mentioned as a preflight check for module verification. More or less, if the repo passes the go module commands understanding of a module then Athens will serve it. In more verboten terms:
- a module version, pseudo version, or +incompatible must be able to be formulated
- that module (and it's dependencies) must produce a valid checksum
The checksum of modules just has to do with the current .mod and all files + recursively for each dependency. So, as the author pointed out you can have lots of space for arbitrary files by design so long as you have a basic go program.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- proposal: https://github.com/cue-lang/proposal/tree/main/designs/modul...
- custom registry: https://cuelang.org/docs/tutorial/working-with-a-custom-modu...
- road map: https://github.com/orgs/cue-lang/projects/10/views/8
- in 0.9.0-alpha-5, modules become enabled by default: https://github.com/cue-lang/cue/releases/tag/v0.9.0-alpha.5
For Go Sum, the Trillian project backs the transparency log: https://github.com/google/trillian
CUE plans to piggyback on the OCI options with attestations and such
So CUE's module design can be seen as an evolution on Go's, building on the good parts while addressing some of the shortcomings.
Fun fact, CUE started as a fork of Go, mainly for the internal compiler tooling and packages
The article does make the point that some monitored networks might trust golang proxy URLs more than arbitrary web URLs and that this could be used for bypassing reputation filters etc -- but there are already several ways to do that, and this one doesn't seem particularly special.
I would hope the Go team collaborated with GCP and Drive, as hosting malicious files is something Google has to deal with all the time. This isn't much different from other endpoints Google already allows people to put random data on.
Former Googler, I know nothing about the Go Dev Tools team, but Google collaborates in this way better than almost any massive company I've worked at or heard about from close friends.
Google is really good at having a central team manage infrastructure, and share it across the company. As long as it's not a messenger app. Surely (pure guessing) the go team is using the internal blob store, and I think there is some internal-infra teams that handle abuse and file scanning automatically.
