Abusing Go's Infrastructure
reverse.put.as
reverse.put.as
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])
Deliver was because we ran the SMTP and queuing infrastructure at the time. We started as Gmail SRE, then split out some of the delivery and abuse services into its own team (SAD), then SAD got SRE, hence SAD-SRE =)
Otherwise, something as simple as a spell checker would be an invasion of privacy because it literally looks at every word in an email you write. That's absurd.
1) you need to constantly update the spell checker so each time you say this is word or something like that most likely the data is send the problem is part of the data, I assume Google do something similar whit data send to span and mark as not spam. This is full email redirect and analysis not partial like old word processing.
2)I feel ai make this even more harder so now you can't simply check patterns as simply as before, and you need to check the whole content constantly
An algorithm that leaked no private information would not be useful to a business. It would do a bunch of computation and then throw it away. So realistically anything that looks at private information is privacy-relevant.
That includes even just the email headers. To quote the former head of the NSA "We Kill People Based on Metadata" https://abcnews.go.com/blogs/headlines/2014/05/ex-nsa-chief-...
You can have debates about how much private information should be leaked and for what purposes. But I don't think having a threshold like "it's all private unless another human reads it" is a good way to think about the issue.
The spell checker would also be a massive privacy invasion if if flagged users based on the content of what they wrote.
I do think there is an obligation to report if any is found, but I don't think they need to look.
There is absolutely no promise on any cloud hosted services that a human will not ever see your data. However, at Google it was made very, very, VERY clear that if we had to scan somebody's personal email for any reason then discussion of the contents outside of legally mandated, or required for work ways would lead to immediate termination and possible lawsuit for any damages to reputation incurred.
While fixing user accounts, or dealing with delivery of content I saw epic piles of personal email. Besides the ones full of CASM or other abusive material I couldn't say that I ever remembered the contents 30 minutes later. Its like a checker at a grocery store. They don't care about whatever embarrassing tings your buying and won't remember you 10 minutes later. =)
From long enough ago that I should apologize to you for libgmail: https://libgmail.sourceforge.net ? :D
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.
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.
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/
1: PEP 668 https://peps.python.org/pep-0668/
2: https://packaging.python.org/en/latest/specifications/extern...
This happens on Ubuntu, Debian, Fedora and macOS (Homebrew). I'm pretty sure it's just a core part of pip these days.
- 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
I could add a "Statement that we might wish to make for a module M" to the "Module contents assurance" section:
- The content of module M is the same content that everyone else sees for the same `$path@$version`.
Though I guess users can utilize existing solutions like https://github.com/sigstore/cosign or rekor (mentioned elsewhere itt).
Perfect for the purpose.
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
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.
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...