Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

Steven D'Aprano : > Perhaps I'm missing something, but aren't there easier ways to attack > os.system than the bash env vulnerability? The main concern is the cases where you provide a service accessible through an SSH login and try to sandbox the client with limited functionality. SSH passes so

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On 25Sep2014 21:30, Tres Seaver wrote: On 09/25/2014 08:59 PM, Cameron Simpson wrote: Your cable/adsl modem? Probably an embedded Linux box, possibly using bash, and certainly a dhcp client of the ISP. Better still, for many people that same comprimisable modem is the DHCP _server_ for their ho

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/25/2014 08:59 PM, Cameron Simpson wrote: > Your cable/adsl modem? Probably an embedded Linux box, possibly using > bash, and certainly a dhcp client of the ISP. Better still, for many > people that same comprimisable modem is the DHCP _server_ fo

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On 26Sep2014 09:40, Steven D'Aprano wrote: On Fri, Sep 26, 2014 at 12:17:46AM +0200, Antoine Pitrou wrote: On Thu, 25 Sep 2014 13:00:16 -0700 Bob Hanson wrote: > Critical bash vulnerability CVE-2014-6271 may affect Python on > *n*x and OSX: [...] See also: http://adminlogs.info/2014/09/25/ag

Re: [Python-Dev] 3.5 release schedule PEP

> On Sep 25, 2014, at 6:44 PM, Chris Barker wrote: > > On Thu, Sep 25, 2014 at 9:00 AM, Donald Stufft > wrote: > 1) Just always default to —user and add a —system or similar flag, this > is super easy to change but is a backwards incompatible change and > would

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, Sep 26, 2014 at 10:29 AM, Devin Jeanpierre wrote: > As I understand it, if the attacker can help specify the environment > (e.g. this is a CGI script), and you run os.system('echo hi'), you can > get pwned. Even safe uses of os.system are vulnerable unless you point > /bin/sh at a secure s

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Thu, Sep 25, 2014 at 4:53 PM, Antoine Pitrou wrote: >> In other words, os.system is *already* an attack vector, unless you only >> use it with trusted strings. I don't think the bash env vulnerability >> adds to the attack surface. >> >> Have I missed something? > > The part where the attack pa

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, Sep 26, 2014 at 9:53 AM, Antoine Pitrou wrote: >> In other words, os.system is *already* an attack vector, unless you only >> use it with trusted strings. I don't think the bash env vulnerability >> adds to the attack surface. >> >> Have I missed something? > > The part where the attack pa

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

> The part where the attack payload is passed through the environment, not through hypothetical user-injected command-line arguments. So, best advice would be to: 1. Upgrade bash (and standby for an additional patch, according to reddit) 2. Upgrade to WSGI, if possible 3. Be careful about includi

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, 26 Sep 2014 09:40:17 +1000 Steven D'Aprano wrote: > Perhaps I'm missing something, but aren't there easier ways to attack > os.system than the bash env vulnerability? If I'm accepting and running > arbitrary strings from an untrusted user, there's no need for them to go > to the trouble

Re: [Python-Dev] 3.5 release schedule PEP

On Thu, Sep 25, 2014 at 9:00 AM, Donald Stufft wrote: > 1) Just always default to —user and add a —system or similar flag, this > is super easy to change but is a backwards incompatible change and > would need to go through a deprecation window. > Maybe would have been the way to go to b

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Fri, Sep 26, 2014 at 12:17:46AM +0200, Antoine Pitrou wrote: > On Thu, 25 Sep 2014 13:00:16 -0700 > Bob Hanson wrote: > > Critical bash vulnerability CVE-2014-6271 may affect Python on > > *n*x and OSX: [...] See also: http://adminlogs.info/2014/09/25/again-bash-cve-2014-7169/ > Fortunately

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On 26Sep2014 00:17, Antoine Pitrou wrote: On Thu, 25 Sep 2014 13:00:16 -0700 Bob Hanson wrote: Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX: [...] Fortunately, Python's subprocess has its `shell` a

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

This was helpful: http://sarge.readthedocs.org/en/latest/internals.html#how-shell-quoting-works -- Wes Turner On Thu, Sep 25, 2014 at 5:17 PM, Antoine Pitrou wrote: > On Thu, 25 Sep 2014 13:00:16 -0700 > Bob Hanson wrote: >> Critical bash vulnerability CVE-2014-6271 may affect Python on >> *n*x

Re: [Python-Dev] 3.5 release schedule PEP

On 26 Sep 2014 01:56, "Paul Moore" wrote: > > Basically, I'd like to hold off moving to "Program Files" as a default > until *after* we have enough confidence in user installs that we are > willing to switch pip to --user as the default behaviour everywhere. > And yes, I'm aware that the first "we

Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

On Thu, 25 Sep 2014 13:00:16 -0700 Bob Hanson wrote: > Critical bash vulnerability CVE-2014-6271 may affect Python on > *n*x and OSX: > > > >

[Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX:

Re: [Python-Dev] 3.5 release schedule PEP

On 09/24/2014 09:11 PM, Larry Hastings wrote: Therefore: if VC14 doesn't ship by 3.5 RC1, currently set at August 5, 2015, I decree we have to ship 3.5 with the previous version. Reasonable? Seems reasonable to me. -- ~Ethan~ ___ Python-Dev mailin

Re: [Python-Dev] 3.5 release schedule PEP

Am 24.09.14 14:34, schrieb Antoine Pitrou: > On Wed, 24 Sep 2014 17:12:35 +1000 > Nick Coghlan wrote: >> On 24 Sep 2014 15:15, "Tim Golden" wrote: >>> >>> On 23/09/2014 18:05, Steve Dower wrote: I'm also considering/experimenting with installing into "Program Files" by default, but

Re: [Python-Dev] 3.5 release schedule PEP

On 25 September 2014 18:13, Steve Dower wrote: > Again, this isn't trivial to get right. The design for the elevation model > seems to have focused mainly on GUI rather than console, probably assuming > that people who need to elevate from the console will elevate the shell > itself (this is a

Re: [Python-Dev] 3.5 release schedule PEP

> Paul Moore wrote: > On 25 September 2014 17:05, Steve Dower wrote: >> So yes, pip can certainly do this, and if it's already running >> elevated then it shouldn't reprompt, but it's not entirely trivial to >> get this right ("are you denied write access to that directory because >> you're not ad

Re: [Python-Dev] 3.5 release schedule PEP

On 25 September 2014 17:05, Steve Dower wrote: > So yes, pip can certainly do this, and if it's already running elevated then > it shouldn't reprompt, but it's not entirely trivial to get this right ("are > you denied write access to that directory because you're not admin or because > it's on

Re: [Python-Dev] 3.5 release schedule PEP

Chris Angelico wrote: > On Thu, Sep 25, 2014 at 6:50 AM, Steve Dower > wrote: >> Donald Stufft wrote: >>> One thing about *nix is even though you can’t write to your normal >>> Python install location without root, invoking pip with permissions >>> (assuming you have >>> them) is as easy as prefa

Re: [Python-Dev] 3.5 release schedule PEP

> On Sep 25, 2014, at 11:54 AM, Paul Moore wrote: > > On 25 September 2014 16:43, Donald Stufft wrote: >> Basically people have Python in a ton of different configurations and it’s >> hard to figure out if —user will work out of the box in all of them or not. > > I guess that "Using the python

Re: [Python-Dev] 3.5 release schedule PEP

On 25 September 2014 16:43, Donald Stufft wrote: > Basically people have Python in a ton of different configurations and it’s > hard to figure out if —user will work out of the box in all of them or not. I guess that "Using the python.org Python installer on Windows" is a limited enough subset th

Re: [Python-Dev] 3.5 release schedule PEP

> On Sep 25, 2014, at 4:54 AM, Antoine Pitrou wrote: > > On Thu, 25 Sep 2014 07:34:31 +0100 > Paul Moore wrote: >> On 25 September 2014 02:08, Antoine Pitrou wrote: Indeed. Moving towards having --user as the norm is definitely something we want to look at for pip. One of the biggest

Re: [Python-Dev] 3.5 release schedule PEP

On 24 September 2014 23:16, Mike Miller wrote: > Hi all, > > ProgramFiles was the default in Python 1.X. > > It has been a supported option for just shy of 15 years on 2.X... most if > not all the bugs (setuptools) were fixed a decade ago, and right now > thousands, if not millions of people are

Re: [Python-Dev] 3.5 release schedule PEP

Le 25/09/2014 09:22, INADA Naoki a écrit : > FYI, homebrew's Python uses prefix option, so I can't use `--user`. > Is it a bug? > > $ /usr/local/bin/pip -V > pip 1.5.6 from > /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg

Re: [Python-Dev] 3.5 release schedule PEP

On Thu, 25 Sep 2014 07:34:31 +0100 Paul Moore wrote: > On 25 September 2014 02:08, Antoine Pitrou wrote: > >> Indeed. Moving towards having --user as the norm is definitely > >> something we want to look at for pip. One of the biggest concerns is > >> how well-exercised the whole user site direct

Re: [Python-Dev] 3.5 release schedule PEP

FYI, homebrew's Python uses prefix option, so I can't use `--user`. Is it a bug? $ /usr/local/bin/pip -V pip 1.5.6 from /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg (python 2.7) $ /usr/local/bin/pip install --user torna