Yeah I think people are very serious when they say that, though it is important to consider that they are talking about it from an installation convenience factor.

Being able to drop one binary over to a host (as opposed to the usual "DLL hell" of installing binary packages which, despite not being DLLs, is still quite common on Linux and other modern UNIX systems in the form of package versions) is insanely simpler than the usual methods.

Now, whether we trust that binary is a wholly separate matter. Maybe we do, maybe we don't, maybe it is signed by the original source, maybe we got it from a trusted source, maybe we built it ourselves from source after an extensive security audit (hopefully some variant of Ken Thompson's [part of the go team, though I present this as an interesting curiosity and nothing more] compiler hack isn't in play). But the security concerns surrounding the trust in the origin of the software and the ease of installation concerns are separate concerns. You can have one or both or neither.

Installing this blog software directly from a pre-built unsigned binary you ftp'd off some random site without ever looking at the source would be neither, but that doesn't negate the deployment benefits of "one single binary" which can be provided with both (at least to the degree that you can trust any 3rd party software).

I agree that one shouldn't copy just any binary on their server and run it. I'd like to help with this. Are you just thinking about providing SHA sums next to the binaries/zip releases on the download page? What kind of cryptographic signatures do you have in mind?

Regarding Journey:

You can always compile from source. Go makes that easy, dependencies on GitHub will be downloaded automatically.

If you trust my builds, the releases page on GitHub is served via HTTPS, so no one should be tinkering with the binary on the way from the server to you.

In your case, PGP would be the best and not so hard to implement.

If you don't want/know how to use PGP you can also publish the SHA1 sums of the files available on your download page. It's better than nothing.

The second alternative is weaker because an attacker would simply need to change the binary and the sum on the website. In the PGP case, the attacker must get access to your PGP private key, and provided that you use PGP reasonably (no private key on your web server), this is harder.

You could PGP sign the binaries.

I've never quite understood the practice of putting SHA hashes next to a download. If an attacker has access to the download surely they also can manipulate the hashes as well.

You could always `go get github.com/kabukky/journey` if you'd prefer to build from source.

I don't see how thats any different from copying a .deb/.rpm/add-apt onto your server.

Having source code readily available didn't stop heartbleed.

If you're downloading random unsigned debs/rpms from the internet and installing them, then you're just as wrong as downloading/execing a binary.

If you're downloading rpms/debs, verifying the signatures, and you trust the signer, then you're probably fine. Those signature signing/checking mechanisms are already built into rpm/deb, which is why they're being argued for.

I don't see how a binary that you can't inspect is meaningfully less secure than source code that you don't inspect. I very much doubt most people vet, for example, the source code to Nginx before compiling and running it. If you're one of the few who does that, you still have that option here. I don't think this distribution model is giving up much.

The point is that someone can inspect that code, not that everyone needs to inspect every piece of source code they use. If the source isn't available, no one can inspect it. That is qualitative different than providing the source code.

Huh? The link to the source is literally right under the link to the binary.

But you don't know that the binary is compiled from _that_ source code.

Compile it yourself, problem solved.

It's slightly better than the "wget this script and pipe it to sudo" fad.