Re: [Python-Dev] 3.5 release schedule PEP
On 9/26/2014 1:03 PM, Chris Barker wrote: On Thu, Sep 25, 2014 at 5:38 PM, Donald Stufft mailto:don...@stufft.io>> wrote: 2) Switch to —user based on if the user has permission to write to the site-packages or not. ouch -- no. Why not a clear error message if pip can't write to site-packages -- something like: I fairly strongly believe that the current default is doing a great disservice to users. I believe that for *most* people --user is the correct option for them to be using and the fact that it's not the default and requires opt in is a historical artifact more than anything else. OK -- fine -- I think that history may be important -- at least for Py2, but I agree that --user is a better default. But what I'm objecting to is is switching the install mode based on the permissions that the user happens to be running with at the time. None of us should be routinely running as admin. So what I do (and I image a LOT of people do) is try to do whatever I need to do, and only if I get an error to I switch to admin mode (or add sudo, or ???). What I'm suggesting is that folks that simply expect stuff to get installed into the usual system python is not thinking ahead of time "oh, I need be admin for this", but rather, simply do it, and then, if you get a permission error, make the switch to either admin in mode, or add --user. If we do switch the default to --user, then this issue goes away. In short -- too much magic is bad. Pip on Windows should act like a normal Windows program. If I install Python for all users, I expect pipped packages to be installed for all users too, unless I specify otherwise. If installation (for all users) requires admin privileges, I expect a UAC box to pop up and ask for the admin password. This is pretty routine, at least with Win7. Most every program I install does this either on installation or on first running. Some Windows operations also pop up a box. There are only a few things that require that I actually login as an admin user. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 release schedule PEP
On Thu, Sep 25, 2014 at 5:38 PM, Donald Stufft wrote: > 2) Switch to —user based on if the user has permission to write to the >> site-packages or not. >> > > ouch -- no. Why not a clear error message if pip can't write to > site-packages -- something like: > > I fairly strongly believe that the current default is doing a great > disservice > to users. I believe that for *most* people --user is the correct option for > them to be using and the fact that it's not the default and requires opt in > is a historical artifact more than anything else. > OK -- fine -- I think that history may be important -- at least for Py2, but I agree that --user is a better default. But what I'm objecting to is is switching the install mode based on the permissions that the user happens to be running with at the time. None of us should be routinely running as admin. So what I do (and I image a LOT of people do) is try to do whatever I need to do, and only if I get an error to I switch to admin mode (or add sudo, or ???). What I'm suggesting is that folks that simply expect stuff to get installed into the usual system python is not thinking ahead of time "oh, I need be admin for this", but rather, simply do it, and then, if you get a permission error, make the switch to either admin in mode, or add --user. If we do switch the default to --user, then this issue goes away. In short -- too much magic is bad. All this is also making me think that virtualenv and friends is the real solution to user installed packages anyway. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On 26Sep2014 13:16, Antoine Pitrou wrote: On Fri, 26 Sep 2014 01:10:53 -0700 Hasan Diwan wrote: On 26 September 2014 00:28, Matěj Cepl wrote: > Where does your faith that other /bin/sh implementations (dash, > busybox, etc.) are less buggy comes from? The fact that they are simpler, in terms of lines of code. It's no guarantee, but the less a given piece of code does, the less bugs it will have. -- H And that they have less "features" (which is certainly correlated to their simplicity). IIUC, the misimplemented feature leading to this vulnerability is a bash-ism. IIRC you could export functions in ksh. Or maybe only aliases. But that implies most POSIX shells may support it. I've never seen the point myself; it is not a feature I've ever needed. Cheers, Cameron Simpson Follow! But! Follow only if ye be men of valor, for the entrance to this cave is guarded by a creature so foul, so cruel that no man yet has fought with it and lived! Bones of four fifty men lie strewn about its lair. So, brave knights, if you do doubt your courage or your strength, come no further, for death awaits you all with nasty big pointy teeth. - Tim The Enchanter ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7
On 26 September 2014 19:01, Steve Dower wrote: > Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). > We've produced this package to help library developers build wheels for > Windows, but also to help users unblock themselves when they need to build C > extensions themselves. > > The Microsoft Visual C++ Compiler for Python 2.7 is available from: > http://aka.ms/vcpython27 That is fantastic news! Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7
On 09/26/2014 11:01 AM, Steve Dower wrote: Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves. That's gorgeous! //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7
At long last! Building C extensions on Windows will no longer be a pain in the rear! On Fri, Sep 26, 2014 at 1:01 PM, Steve Dower wrote: > Hi all, > > (This is advance notice since people on this list will be interested. > Official announcements are coming when setuptools makes their next release.) > > Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). > We've produced this package to help library developers build wheels for > Windows, but also to help users unblock themselves when they need to build > C extensions themselves. > > The Microsoft Visual C++ Compiler for Python 2.7 is available from: > http://aka.ms/vcpython27 > > This package contains all the tools and headers required to build C > extension modules for Python 2.7 32-bit and 64-bit (note that some > extension modules require 3rd party dependencies such as OpenSSL or libxml2 > that are not included). Other versions of Python built with Visual C++ 2008 > are also supported. > > You can install the package without requiring administrative privileges > and, with the latest version of setuptools (when it releases), use tools > such as pip, wheel, or a setup.py file to produce binaries on Windows. > > Unfortunately, this package isn't necessarily going to help with building > CPython 2.7 itself, as the build process is complicated and Visual Studio > 2008 is practically required. However, as most people aren't building > CPython on Windows, this isn't a huge issue. This compiler package should > be sufficient for most extension modules. > > I should also point out that VC9 is no longer supported by Microsoft. This > means there won't be any improvements or bug fixes coming, and there's no > official support offered. Feel free to contact me directly < > steve.do...@microsoft.com> if there are issues with the package. > > Cheers, > Steve > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
T-Mobile. America's First Nationwide 4G Network. -- Original message--From: Python trackerDate: Fri, Sep 26, 2014 12:07 PMTo: python-dev@python.org;Subject:[Python-Dev] Summary of Python tracker IssuesACTIVITY SUMMARY (2014-09-19 - 2014-09-26)Python tracker at http://bugs.python.org/To view or respond to any of the issues listed below, click on the issue.Do NOT respond to this message.Issues counts and deltas: open4677 (+15) closed 29587 (+43) total 34264 (+58)Open issues with patches: 2197 Issues opened (39)==#22444: Floor divide should return inthttp://bugs.python.org/issue22444 opened by belopolsky#22445: Memoryviews require more strict contiguous checks then necessahttp://bugs.python.org/issue22445 opened by seberg#22449: SSLContext.load_verify_locations behavior on Windows and OSXhttp://bugs.python.org/issue22449 opened by christian.heimes#22450: urllib doesn't put Accept: */* in the headershttp://bugs.python.org/issue22450 opened by rhettinger#22452: addTypeEqualityFunc is not used in assertListEqualhttp://bugs.python.org/issue22452 opened by simonzack#22453: PyObject_REPR macro causes refcount leakhttp://bugs.python.org/issue22453 opened by Chris.Colbert#22454: Adding the opposite function of shlex.split()http://bugs.python.org/issue22454 opened by Sworddragon#22455: idna/punycode give wrong results on narrow buildshttp://bugs.python.org/issue22455 opened by bukzor#22456: __base__ undocumentedhttp://bugs.python.org/issue22456 opened by Arfrever#22457: load_tests not invoked in root __init__.py when start=package http://bugs.python.org/issue22457 opened by rbcollins#22458: Add fractions benchmarkhttp://bugs.python.org/issue22458 opened by scoder#22460: idle editor: replace all in selectionhttp://bugs.python.org/issue22460 opened by bagratte#22462: Modules/pyexpat.c violates PEP 384http://bugs.python.org/issue22462 opened by Mark.Shannon#22463: Warnings when building on AIXhttp://bugs.python.org/issue22463 opened by jelie#22465: Number agreement error in section 3.2 of web docshttp://bugs.python.org/issue22465 opened by pauamma#22466: problem with installing python 2.7.8http://bugs.python.org/issue22466 opened by elctr0#22468: Tarfile using fstat on GZip file objecthttp://bugs.python.org/issue22468 opened by bartolsthoorn#22470: Possible integer overflow in error handlershttp://bugs.python.org/issue22470 opened by serhiy.storchaka#22472: OSErrors should use str and not repr on pathshttp://bugs.python.org/issue22472 opened by r.david.murray#22473: The gloss on asyncio "future with run_forever" example is confhttp://bugs.python.org/issue22473 opened by r.david.murray#22474: No explanation of how a task gets destroyed in asyncio 'task' http://bugs.python.org/issue22474 opened by r.david.murray#22475: asyncio task get_stack documentation seems to contradict itselhttp://bugs.python.org/issue22475 opened by r.david.murray#22476: asyncio task chapter confusion about 'task', 'future', and 'schttp://bugs.python.org/issue22476 opened by r.david.murray#22477: GCD in Fractionshttp://bugs.python.org/issue22477 opened by b...@gladman.plus.com#22480: SystemExit out of run_until_complete causes AttributeError whehttp://bugs.python.org/issue22480 opened by chrysn#22482: logging: fileConfig doesn't support formatter styleshttp://bugs.python.org/issue22482 opened by domzippilli#22486: Add math.gcd()http://bugs.python.org/issue22486 opened by scoder#22489: .gitignore filehttp://bugs.python.org/issue22489 opened by rbcollins#22490: Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installshttp://bugs.python.org/issue22490 opened by tdsmith#22491: Support Unicode line boundaries in regular expressionhttp://bugs.python.org/issue22491 opened by serhiy.storchaka#22492: small addition to print() docs: no binary streams.http://bugs.python.org/issue22492 opened by georg.brandl#22493: Deprecate the use of flags not at the start of regular expresshttp://bugs.python.org/issue22493 opened by serhiy.storchaka#22494: default logging time string is not localizedhttp://bugs.python.org/issue22494 opened by sdague#22495: merge large parts of test_binop.py and test_fractions.pyhttp://bugs.python.org/issue22495 opened by wolma#22496: urllib2 fails against IIS (urllib2 can't parse 401 reply www-ahttp://bugs.python.org/issue22496 opened by deronnax#22497: msiexec not creating msvcr90.dll with python -2.7.6.msihttp://bugs.python.org/issue22497 opened by dykesk#22499: [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636http://bugs.python.org/issue22499 opened by nikratio#22500: Argparse always stores True for positional argumentshttp://bugs.python.org/issue22500 opened by Tristan.Fisher#22501: Optimise PyLong division by 1 or -1http://bugs.python.org/issue22501 opened by scoderMost recent 15 issues with no replies (15)==#22495: merge large parts of
Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7
On 26/09/2014 19:01, Steve Dower wrote: Hi all, (This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.) Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves. The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27 Wow. I am lost for words. TJG ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7
Awesome! > On Sep 26, 2014, at 2:01 PM, Steve Dower wrote: > > Hi all, > > (This is advance notice since people on this list will be interested. > Official announcements are coming when setuptools makes their next release.) > > Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). > We've produced this package to help library developers build wheels for > Windows, but also to help users unblock themselves when they need to build C > extensions themselves. > > The Microsoft Visual C++ Compiler for Python 2.7 is available from: > http://aka.ms/vcpython27 > > This package contains all the tools and headers required to build C extension > modules for Python 2.7 32-bit and 64-bit (note that some extension modules > require 3rd party dependencies such as OpenSSL or libxml2 that are not > included). Other versions of Python built with Visual C++ 2008 are also > supported. > > You can install the package without requiring administrative privileges and, > with the latest version of setuptools (when it releases), use tools such as > pip, wheel, or a setup.py file to produce binaries on Windows. > > Unfortunately, this package isn't necessarily going to help with building > CPython 2.7 itself, as the build process is complicated and Visual Studio > 2008 is practically required. However, as most people aren't building CPython > on Windows, this isn't a huge issue. This compiler package should be > sufficient for most extension modules. > > I should also point out that VC9 is no longer supported by Microsoft. This > means there won't be any improvements or bug fixes coming, and there's no > official support offered. Feel free to contact me directly > if there are issues with the package. > > Cheers, > Steve > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Microsoft Visual C++ Compiler for Python 2.7
Hi all, (This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.) Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build wheels for Windows, but also to help users unblock themselves when they need to build C extensions themselves. The Microsoft Visual C++ Compiler for Python 2.7 is available from: http://aka.ms/vcpython27 This package contains all the tools and headers required to build C extension modules for Python 2.7 32-bit and 64-bit (note that some extension modules require 3rd party dependencies such as OpenSSL or libxml2 that are not included). Other versions of Python built with Visual C++ 2008 are also supported. You can install the package without requiring administrative privileges and, with the latest version of setuptools (when it releases), use tools such as pip, wheel, or a setup.py file to produce binaries on Windows. Unfortunately, this package isn't necessarily going to help with building CPython 2.7 itself, as the build process is complicated and Visual Studio 2008 is practically required. However, as most people aren't building CPython on Windows, this isn't a huge issue. This compiler package should be sufficient for most extension modules. I should also point out that VC9 is no longer supported by Microsoft. This means there won't be any improvements or bug fixes coming, and there's no official support offered. Feel free to contact me directly if there are issues with the package. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-09-19 - 2014-09-26) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4677 (+15) closed 29587 (+43) total 34264 (+58) Open issues with patches: 2197 Issues opened (39) == #22444: Floor divide should return int http://bugs.python.org/issue22444 opened by belopolsky #22445: Memoryviews require more strict contiguous checks then necessa http://bugs.python.org/issue22445 opened by seberg #22449: SSLContext.load_verify_locations behavior on Windows and OSX http://bugs.python.org/issue22449 opened by christian.heimes #22450: urllib doesn't put Accept: */* in the headers http://bugs.python.org/issue22450 opened by rhettinger #22452: addTypeEqualityFunc is not used in assertListEqual http://bugs.python.org/issue22452 opened by simonzack #22453: PyObject_REPR macro causes refcount leak http://bugs.python.org/issue22453 opened by Chris.Colbert #22454: Adding the opposite function of shlex.split() http://bugs.python.org/issue22454 opened by Sworddragon #22455: idna/punycode give wrong results on narrow builds http://bugs.python.org/issue22455 opened by bukzor #22456: __base__ undocumented http://bugs.python.org/issue22456 opened by Arfrever #22457: load_tests not invoked in root __init__.py when start=package http://bugs.python.org/issue22457 opened by rbcollins #22458: Add fractions benchmark http://bugs.python.org/issue22458 opened by scoder #22460: idle editor: replace all in selection http://bugs.python.org/issue22460 opened by bagratte #22462: Modules/pyexpat.c violates PEP 384 http://bugs.python.org/issue22462 opened by Mark.Shannon #22463: Warnings when building on AIX http://bugs.python.org/issue22463 opened by jelie #22465: Number agreement error in section 3.2 of web docs http://bugs.python.org/issue22465 opened by pauamma #22466: problem with installing python 2.7.8 http://bugs.python.org/issue22466 opened by elctr0 #22468: Tarfile using fstat on GZip file object http://bugs.python.org/issue22468 opened by bartolsthoorn #22470: Possible integer overflow in error handlers http://bugs.python.org/issue22470 opened by serhiy.storchaka #22472: OSErrors should use str and not repr on paths http://bugs.python.org/issue22472 opened by r.david.murray #22473: The gloss on asyncio "future with run_forever" example is conf http://bugs.python.org/issue22473 opened by r.david.murray #22474: No explanation of how a task gets destroyed in asyncio 'task' http://bugs.python.org/issue22474 opened by r.david.murray #22475: asyncio task get_stack documentation seems to contradict itsel http://bugs.python.org/issue22475 opened by r.david.murray #22476: asyncio task chapter confusion about 'task', 'future', and 'sc http://bugs.python.org/issue22476 opened by r.david.murray #22477: GCD in Fractions http://bugs.python.org/issue22477 opened by b...@gladman.plus.com #22480: SystemExit out of run_until_complete causes AttributeError whe http://bugs.python.org/issue22480 opened by chrysn #22482: logging: fileConfig doesn't support formatter styles http://bugs.python.org/issue22482 opened by domzippilli #22486: Add math.gcd() http://bugs.python.org/issue22486 opened by scoder #22489: .gitignore file http://bugs.python.org/issue22489 opened by rbcollins #22490: Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs http://bugs.python.org/issue22490 opened by tdsmith #22491: Support Unicode line boundaries in regular expression http://bugs.python.org/issue22491 opened by serhiy.storchaka #22492: small addition to print() docs: no binary streams. http://bugs.python.org/issue22492 opened by georg.brandl #22493: Deprecate the use of flags not at the start of regular express http://bugs.python.org/issue22493 opened by serhiy.storchaka #22494: default logging time string is not localized http://bugs.python.org/issue22494 opened by sdague #22495: merge large parts of test_binop.py and test_fractions.py http://bugs.python.org/issue22495 opened by wolma #22496: urllib2 fails against IIS (urllib2 can't parse 401 reply www-a http://bugs.python.org/issue22496 opened by deronnax #22497: msiexec not creating msvcr90.dll with python -2.7.6.msi http://bugs.python.org/issue22497 opened by dykesk #22499: [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636 http://bugs.python.org/issue22499 opened by nikratio #22500: Argparse always stores True for positional arguments http://bugs.python.org/issue22500 opened by Tristan.Fisher #22501: Optimise PyLong division by 1 or -1 http://bugs.python.org/issue22501 opened by scoder Most recent 15 issues with no replies (15) == #22495: merge large parts of test_binop.py and test_fractions.py http://bugs.python.org/issue22495 #22494: default logging time string is not localized http://bugs.python.org/issue
Re: [Python-Dev] 3.5 release schedule PEP
> On Sep 26, 2014, at 9:53 AM, Paul Moore wrote: > > On 26 September 2014 14:31, Donald Stufft wrote: >> Yea, I think we throw an error when you use —user inside a virtual >>environment. > > So if --user became the default, what would happen? I'd like pip > inside a virtualenv to install into the environment without needing a > --system flag. Is that the intention? > > Paul default = “—user” if not running_inside_virtualenv() else “—system" --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 release schedule PEP
On 26 September 2014 14:31, Donald Stufft wrote: > Yea, I think we throw an error when you use —user inside a virtual > environment. So if --user became the default, what would happen? I'd like pip inside a virtualenv to install into the environment without needing a --system flag. Is that the intention? Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
Stefan Behnel wrote: > Ok, but does that really make it a relevant topic for python-dev? Sorry - I thought I was reading python-general. gmane makes it too easy to post :-). However, I think it's worth pointing that out, in case people think that Popen is a security panacea. J ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 release schedule PEP
> On Sep 26, 2014, at 3:09 AM, Paul Moore wrote: > > On 26 September 2014 01:38, Donald Stufft wrote: >> Either way I'm fairly commited to making --user the default, the only >> question >> on my mind is what exactly does that look like (e.g. does root get --user by >> default?) and how we get from where we are now to that point. I think that >> raising an error here is fairly unfriendly when we can know with pretty good >> certainity what the user wanted (and they can explicitly declare that if >> they want too). > > A couple of points come to mind (although they may be more suitable > for distutils-sig). > > 1. Do user installs "leak" into virtualenvs? If so, then in effect > --use-system-packages is switched back on again if --user installs > become the norm. Which is almost certainly not what is wanted. > 2. pip install should default to not being --user when run from within > a virtualenv (same logic as the isolated Python case, but much more > important that behaviour remains as now, because the whole *point* of > virtualenvs is to isolate). > > Note that both of these points apply both to venv and virtualenvs. 1. No they don’t leak as far as I’m aware. 2. Yea, I think we throw an error when you use —user inside a virtual environment. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On Fri, 26 Sep 2014 14:56:05 +0200 Stefan Behnel wrote: > Jeremy Sanders schrieb am 26.09.2014 um 09:28: > > Antoine Pitrou wrote: > > > >> Fortunately, Python's subprocess has its `shell` argument default to > >> False. However, `os.system` invokes the shell implicitly and is > >> therefore a possible attack vector. > > > > Of course anything called by subprocess with shell=False may invoke the > > shell itself if it runs other processes. > > Ok, but does that really make it a relevant topic for python-dev? No. I don't know why the OP posted here. (but we have all kinds of borderline discussion threads these days, and people don't seem to care when they are asked to move the discussion elsewhere, so...) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
Jeremy Sanders schrieb am 26.09.2014 um 09:28: > Antoine Pitrou wrote: > >> Fortunately, Python's subprocess has its `shell` argument default to >> False. However, `os.system` invokes the shell implicitly and is >> therefore a possible attack vector. > > Of course anything called by subprocess with shell=False may invoke the > shell itself if it runs other processes. Ok, but does that really make it a relevant topic for python-dev? Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On Fri, 26 Sep 2014 01:10:53 -0700 Hasan Diwan wrote: > Matěj, > > On 26 September 2014 00:28, Matěj Cepl wrote: > > > Where does your faith that other /bin/sh implementations (dash, > > busybox, etc.) are less buggy comes from? > > > The fact that they are simpler, in terms of lines of code. It's no > guarantee, but the less a given piece of code does, the less bugs it will > have. -- H And that they have less "features" (which is certainly correlated to their simplicity). IIUC, the misimplemented feature leading to this vulnerability is a bash-ism. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On 26.09.14 01:17, Antoine Pitrou wrote:
Fortunately, Python's subprocess has its `shell` argument default to
False. However, `os.system` invokes the shell implicitly and is
therefore a possible attack vector.
Fortunately dash (which is used as /bin/sh in Debian and Ubuntu) is not
vulnerable.
$ x='() { :;}; echo gotcha' ./python -c 'import os; os.system("echo do
something useful")'
do something useful
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
Matěj, On 26 September 2014 00:28, Matěj Cepl wrote: > Where does your faith that other /bin/sh implementations (dash, > busybox, etc.) are less buggy comes from? The fact that they are simpler, in terms of lines of code. It's no guarantee, but the less a given piece of code does, the less bugs it will have. -- H -- OpenPGP: https://hasan.d8u.us/gpg.key Sent from my mobile device Envoyé de mon portable ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
On 2014-09-25, 23:14 GMT, Cameron Simpson wrote: >>Fortunately, Python's subprocess has its `shell` argument default to >>False. However, `os.system` invokes the shell implicitly and is >>therefore a possible attack vector. > > Only if /bin/sh is bash :-) Not always the case, fortunately. Where does your faith that other /bin/sh implementations (dash, busybox, etc.) are less buggy comes from? On the contrary, bash being the most used, beaten, patched, and studied of them all has plenty of arguments to claim to be the most secure /bin/sh implementation around. You just don't know about those other guys bugs. No reason to believe hackers don't know about them either. Matěj ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX
Antoine Pitrou wrote: > Fortunately, Python's subprocess has its `shell` argument default to > False. However, `os.system` invokes the shell implicitly and is > therefore a possible attack vector. Of course anything called by subprocess with shell=False may invoke the shell itself if it runs other processes. Jeremy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 release schedule PEP
On 26 September 2014 01:38, Donald Stufft wrote: > Either way I'm fairly commited to making --user the default, the only > question > on my mind is what exactly does that look like (e.g. does root get --user by > default?) and how we get from where we are now to that point. I think that > raising an error here is fairly unfriendly when we can know with pretty good > certainity what the user wanted (and they can explicitly declare that if > they want too). A couple of points come to mind (although they may be more suitable for distutils-sig). 1. Do user installs "leak" into virtualenvs? If so, then in effect --use-system-packages is switched back on again if --user installs become the norm. Which is almost certainly not what is wanted. 2. pip install should default to not being --user when run from within a virtualenv (same logic as the isolated Python case, but much more important that behaviour remains as now, because the whole *point* of virtualenvs is to isolate). Note that both of these points apply both to venv and virtualenvs. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
