6 ms·

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

by kenhwang 9y ago

sergiotapia 9y ago
I also think it's weird how Go uses Github HEAD as the package download source. Strange.
- artursapek 9y ago
  You can use tools like glide to lock in a particular revision, like package-lock.json with NPM.
  - zeveb 9y ago
    > 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).
    - artursapek 9y ago
      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.
      - zeveb 9y ago
        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.
        artursapek 9y ago
        That's insane. Glide takes a couple minutes tops with a clear cache. No reason it should take more than that.
- shurcooL 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - calcifer 9y ago
    > 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/ https://golang.org/doc/
    - petre 9y ago
      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.
    - slrz 9y ago
      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.
  - cstejerean 9y ago
    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 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/grafana/grafana/blob/master/Gopkg.toml https://github.com/containous/traefik/blob/master/Gopkg.toml https://github.com/containous/traefik/blob/master/Gopkg.toml https://github.com/cockroachdb/cockroach/blob/master/Gopkg.toml https://github.com/cockroachdb/cockroach/blob/master/Gopkg.t... https://github.com/github/hub/blob/master/Gopkg.toml https://github.com/github/hub/blob/master/Gopkg.toml These include projects like graphana, cockroachdb and hugo.
greymeister 9y ago
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.
- Demiurge 9y ago
  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?
- rocky1138 9y ago
  Beware that if upstream deletes the repo yours goes with it (if it's private).
krapp 9y ago
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.
- mcphage 9y ago
  Checking the hash of the code against an expected value should at least ameliorate that concern.
craftyguy 9y ago
Or, maybe you should gpg sign your commits. Then github is irrelevant, assuming you have sole control over your private key.
- mathgeek 9y ago
  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.
  - craftyguy 9y ago
    What do you propose then? If you can't trust the person, then why trust them at all? That argument doesn't make sense.
    - mathgeek 9y ago
      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).
  - Zamicol 9y ago
    Even then it doesn't matter because you are signing an insecure hash.

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

sergiotapia 9y ago

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

artursapek 9y ago
You can use tools like glide to lock in a particular revision, like package-lock.json with NPM.
- zeveb 9y ago
  > 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).
  - artursapek 9y ago
    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.
    - zeveb 9y ago
      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.
      - artursapek 9y ago
        That's insane. Glide takes a couple minutes tops with a clear cache. No reason it should take more than that.
shurcooL 9y ago
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.
- deleted 9y ago
  [deleted]
- calcifer 9y ago
  > 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/ https://golang.org/doc/
  - petre 9y ago
    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.
  - slrz 9y ago
    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.
- cstejerean 9y ago
  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 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/grafana/grafana/blob/master/Gopkg.toml https://github.com/containous/traefik/blob/master/Gopkg.toml https://github.com/containous/traefik/blob/master/Gopkg.toml https://github.com/cockroachdb/cockroach/blob/master/Gopkg.toml https://github.com/cockroachdb/cockroach/blob/master/Gopkg.t... https://github.com/github/hub/blob/master/Gopkg.toml https://github.com/github/hub/blob/master/Gopkg.toml These include projects like graphana, cockroachdb and hugo.

greymeister 9y ago

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.

Demiurge 9y ago
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?
rocky1138 9y ago
Beware that if upstream deletes the repo yours goes with it (if it's private).

krapp 9y ago

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.

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

craftyguy 9y ago

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

mathgeek 9y ago
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.
- craftyguy 9y ago
  What do you propose then? If you can't trust the person, then why trust them at all? That argument doesn't make sense.
  - mathgeek 9y ago
    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).
- Zamicol 9y ago
  Even then it doesn't matter because you are signing an insecure hash.