Hacker News Reader

Comment by kenhwang | Hacker News Reader

Or maybe Github shouldn't be used as a package repository if security is a concern.

I also think it's weird how Go uses Github HEAD as the package download source. Strange.

Go doesn’t “do” that.

Using GitHub HEAD is one of many ways it can be used. It’s not a very popular approach. People with important projects that often use other ways, such as vendoring via a tool like dep.

Go doesn't do that, but it enables it and I'd even say encourages it, starting from the documentation https://golang.org/doc/code.html#Library

Even projects using dep continue this pattern of pulling things from github master. I just browed through the top projects on Github for go and pretty much all of them that contained a gopkg.toml pulled in one or more things from github directly from master

https://github.com/grafana/grafana/blob/master/Gopkg.toml https://github.com/containous/traefik/blob/master/Gopkg.toml https://github.com/cockroachdb/cockroach/blob/master/Gopkg.t... https://github.com/github/hub/blob/master/Gopkg.toml

These include projects like graphana, cockroachdb and hugo.

> Go doesn't "do" that

Literally the first example of the Go tour [1] tells you to run "go get". "dep" is not (yet) an official part of Go's tooling. So when the only official tool fetches HEAD and calls it a day, I think it's perfectly fine to say "Go does that".

[1] https://golang.org/doc/

The 'go get' tool is just a small convenience wrapper around git/hg/svn. Its intended for use by developers, for quickly taking a look at some source code. The tour use case you cited is also a good fit for 'go get'.

It was never intended to be a part of your production build process. If you push its outputs directly to production, you're holding it wrong.

It's pretty annoying. Most of the time I want to build a stable version not HEAD which could break in many ways. Using HEAD as a dep is pretty much insane. Stop publishing for several months and the code would most likely fail to build.

It is an extremely popular approach. It might not be the best way, but I’d argue it is the default for most people.

You can use tools like glide to lock in a particular revision, like package-lock.json with NPM.

> You can use tools like glide

Ah, the new hotness is dep (as opposed to godep, as opposed to govendor). I love Go, but man if it doesn't have a bit of JavaScript's reïmplement-the-world problem.

The funny thing to me is that this was always pointed to as a problem of Lisps: Lisp is so powerful that a student can implement an object system as homework, and the issue is that every student will. It looks like this problem isn't limited to Lisp: any sufficiently-powerful language enables programmers to reïnvent the wheel rather than forcing them to collaborate (e.g. as with C, where doing anything is so incredibly difficult that it's easier to pitch in with someone else's project than start your own).

go dep hilarious fails to work with private repos. It just hangs whenever I try running it. Looking through its source code it looks like it's actually just a fork of glide.

It works for us, with GitHub private repos. We already have each repo checked out locally, though, so perhaps git is already aware of our credentials?

Also, it may not be hanging but merely running for a very long time. Sometimes I'll start dep, then head to lunch.

It's … not the fastest thing ever.

That's insane. Glide takes a couple minutes tops with a clear cache. No reason it should take more than that.

If security is a concern, the entire premise behind package managers and blindly trusting code pulled from a remote server is flawed regardless of where it comes from.

Checking the hash of the code against an expected value should at least ameliorate that concern.

Or, maybe you should gpg sign your commits. Then github is irrelevant, assuming you have sole control over your private key.

Even then, the consumer of the package is still dependent on the security practices of the holder of the key. It's more secure, but still not something you can depend on universally as a consumer.

"I promise you can trust me" is not something you can trust.

What do you propose then? If you can't trust the person, then why trust them at all? That argument doesn't make sense.

No one (absolutely no one) should be trusting a human being to be 100% infallible when it comes to security. That's what I'd propose, without even going into the topic of the fallibility of software.

If you're interested in the topic, there are many good papers and studies on how we can't even trust ourselves when it comes to basic things like memory and honesty (with ourselves).

Even then it doesn't matter because you are signing an insecure hash.

I agree, or at the very minimum it seems like you'd need to fork every repo you wanted to use as a dependency that way.

I actually tried to do that, but quickly realized there is no way I could follow the tree of forks. How is what you're saying practically possible?

Beware that if upstream deletes the repo yours goes with it (if it's private).

Reply on news.ycombinator.com