Oh, this web service is going to be such a nice target for hackers waiting to infect everyone who dares download random binaries. Centralizing “builds on demand” like this creates a pretty juicy supply-chain target. If the service gets popped, you’ve got a one-stop shop for shipping compromised binaries to every arch/OS combo. Convenient idea, but I’d only trust it with strong guarantees: reproducible builds, signed artifacts tied to commits, and a way to verify locally. Otherwise it’s basically “go install URL” with extra steps.
If you're in the market for this kind of thin convenience wrapper you might as well just vibe code a .goreleaser.yaml, .github/workflows/releases.yml and an install.sh. Takes a couple minutes, and you don't need to face angry users when this service is hacked/turns evil/shuts down. (Before anyone protests vibe coding, you're doing less due diligence by using this.)
It is mostly indicative of another underlying issue, like glibc versions or so. But this also leads to weird situations with reproducibility for QE/error reporting. One of the reasons I also hated some distro wanting to devendor and use distro dependencies. This all makes it harder to have a consistent support matrix.
> The response of this request is a Golang binary compiled for the requested
operating system, architecture, package version, and the binary's name—using Go
1.17.x
Uh... Go 1.17 is almost five years old. (The current version is 1.26.) Why is this service using an ancient version of Go?
so, it's kinda build server, building golang sources in remote server?
then, download the built binary?
it seems to be useful for normal enduser I guess
Oh, this web service is going to be such a nice target for hackers waiting to infect everyone who dares download random binaries. Centralizing “builds on demand” like this creates a pretty juicy supply-chain target. If the service gets popped, you’ve got a one-stop shop for shipping compromised binaries to every arch/OS combo. Convenient idea, but I’d only trust it with strong guarantees: reproducible builds, signed artifacts tied to commits, and a way to verify locally. Otherwise it’s basically “go install URL” with extra steps.
If you're in the market for this kind of thin convenience wrapper you might as well just vibe code a .goreleaser.yaml, .github/workflows/releases.yml and an install.sh. Takes a couple minutes, and you don't need to face angry users when this service is hacked/turns evil/shuts down. (Before anyone protests vibe coding, you're doing less due diligence by using this.)
Precisely; Go is by no means perfect, but if you want to throw away its security efforts, by all means use goblin.run
I’ll take vibe shooting myself in the foot over lying to myself any day.
I cannot fathom why anyone would want this.
It is mostly indicative of another underlying issue, like glibc versions or so. But this also leads to weird situations with reproducibility for QE/error reporting. One of the reasons I also hated some distro wanting to devendor and use distro dependencies. This all makes it harder to have a consistent support matrix.
> The response of this request is a Golang binary compiled for the requested operating system, architecture, package version, and the binary's name—using Go 1.17.x
Uh... Go 1.17 is almost five years old. (The current version is 1.26.) Why is this service using an ancient version of Go?
so, it's kinda build server, building golang sources in remote server? then, download the built binary? it seems to be useful for normal enduser I guess