Hacker News Reader

Comment by oakhaven | Hacker News Reader

I thought the same with the exaggerating. The author of the article can hardly blame github. But he makes a good point, I never realized how much I rely on github username policy in Go code :).

If golang allows to import from Git URLs over HTTP or SSH, then it is the same problem with DNS as with the github usernames, isn't it? If the domain name, from which you import, will disappear, then someone else can register it and serve malicious code. This is also pretty hyperbolic.

IMO It's simply solvable by refering to a commit hash, like govendor does it (or the gemfile in ruby for that matter). I am actually not sure why it's not possible to add commit hash to a golang import, I thought that $GOPATH/src contains only git repos (but I'm not sure about this).

View on HN

Call me paranoid, but I've always assumed urls are not permanent. Domains can change, usernames can change, and published things can be taken down.

For example, I may publish something as an online backup or a mirror of my real repositories, without any kind of guarantee whatsoever. ONLY sharing because I want people to be able to see how the things I do were made. I mean, even most FOSS licenses explicitly state that there are no guarantees of any kind.

IMHO I think people should stop with the "if it's on internet, it must retain compatibility" mindset, and instead switch to a "this will break or disappear at any time unless explicitly stated otherwise" mindset.

Hence why it's important to have your own software package repository server and grab internal packages from that rather an external party for any serious infrastructure.

> It's simply solvable by refering to a commit hash

It really ought to refer to a signed tag that the package manager verifies before installing the package.

> It's simply solvable by refering to a commit hash

Do you never update your dependencies?

If you don't pin your deps to a commit, what's the difference between the author deleting their account (and being replaced), and the author merging an evil commit?

There is no difference technically, but the point is that as is the author has built up a reputation and trust, and that someone taking their name inherits the trust without the reputation.

It's still a bad idea not to pin your dependencies even if you trust the author.

Say you want to check out some older version of the code for bisecting, and it doesn't even build anymore because it worked with some version of the dependencies that was the latest years ago, good luck figuring out what commit they were all on at the time.

It's trivial to just update your own project to point to the latest upstream SHA-1s and commit that, this is why git's own facility to do this (submodules) pins you at specific upstream commits.

Right, so the author going awol would be a pretty big break off that trust right?

What about the author having their github account compromised? I agree that GitHub account names should not be released so quickly, but if you're seriously worried about that possibility then I'd think it's also wise to be worried about the possibility of upstream being compromised in other ways.

Yeah the problem is Go has a stupid package management design.

Reply on news.ycombinator.com