search

probcomp / bdbcontrib

BayesDB contributions, including plotting, helper methods, and examples
http://probcomp.csail.mit.edu/bayesdb
Apache License 2.0
9 stars 6 forks source link

bdbcontrib requries python 2.7.11 #132

Closed fsaad closed 8 years ago

fsaad commented 8 years ago

What is the justification for this requirement -- in particular, what parts of bdbcontrib explicitly require python 2.7.11, and why? python 2.7.6 is the standard on Ubuntu 14.04 LTS [1] and asking a user to grab a whole python installation for a small package like bdbcontrib is not a reasonable requirement. Neither is it a requirement that can be solved directly using a virtual env (unlike new versions python packages) -- our experience today where we lost 2 hours debugging the migration was proof of that.

[1] When we support the next Ubuntu LTS which has an update python 2.7.11 it will make more sense than now.

fsaad commented 8 years ago

For example, a user cannot now use the gtkagg or qt4 backend, which are far superior to tkagg, in matplotlib because they are not available for 2.7.11 through any standard mechanism.

riastradh-probcomp commented 8 years ago

No idea why anything might depend on 2.7.11 beyond a remark by @gregory-marton in personal communication without elaboration. Elaborate please so we can just fix it? Changing foundational infrastructural requirements during deadline pressure is not cool.

fsaad commented 8 years ago

It's not just that it is "not cool", it just does not make any sense why an entire new version of python is required -- I cannot envision what critical features necessitate it, and I imagine it will cause problems for users in the future as it caused problems in the past.

riastradh-probcomp commented 8 years ago

All the tests pass on 2.7.6, so if something is broken on 2.7.6, it is not being automatically tested.

leocasarsa commented 8 years ago

This warning:

/home/leo/venv/20160505-headbdb/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning

And @gregory-marton says it's not safe for a reason I don't really know.

riastradh-probcomp commented 8 years ago

Date: Sat, 07 May 2016 12:31:53 -0700 From: leocasarsa notifications@github.com

This warning:

   /home/leo/venv/20160505-headbdb/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
     InsecurePlatformWarning

And @gregory-marton says it's not safe for a reason I don't really know.

That warning happens only if the software is already actively snooping on you and relaying your activity to a probcomp server. The effect is that a man-in-the-middle on the network may be able to impersonate the probcomp server and snoop on you too.

If you're not comfortable with the software doing this, you can set the environment variable BAYESDB_DISABLE_VERSION_CHECK=1 and do

import bayeslite.loggers bayeslite.loggers.CallHomeStatusLogger = bayeslite.loggers.SilentLogger

and then it doesn't matter whether there are issues in Python 2.7.6's TLS support.

(If, like me, you're not comfortable with the software having been written to do this then feel free to voice that concern with others.)

gregory-marton commented 8 years ago

Yep, we communicate users' usage to the server so we can benefit from that. We tell people that at the get-go and require them to opt in or opt out with clear instructions in each case. In order to protect our users as they do so, we would like them to use a python that doesn't expose them to needless security issues. If they insist on using out-of-date python, then they are indeed better off opting out, and are free to do so.

@riastradh-probcomp thank you for clearly explaining the security concern. I would think that, given that the design decision has been made to ask for this communication, you would want people to communicate safely. Continuing to raise and reraise the objection, despite decisions above having taken your concerns into account, and seemingly not understanding the bigger picture that we would like to have users' sessions, with their explicit consent, to make our software better, ... it's kind of annoying, and becomes counterproductive because we merely learn to tune you out. Please give it a rest?