4 ms·
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 gith
by t0mk 9y ago
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).
- donatj 9y ago> It's simply solvable by refering to a commit hash Do you never update your dependencies?
- bmon 9y agoIf 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?
- macrael 9y agoThere 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.
- avar 9y agoIt'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.
- bmon 9y agoRight, 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.
- strkek 9y agoCall 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.
- autotune 9y agoHence 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.
- deleted 9y ago[deleted]
- u801e 9y ago> 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.
- philipwhiuk 9y agoYeah the problem is Go has a stupid package management design.