News for hackers. Stuff that matters.

A comment on GitHub shouldn't allow username reuse.

Re:GitHub shouldn't allow username reuse by dasil003 on Friday February 09, 2018 @04:41PM (#16344080)
Title is a little bit hyperbolic. I get that it's a real issue that needs fixing, but a GitHub URL is not a secure package identifier, it was never designed this way, and it's an unfortunate hack that it's become a defacto standard.

What we really need is for language-level package managers to support signed immutable packages, and for that to start being taken seriously above the OS-level.

Edit: author changed the title, it used to say something about a "GitHub's security facepalm"

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by t0mk on Friday February 09, 2018 @05:00PM (#16344216)
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).

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by strkek on Friday February 09, 2018 @05:10PM (#16344287)
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.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by autotune on Friday February 09, 2018 @06:45PM (#16344826)
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.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by u801e on Friday February 09, 2018 @07:06PM (#16344921)
> 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.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by donatj on Friday February 09, 2018 @05:09PM (#16344283)
> It's simply solvable by refering to a commit hash

Do you never update your dependencies?

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by bmon on Friday February 09, 2018 @06:06PM (#16344614)
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?
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by macrael on Friday February 09, 2018 @06:11PM (#16344637)
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.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by avar on Friday February 09, 2018 @06:20PM (#16344686)
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.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by bmon on Friday February 09, 2018 @06:24PM (#16344707)
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.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by philipwhiuk on Sunday February 11, 2018 @07:21AM (#16352386)
Yeah the problem is Go has a stupid package management design.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by tomphoolery on Friday February 09, 2018 @04:49PM (#16344132)
> but a GitHub URL is not a secure package identifier, it was never designed this way, and it's an unfortunate hack that it's become a defacto standard.

Thank you. GitHub shouldn't be the only line of defense between a malicious coder and your software.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by whack on Friday February 09, 2018 @04:59PM (#16344210)
> What we really need is for language-level package managers to support signed immutable packages

+1 Emphasis on immutable. Can someone explain why popular package managers like npm don't offer this? During the leftpad fiasco, it boggled my mind that someone could just "liberate" their packages one morning, and transitively break the build for thousands of projects. Immutable packages would have prevented this entire problem.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by AgentME on Friday February 09, 2018 @05:16PM (#16344337)
NPM fixed that situation by no longer allowing packages to be unpublished after 24 hours. NPM does not allow packages to republish new content under a previously-used version number. NPM by default generates a package-lock.json file (separate from package.json) which pins the versions of all dependencies (including transitive ones) and includes the hashes of the dependencies, which would protect users if npm's servers ever became malicious.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by oneweekwonder on Saturday February 10, 2018 @09:15AM (#16347345)
> NPM by default generates a package-lock.json file

Thanks for the tidbit, seen it been added May last year to npm5[0]. Hard to keep up if you don't use the tooling activity and only depend on it for other tooling.

[0]: http://blog.npmjs.org/post/161081169345/v500

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by Demiurge on Friday February 09, 2018 @04:52PM (#16344164)
I tried to debug Go project once, and the moment I saw that, I was completely shocked that it was importing from github urls, without even tags, or versions as far as I could tell. It seems dangerous to rely on a for-profit host and individual users. If 'network' dependencies are part of the language, it should at least be non-profit, or better Go project managed host. There are many examples, like PyPi, or PECL.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by ovao on Friday February 09, 2018 @05:16PM (#16344333)
Go doesn't specifically rely on GitHub, but it can pull in dependencies with a simplified URL that points to a git repository hosted on GitHub. This is possible because GitHub renders an HTML meta tag on project pages that the go tool can reference to fetch information about the repository.

Anyone can actually 'reflect' dependencies hosted with various VCS with this method, and gopkg.in does essentially this (while adding version pinning).

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by ioddly on Friday February 09, 2018 @06:08PM (#16344625)
> Go doesn't specifically rely on GitHub, but it can pull in dependencies with a simplified URL that points to a git repository hosted on GitHub. This is possible because GitHub renders an HTML meta tag on project pages that the go tool can reference to fetch information about the repository.

Is there somewhere I can read more about this tag? Opened up the source of one of my repos and I couldn't find it.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by detaro on Friday February 09, 2018 @06:37PM (#16344785)
https://golang.org/cmd/go/#hdr-Remote_import_paths

<meta name="go-import" ...> tags

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by ioddly on Friday February 09, 2018 @06:47PM (#16344839)
Thank you! I didn't think to check the Go docs.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by strkek on Friday February 09, 2018 @05:24PM (#16344388)
The only drawback I see to this approach is that adding a new method is not trivial, and requires recompiling the `go` executable.

Makes it more difficult to implement a handler for the BitTorrent protocol to `go get` from a DHT, just for the sake of mad science.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by Klathmon on Friday February 09, 2018 @07:48PM (#16345136)
That sounds like an incredible idea!

Has anyone tried to do something like this before? I would absolutely run a torrent server to serve up my own and others' open source packages.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by ovao on Friday February 09, 2018 @09:21PM (#16345472)
To my knowledge it hasn’t been tried. It shouldn’t be too difficult to author a tool to do so, which could itself be made go-gettable. With this you’d avoid the mess of shipping an alternate build of the go tool and all that entails.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by comex on Saturday February 10, 2018 @12:03AM (#16345983)
This project was fairly close to that idea:

https://github.com/cjb/GitTorrent

I think it’s abandoned though.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by Klathmon on Friday February 09, 2018 @11:11PM (#16345826)
Yeah, the more I think about it the easier it seems.

You could probably write "plugins" or shims/wrappers for most package managers out there pretty easily.

And a great MVP would just be the ability to install from a magnet link.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by strkek on Friday February 09, 2018 @09:23PM (#16345475)
I read somewhere that big companies use BitTorrent internally to update their codebase.

But yeah, I'd really like for someone to develop a VCS like that (even more if it's in Go, with no Cgo, and under BSD, MIT or Apache license). It'd make distribution, immutability and mirroring so much easier.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by detaro on Saturday February 10, 2018 @06:38AM (#16346895)
There is https://github.com/whyrusleeping/gx (based on IPFS instead of torrents, but they work extremely similarly for this use case)
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by dewey on Friday February 09, 2018 @04:54PM (#16344177)
That's what vendoring and dependency tools are for.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by crdoconnor on Friday February 09, 2018 @05:02PM (#16344232)
That was the first wtf I hit when learning go that made me think that it possibly wasn't all it was cracked up to be.
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by sannee on Saturday February 10, 2018 @06:38AM (#16346894)
> It seems dangerous to rely on a for-profit host

Unfortunately, "non-profit" hosts are somewhat in a short supply.

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by beached_whale on Friday February 09, 2018 @07:35PM (#16345066)
It is git, so everything is signed. Just not authenticated. If you don't use head but a release or some tag you should be fine. Also, github supports permanent URL's
[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by Zamicol on Friday February 09, 2018 @06:24PM (#16344698)
I really feel like git having a secure package identifier built in is the right answer.

I haven't heard any news of git moving to SHA3-256.

Why shouldn't this be built in?

Here's an old thread from 2017-03-04: https://public-inbox.org/git/CA+dhYEViN4-boZLN+5QJyE7RtX+q6a...

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by craftyguy on Friday February 09, 2018 @06:51PM (#16344857)
> I really feel like git having a secure package identifier built in is the right answer.

git commits can be gpg signed: https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by Zamicol on Friday February 09, 2018 @07:39PM (#16345083)
I would never use that. It uses SHA1. The problem is the hash, not the signing. A secure package identifier doesn't necessarily need to be signed. Conversely, you must have a decent hash algorithm.

Your mentioned method signs the git commit hash. A signature is only as good as the hash you use, and SHA1 is not suitable.

https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-g...

Also see https://github.com/git/git/commit/721cc4314cb593e799213ad5f9...

[ Parent | on HN ]
Re:GitHub shouldn't allow username reuse by Shoothe on Saturday February 10, 2018 @07:40AM (#16347063)
What do you mean by "secure package identifier"? Do you mean commit hash using strong hashing function or something else?
[ Parent | on HN ]