On Thu, Feb 28, 2019 at 4:53 PM Jeroen Demeyer <j.deme...@ugent.be> wrote: > > Since many years, we have patched the Python in Sage with a patch to > mitigate some security issues related to sys.path. > > The security issue is the following: if you run a Python script from a > world-writable directory, say a script like /tmp/foo.py this is very > insecure since Python will add /tmp as first entry in sys.path. So if > the script starts with from __future__ import absolute_import (say) and > some evil person creates /tmp/__future__.py then you'll run that code. > > We added a patch for this in Sage in > https://trac.sagemath.org/ticket/13579 and also reported this upstream > to CPython at https://bugs.python.org/issue16202 > > As expected, upstream was not impressed by our patch because it would > break backwards compatibility. But we never really tried to discuss it > seriously with upstream. If anybody wants to go for that, please do. I > won't do this, I've already picked different battles with CPython. > > As a side remark, let me mention that Perl also had this issue but they > fixed it, the current directory is no longer in the include path: > https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-%28%22.%22%29-from-@INC > > I noticed at Trac #27001 that we don't have this patch in Python 3. The > question is: should we? It makes little sense to have it for Python 2 > and not for Python 3. So either we drop it from Python 2 or we port it > to Python 3. The ideal situation would be that it gets accepted > upstream, but for the sake of argument, let's assume that it doesn't get > accepted. What should we do then?
I suggest a middle ground: I don't believe this behavior should be tested in Sage's test suite, because this is a question about the Python interpreter's behavior, not Sage. The possibility of running Sage on a Python interpreter provided by the system, which does not have this patch, means the behavior here cannot be controlled for. So I think if you want to include this patch in Sage, the patch should include patches to Python's own test suite (as would be needed in any case to have any chance of getting it upstream) so that it can be checked when building Sage's Python SPKG with SAGE_CHECK=yes. Otherwise, I don't think the Sage test suite has any business testing this. I don't care about porting the patch to Python 3 either. Though if someone did, and raised the issue on python-dev, I think there's not a terrible chance of getting this accepted. Yes, it would break some backwards compatibility, but for a use case that isn't very strong in the first place. So I could see something like that getting accepted in a future Python 3.x release (and likely never for Python 2.7, though you could make an argument for it with various distros if it's something you're passionate about :) By "you" here I mean anyone reading btw, not just Jeroen. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
