New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

META-SHARE installation depends on my github account #762

zeehio opened this Issue May 12, 2016 · 1 comment


None yet
1 participant
Copy link

zeehio commented May 12, 2016

  • Some time ago I worked on my free time to upgrade META-SHARE from django-1.3 to django-1.4.
    • To do that I decided to move META-SHARE from a lib/ directory with all the dependencies bundled to the standard way of declaring dependencies in python packages: a requirements.txt file.
      • This allowed the installation instructions to use virtualenv, which is the standard way of having dependencies installed for python software.
      • This allowed to have a clear log of META-SHARE dependencies and versions.
      • I downloaded all the upstream dependencies and compared them with the bundled lib/ dependency, so I could check if each dependency had been patched or not.
      • For those patched dependency cases, I created a fork of the upstream package, and committed the patch that original META-SHARE developers had applied to it. example
        • Keeping the patch as a commit, I provided clear information of both the upstream version used and the patch applied.

That's why you can read in the requirements.txt file (used during the META-SHARE installation) some github references pointing to my github account:


I don't want the responsibility of breaking all the META-SHARE 3.0.3 installations in the future, if I ever forget that the META-SHARE installation depends on those repositories and remove them, because I don't use them any more.

I am opening this issue to ask someone in the metashare github group to fork my projects (zeehio/django, zeehio/django-haystack, zeehio/django-kronos) under the metashare umbrella and update the requirements.txt so it points to something metashare developers control. It is easy: Click on my forks, click on fork, and fork to metashare/. Then use git+git:// in the requirements instead.

Finally, I would like to express my concern again regarding META-SHARE dependencies (see #751), as it depends on patched and unsupported upstream packages. For instance, I believe that META-SHARE v.3.0.3 (and previous versions too) are affected at least by a DoS vulnerability CVE-2015-5143 because they use an outdated django version. I know it is expensive, time consuming and usually has a low visibility, as it provides no new features, but the dependencies need to be updated if the META-SHARE network is expected to continue running.

JuliBakagianni added a commit that referenced this issue May 13, 2016


This comment has been minimized.

Copy link
Contributor Author

zeehio commented May 17, 2016

Thanks! I feel relieved now!

@zeehio zeehio closed this May 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment