Potential Vulrnerability With Gopkg.in about corpus HOT 8 OPEN

lol nvm.

from corpus.

Obviously this doesn't matter to go-corpus, so closing the issue was fine. But as someone interested in package management in Go I would like to understand more about what you are reporting, so I reopened it.

How can requests to import github.com/fsnotify/fsnotify have anything to do with gopkg.in? Also I don't believe there's any ambiguity about what a gopkg.in URL means so I don't understand how, even if we were talking about gopkg.in import paths, creating a new repo on GitHub would redirect existing gopkg.in paths.

Thanks very much for any additional information.

/cc @niemeyer

from corpus.

I had started to write a script to notify all repos that used gopkg.in/fsnotify.v1 (I didn't run the script beyond the first repo it found in the end), because of an issue my team encountered. Here is the long version.

github.com/fsnotify/fsnotify 2 years ago was named github.com/go-fsnotify/fsnotify. We are using a tool that utilizes fsnotify through gopkg.in/fsnotify.v1. gopkg.in/fsnotify.v1 until today redirected to github.com/fsnotify/fsnotify. (I think this is because of the redirecting github does when an organizations name changes, but don't quote me). Someone created a new go-fsnotify organization with an empty fsnotify. My team thought it was the beginnings of a bad actor exploiting gopkg and the github redirect behavior and was planning on putting some bad code in the repo similar to what happened earlier this year with npm packages. After talking to @niemeyer we ended up figuring out that it was a false positive.

TLDR github redirects due to renaming made my team worry about a potential bad actor.

from corpus.

Fascinating, thanks @robbert229. It certainly seems like a bug that GitHub lets people recreate deleted accounts.

@nathany, was that you re-creating go-fsnotify/fsnotify?

from corpus.

Indeed the issue was created by the rename of the original project plus the fact it wasn't further reserved. But we're not entirely sure it's a false positive yet. The organization registrant hasn't spoken up, and the repository description as "Go Dependency R&D" leaves room for interpretation. If we don't resolve this soon I'll need to redirect or at least block that project internally in gopkg.in.

from corpus.

Follow up conversation here: go-fsnotify/fsnotify#1

from corpus.

A security research recreated the go-fsnotify organization. My mistake for relying on the GitHub redirect and not considering the security implications.

from corpus.

See also fsnotify/fsnotify#108 for the original reasoning behind moving away from gopkg.in and version numbers in import paths (this happened over two years ago).

from corpus.