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.)
> 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?
6 comments
[ 3.1 ms ] story [ 20.7 ms ] threadUh... Go 1.17 is almost five years old. (The current version is 1.26.) Why is this service using an ancient version of Go?