He obviously wasn't clear enough about this, but if you're just trying to use the tool, download the binary release. Don't use go get as an installer. They're trying to be multi-OS compatible, an autotools that doesn't assume every system has a /usr/local or whatever the Windows equivalent but not assuming everyone has a %USERPROFILE%\AppData\Local\Low\Roaming or whatever. It does assume everyone has a home directory and an environment variable indicating where that is.
If you opt into modules, modules get stored in GOPATH. If you don't use modules...source gets downloaded into GOPATH. If GOPATH is unset, it uses ~/go.
Not just you. I've been using Go for many years, and while I enjoy the language I always found the environment of it awkward and unfriendly. Envvars on top of envvars. Work only in GOPATH, no wait, stop working in GOPATH. Vendor things...no wait don't do that either.
I think a lot of it is just growing pains, but it still feels clunky. My system has a .cache folder that everything already uses, why does Go need a special cache?
That seems... a bit much IMO. I personally prefer containerizing things. Such as Node.js’ way with node_modules. Then I can put my project wherever I want. Downloaded dependencies can also go in ~/.cache because I don’t plan on editing them.
Go projects using modules are permissive about where you put them (e.g. they don't have to be inside a GOPATH at the right location). It does still use a GOPATH for caching directories though, which seems normal enough. They have to go somewhere, usually declared in some env variable, or they have to have a default location and silently spread files all over. `go get` is not a binary installer, it's a go-project-downloader that happens to also be able to install binaries, so this is IMO expected as it doesn't toss the intermediate products (i.e. a temp folder is not a reasonable choice).
As for multi-language projects and conflicting layout needs: oh yeah, that's still terrible. Maybe try Bazel? It can break `go`(the CLI binary)'s rules and build any package from any source files, regardless of their locations. None of that is part of the language spec, `go` is just opinionated and inflexible (probably for simplicity).
Go uses $GOPATH to save it's own packages/binaries but uses $HOME/go if $GOPATH is not set. Originally needed $GOPATH to be set, but that changed later
Looks interesting for testing local server security. A useful feature to add might be a link to an explanation of the exploited vulnerability, and how to resolve it.
From the readme (saves you the trip to github):
"It'll exploit most sudo privileges listed in GTFOBins to pop a root shell, as well as exploiting issues like a writable docker.sock. More routes to root will be added over time too."
It's a cool idea and I like the execution but if I'm at the point where I've uploaded the binary over and executed it I've already run `sudo -l` and checked my permissions (and I could be wrong but from my brief scan of the source code I don't think it attempts to exploit SUID but just sudo permissions). Probably would save a little bit of time with docker escalation but again pretty standard enumeration would've revealed that vector by then.
How do you plan to use this universally across compromised systems, if they don't have Go to compile this?
A better solution might be https://github.com/Frissi0n/GTFONow which is written in python without dependencies and supports Py2/3. I would expect this to work on more hosts.
I mean typically yes, I keep binaries around for whatever system I'm targeting. 32+64bit binaries for linux and windows (4 total) will cover about 99% of any machines you're likely to come across. I think you've taken more of an issue with this than is necessary, seeing as if I can run linpeas or linenum I am probably not going to have an issue running a static binary, and it's really a matter of personal choice.
Unlike most of compiled languages Go have no-effort cross-compile for different architecture. All you need is to specify GOARCH. So what's problem with compiling different binaries?
There's no way to achieve this...even writing things in POSIX is going to be incompatible on some systems. Having a different binary for different systems is necessary. Even writing things in an interpreted language e.g. Python still requires at least Python binaries on all your systems, and that's ignoring dependencies. It doesn't get much more convenient than Golang's cross compilation.
Most of these tricks are listed here at GTFOBins: https://gtfobins.github.io/ which is based on LOLBAS for Windows: https://lolbas-project.github.io/#