Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 13.08, André Malo wrote: > On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote: >> NNTP is still quite used (often through GMane, but probably not only) so >> I'd question the removal of nntplib. >> >> cgitb used to be used by some Web frameworks in order to format >> exception

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 13.50, Victor Stinner wrote: > Hi Christian, > > I dislike the PEP 594 title: "Removing dead batteries from the > standard library". A module is never "dead", there are always users, > even if there are less than 5 of them. I'm open for suggestions for a better title. > Extract of

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 14.06, Anders Munch wrote: > Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På > vegne af Christian Heimes >> * The removed modules will be available through PyPI. > > Will they? That's not the impression I got from the PEP. It

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 15.01, Steven D'Aprano wrote: > Christian, I'm glad that you are privileged enough to find it simple and > straight forward to download and install, but for many Python users, it > is not so simple or straight forward. > > Many Python users don't have the privilege of being able to

[Python-Dev] PEP 594: update 1

ndard library Author: Christian Heimes Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 20-May-2019 Post-History: 21-May-2019 Abstract This PEP proposed a list of standard library modules to be removed from the standard library. The modules are mostly historic data fo

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 15.54, Victor Stinner wrote: > IMHO we should simply acknowledge this fact by mentioning it in the > PEP. We are aware that "pip install" is not always a valid option, but > we decided anyway to deprecate/remove modules because <...>. I like the idea. Could you create an issue or PR,

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 17.35, Guido van Rossum wrote: > OK, sounds like nntplib can stay — this time.  > > On Tue, May 21, 2019 at 08:33 Antoine Pitrou > wrote: > > > As I said, if the main annoyance with nntplib is the sporadic test > failures, then the relevant test

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 17.31, Antoine Pitrou wrote: > > As I said, if the main annoyance with nntplib is the sporadic test > failures, then the relevant tests can be disabled on CI. > > NNTP itself is still used, even if less and less. I don't like the idea to drop a third of the test cases for nntplib -

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 21:13, Christian Heimes <mailto:christ...@python.org>> wrote: > > crypt > ~ > > The `crypt <https://docs.python.org/3/library/crypt.html>`_ module > imple

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 21:13, Christian Heimes <mailto:christ...@python.org>> wrote: > > crypt > ~ > > The `crypt <https://docs.python.org/3/library/crypt.html>`_ module > imple

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 18.29, Glenn Linderman wrote: > On 5/20/2019 2:20 PM, Christian Heimes wrote: >> On 20/05/2019 23.12, Andrew Svetlov wrote: >>> socketserver.py is also questionable >> I briefly though about the module, but didn't consider it for removal. The >&

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 16.46, Guido van Rossum wrote: > +1. Let's keep colorsys then. I let colorsys off the hock, https://github.com/python/peps/pull/1070 Thanks for your feedback, Walter and Petr! Christian ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 20.18, Giampaolo Rodola' wrote: > No, the statement is correct. I may have to explain this even further. > > The approach in pyftpdlib is the wrong and IMO deserves a CVE. The > crypt() + spwd() approach is flawed on multiple levels. For example it > bypasses account restri

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 20.35, Guido van Rossum wrote: > On Tue, May 21, 2019 at 11:17 AM Christian Heimes <mailto:christ...@python.org>> wrote: > > I'm already facing opposition for modules that are less controversial and > useful than http.server, too. > > > The

Re: [Python-Dev] Python in next Windows 10 update

On 21/05/2019 22.30, Steve Dower wrote: > Hi all > > Just sharing this here because I think it's important for us to be aware of > it - I'm not trying to promote or sell anything here :) (Those who were at > the language summit have seen this already.) > > In the next Windows 10 update that sta

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 06.20, Arfrever Frehtes Taifersar Arahesis wrote: > 2019-05-21 00:06 UTC+02:00, Christian Heimes wrote: >> On 20/05/2019 23.27, Antoine Pitrou wrote: >>> Removing the crypt module would remove support for system-standard >>> password files. I don

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 08.30, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 04:30, Antoine Pitrou > wrote: > > > NNTP is still quite used (often through GMane, but probably not only) so > I'd question the removal of nntplib. > > > I concur nntplib should be

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 01.11, Glenn Linderman wrote: > On 5/21/2019 2:00 PM, Nathaniel Smith wrote: >> On Tue, May 21, 2019 at 10:43 AM Glenn Linderman >> wrote: >>> After maintaining my own version of http.server to fix or workaround some >>> of its deficiencies for some years, I discovered bottle.py. I

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 12.19, Steven D'Aprano wrote: > I don't think this PEP should become a document about "Why you should > use PAM". I appreciate that from your perspective as a Red Hat security > guy, you want everyone to use best practices as you see them, but it > isn't Python's position to convin

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 06.59, Stephen J. Turnbull wrote: > Christian Heimes writes: > > > It's all open source. It's up to the Python community to adopt > > packages and provide them on PyPI. > > > > Python core will not maintain and distribute the packages. I&

[Python-Dev] PEP 594: discussion-to discuss.python.org

Please use https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 for feedback and discussion. Thank you, Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-d

Re: [Python-Dev] PEP 594: update 1

On 22/05/2019 02.44, Brett Cannon wrote: > It also doesn't help that no one is listed in the experts index for the > module either.. Excellent point! The PEP now lists the presence / absence of experts. Christian ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 23/05/2019 02.58, Steven D'Aprano wrote: > On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote: >> On 22/05/2019 12.19, Steven D'Aprano wrote: >>> I don't think this PEP should become a document about "Why you should >>> use PAM&quo

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 29/05/2019 15.29, Petr Viktorin wrote: > On 5/29/19 2:25 PM, Jeroen Demeyer wrote: >> Hello, >> >> I have one implementation question about vectorcall which is not >> specified in PEP 590: what should happen if a type implements >> vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't

[Python-Dev] Re: python3 -bb and hash collisions

On 18/06/2019 18.32, Daniel Holth wrote: > set([u"foo", b"foo]) will error because the two kinds of string have the > same hash, and this causes a comparison. Is that correct? Yes, it will fail with -bb, because it turns comparison between str and bytes into an error. This can also happen with oth

[Python-Dev] Re: EuroPython 2019 sprints

On 13/06/2019 18.28, Steve Dower wrote: > Hi all > > Just letting everyone know that I signed up any core devs who are going > to be at EuroPython to run sprints :) (including myself, since I'll be > there) > > Like PyCon US, the sprints at EuroPython will attract many first-time > contributors,

[Python-Dev] Re: 3.7.4 final delayed [Was: Python 3.7.4rc1 (and 3.6.9rc1) cutoffs ahead, now set for 2019-06-17]

On 29/06/2019 21.53, Ned Deily wrote: > On Jun 6, 2019, at 01:43, Ned Deily wrote: >> >> https://discuss.python.org/t/python-3-7-4rc1-and-3-6-9rc1-cutoffs-ahead-now-set-for-2019-06-17/1824 >> [...] >> Following the rc1 cutoff, changes merged to the >> 3.7 branch will be released in 3.7.5 three mon

[Python-Dev] Docs: audit event table empty

Hi, the table with auditing events does not render on docs.python.org, https://docs.python.org/3.9/library/audit_events.html. Steve and I are going to present the auditing feature tomorrow at EuroPython. It would be helpful to have the table available. It works on Steve's and my local machine wit

[Python-Dev] Re: Docs: audit event table empty

On 09/07/2019 14.02, Julien Palard wrote: > Hi Christian, > >> the table with auditing events does not render on docs.python.org, >> https://docs.python.org/3.9/library/audit_events.html. Steve and I are >> going to present the auditing feature tomorrow at EuroPython. It would >> be helpful to hav

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 00.14, Steven D'Aprano wrote: > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: > >> What I don't see is where the money's coming from. It's fine to ask, >> but will anyone come up with that sort of funding? > > I don't think Mark is asking for you or I to fund the exerc

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 09.35, Paul Moore wrote: > On Wed, 21 Oct 2020 at 08:14, Christian Heimes wrote: >> >> On 21/10/2020 00.14, Steven D'Aprano wrote: >>> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: >>> >>>> What I don't see is wh

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 11.37, Steven D'Aprano wrote: > On Wed, Oct 21, 2020 at 09:06:58AM +0200, Christian Heimes wrote: >> On 21/10/2020 00.14, Steven D'Aprano wrote: >>> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: >>> >>>> What I don

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 20.55, Larry Hastings wrote: > On 10/21/20 5:58 AM, Petr Viktorin wrote: >> At the risk of going off topic: That's for GCC. As far as I know, MSVC >> uses something like __declspec( thread ). >> What are the options for generic C99 compilers, other than staying slow? > > > As a prac

[Python-Dev] Re: When to remove BytesWarning?

On 24/10/2020 05.19, Inada Naoki wrote: > Hi, all. > > To avoid BytesWarning, the compiler needs to do some hack when they > need to store bytes and str constants in one dict or set. > BytesWarning has maintenance costs. It is not huge, but significant. > > When can we remove it? My idea is: > >

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

On 30/10/2020 08.58, Serhiy Storchaka wrote: > It would make life of Illumos and OpenIndiana developers much harder, > that can be seen hostile to open source community. It would make the > code of CPython more rigid, virtually Linux-only with Windows and MacOS > patches, and as a side effect can m

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

9 release, Fedora has plans to fix this > <https://src.fedoraproject.org/rpms/python3.10/pull-request/13>, and > Christian Heimes has opened a bug on the Ubuntu launchpad > <https://bugs.launchpad.net/ubuntu/+source/python3.9/+bug/1904271> for > this. I will figure o

[Python-Dev] Re: Where is the SQLite module maintainer

On 27/12/2020 21.20, Erlend Aasland wrote: > Hi, everyone. > > I'm trying to find a reviewer for this trivial > PR: https://github.com/python/cpython/pull/20530 > > (The PR fixes /CheckTraceCallbackContent/ (in the sqlite3 test suite) > for SQLite pre

[Python-Dev] Re: Upcoming 3.7.10 and 3.6.13 Security Releases

On 20/01/2021 13.06, Miro Hrončok wrote: > On 10. 01. 21 21:15, Ned Deily wrote: >> We are planning to produce the next security-fix rollup releases for >> Python 3.7.x and 3.6.x on 2021-01-15. The most recent releases for >> these versions were on 2020-08-17.  There has not been a lot of >> activi

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On 01/02/2021 17.39, M.-A. Lemburg wrote: >> Can you explain where wchar_t* type is appropriate and how two >> conversions is a performance bottleneck? > > If an extension has a wchar_t* string, it should be easy > to convert this in to a Python bytes object for use in Python. How much software a

[Python-Dev] Re: Security releases of CPython

On 19/02/2021 23.22, Stestagg wrote: > The thing that stood out from this conversation, for me, is: Releases > are too hard, and there’s a risk of not having enough volunteers as a > result. > > How hard is it to fix that?  Actually it's easy to fix! The PSF needs needs sufficient money to hire

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 21/02/2021 13.13, Victor Stinner wrote: > Hi, > > I propose to actively remove support for *legacy* platforms and > architectures which are not supported by Python according to PEP 11 > rules: hardware no longer sold and end-of-life operating systems. The > removal should be discussed on a case

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 21/02/2021 13.47, glaub...@debian.org wrote: > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms. > There is no separate configure guard. All platforms that Rust can build for, > are always enabled by default. No one in Rust keeps anyone from > cross-compiling code

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

f Python, and the following >> statement stood out for me as shocking: >> >> Christian Heimes wrote: >>> Core dev and PyPA has spent a lot of effort in promoting venv because we >>> don't want users to break their operating system with sudo pip install. >>

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 11.52, Stéfane Fermigier wrote: > I love pipx and I'm glad it exists at this point because it make  > > The main issue is that each virtualenv takes space, lots of space. > > I have currently 57 apps installed via pipx on my laptop, and the 57 > environments take almost 1 GB already

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 15.16, Random832 wrote: > On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: >> Separate directories don't prevent clashes and system breakage. But they >> provide an easy way to *recover* from a broken system. > > I think it could be turned into

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 19.17, Steve Dower wrote: > On 2/24/2021 4:26 PM, Christian Heimes wrote: >> On 24/02/2021 15.16, Random832 wrote: >>> On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: >>>> Separate directories don't prevent clashes and system breakage. But

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 20.03, Christian Heimes wrote: > On 24/02/2021 19.17, Steve Dower wrote: >> On 2/24/2021 4:26 PM, Christian Heimes wrote: >>> On 24/02/2021 15.16, Random832 wrote: >>>> On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: >>>>> Separate

[Python-Dev] Re: Need help to fix known Python security vulnerabilities

On 08/03/2021 22.02, Victor Stinner wrote: Thanks Victor! > == XML == > > Python XML parsers have at least two known vulnerabilities: "billion > laughs" and "quadratic blowup" which are documented: > https://docs.python.org/dev/library/xml.html#xml-vulnerabilities > > The third party defusedxml

[Python-Dev] Re: Steering Council update for February

On 10/03/2021 01.53, Chris Angelico wrote: > On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw > wrote: >> >>> Does 'master' confuse people? >> >> There's a general movement to replace language from common programming >> practises that derive from, or are associated with, the dehumanization of >> peo

[Python-Dev] Re: Steering Council update for February

On 10/03/2021 10.30, Antoine Pitrou wrote: > On Wed, 10 Mar 2021 10:30:43 +0900 > Inada Naoki wrote: >> On Wed, Mar 10, 2021 at 10:10 AM Ivan Pozdeev via Python-Dev >> wrote: >>> >>> On 10.03.2021 3:53, Chris Angelico wrote: On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw wrote: >

[Python-Dev] Re: Steering Council update for February

On 11/03/2021 00.38, Mike Miller wrote: > > On 2021-03-10 13:45, David Mertz wrote: >> In contrast, the "master" used in version control directly borrows >> from so-called "master/slave network architecture." > > > It was shown upthread that this isn't the case.  Do you have more > accurate docu

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 25/03/2021 18.39, Antoine Pitrou wrote: > On Thu, 25 Mar 2021 20:22:55 +0300 > Ivan Pozdeev via Python-Dev wrote: >> On 24.03.2021 19:58, Antoine Pitrou wrote: >>> On Wed, 24 Mar 2021 19:45:49 +0300 >>> Ivan Pozdeev via Python-Dev wrote: How does C++ fare in binary compatibility? Last t

[Python-Dev] OpenSSL 1.1.1k CVE fixes

Hi, OpenSSL released 1.1.1k today with two high severity CVEs, https://www.openssl.org/news/vulnerabilities.html The ssl module is not affected by CVE-2021-3450 in its default configuration. Python does not set X509_V_FLAG_X509_STRICT on SSLContext. Only applications that that use ssl.VERIFY_X50

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

On 30/03/2021 19.01, Barry Warsaw wrote: > Hello Mario, > > Thank you for your submission of PEP 648 (Extensible customizations of the > interpreter at startup). The Python Steering Council has reviewed the PEP > and before we can pronounce on it, we have some additional questions and > commen

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 16/04/2021 19.39, Victor Stinner wrote: > A *fresh* build (after make clean) of CPython on my laptop (8 threads, > 4 CPU cores) takes 13 seconds using make -j10 and gcc -O0. A fresh > build in release mode (make -j10 and gcc -O3) takes 44 seconds on the > same laptop. $ make clean $ time make -

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 16/04/2021 19.14, redrad...@gmail.com wrote: > My personal stop of contributing in CPython is that it is written in pure C !! > I wrote code in both: pure C and C++, but I like writing code in C++, because > it simplifies things without losing perfomance There are plenty of Open Source project

[Python-Dev] Re: PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer

On 30/03/2021 13.46, Pablo Galindo Salgado wrote: > Hi Christian, > > Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating > the situation and discussing the PEP, the Steering Council is happy with > the PEP, > and hereby accepts it. The SC is of the opinion that this change

[Python-Dev] Re: March Steering Council update.

On 18/05/2021 16.19, Guido van Rossum wrote: > There are a few mentions of Debian, but no explanation of what the issue > is about. Can you elaborate on that? Debian and Debian-based distros like Ubuntu are applying downstream packages and split CPython interpreter and stdlib into multiple package

[Python-Dev] Re: [python-committers] IMPORTANT: Python 3.10b2 release blockers

On 25/05/2021 00.45, Pablo Galindo Salgado wrote: > Hi, > > Tomorrow is the scheduled release of Python 3.10 beta 2 but > unfortunately we have several release blockers: > > https://bugs.python.org/issue44043 : > 3.10 b1 armhf Bus Error in hashlib test: test_gil

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

On 06/06/2021 11.42, Marco Sulla wrote: > As title. Is it faster for inplace sorting, or simply the > implementation of list.sort() was done before the implementation of > timsort? list.sort() uses timsort. What makes you think that Python uses mergesort? Tim Peters invented timsort for Python ab

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On 26/09/2021 13.07, jack.jan...@cwi.nl wrote: The problem with the stable ABI is that very few developers are targeting it. I’m not sure why not, whether it has to do with incompleteness of the ABI, or with issues targeting it easily and your builds and then having pip/PyPI do the right things

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On 27/09/2021 16.32, Ronald Oussoren via Python-Dev wrote: On 26 Sep 2021, at 19:03, Christian Heimes <mailto:christ...@python.org>> wrote: On 26/09/2021 13.07, jack.jan...@cwi.nl <mailto:jack.jan...@cwi.nl> wrote: The problem with the stable ABI is that very few developers ar

[Python-Dev] Re: python3.10 compilation on OpenBSD: running into ssl issues

On 05/10/2021 16.40, Sandeep Gupta wrote: Trying to compile python3.10 on openbsd 7.0 on Pi4. It seems to run into several openssl issue.  I have installed openssl as I couldn't find libreSSL in the package manager. Your installation is picking up header files from LibreSSL. Python 3.10 requi

[Python-Dev] Re: python3.10 compilation on OpenBSD: running into ssl issues

On 06/10/2021 09.06, Sandeep Gupta wrote: Tried with openssl. Some progress but no success.  The configure checks went through find. >configure:17536: checking for openssl/ssl.h in /home/kabira/DrivingRange//project_versa/Build >s/openssl-1.1.1l >configure:17543: result: yes >configure:1755

[Python-Dev] XML DoS vulnerabilities and exploits in Python

Hello, in August 2012 I found a DoS vulnerability in expat and XML libraries in Python's standard library. Since then I have found several more issues. I have been working on fixes ever since. The README of https://pypi.python.org/pypi/defusedxml contains detailed explanations of my research and

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 20.02.2013 17:25, schrieb Benjamin Peterson: > Are these going to become patches for Python, too? I'm working on it. The patches need to be discussed as they break backward compatibility and AFAIK XML standards, too. ___ Python-Dev mailing list Pyth

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 20.02.2013 21:17, schrieb Maciej Fijalkowski: > On Wed, Feb 20, 2013 at 8:24 PM, Christian Heimes > wrote: >> Am 20.02.2013 17:25, schrieb Benjamin Peterson: >>> Are these going to become patches for Python, too? >> >> I'm working on it. The patc

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 20.02.2013 22:02, schrieb Carl Meyer: > Also, despite the title of this thread, the vulnerabilities include > fetching of external DTDs and entities (per standard), which opens up > attacks that are worse than just denial-of-service. In our initial > Django release advisory we carelessly lumped

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 20.02.2013 23:45, schrieb R. David Murray: > I don't believe it does. The DTD URL is, if I remember correctly, > specified as an identifier. The fact that you can often also download the > DTD from the location specified by the identifier is a secondary effect. > > But, it's been a *long* tim

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 20.02.2013 23:56, schrieb Fred Drake: > While I'd hate to make XML processing more painful than it often is, there's > no injunction not to be reasonable. Security concerns and resource limits > are cross-cutting concerns, so it's not wrong to provide safe defaults. > > Doing so *will* be back

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 21.02.2013 00:08, schrieb Antoine Pitrou: > Not everyone is a security nuts. But, but, but ... it's fun to be paranoid! You get so many new potential enemies. :) Jerry Fletcher ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 21.02.2013 10:23, schrieb Antoine Pitrou: > If you like being paranoid, there are other things than security to > be paranoid about: reference cycles, performance on micro-benchmarks, > memory consumption of docstrings, etc. :-) snappy(__doc__)? http://code.google.com/p/snappy/ Christian ___

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 21.02.2013 08:42, schrieb Antoine Pitrou: > Sure, but in many instances, rebooting a machine is not > business-threatening. You will have a couple of minutes' downtime and > that's all. Which is why the attack must be repeated many times to be a > major annoyance. Is this business-threatening e

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 21.02.2013 11:32, schrieb Antoine Pitrou: > You haven't proved that these were actual threats, nor how they > actually worked. I'm gonna remain skeptical if there isn't anything > more precise than "It highly depends on the parser and the application > what kind of exploit is possible". https:/

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 21.02.2013 12:16, schrieb Antoine Pitrou: > I don't know whether you are trying to be ironic but, for the record, > proof of concepts needn't be "released into the wild" as long as they > exist. Fun fact: In fact the abbreviation 'ap' doesn't stand for 'Antoine Pitrou' but for 'antipole'. I'm

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

Am 21.02.2013 19:39, schrieb Eli Bendersky: > Just to clarify for my own curiosity. These attacks (e.g. > http://en.wikipedia.org/wiki/Billion_laughs) have been known and public > since 2003? Correct, see https://pypi.python.org/pypi/defusedxml#synopsis third paragraph. All XML attacks in my analy

Re: [Python-Dev] xml.sax and xml.dom fetch DTDs by default

Am 22.02.2013 00:47, schrieb Paul Boddie: > Perhaps related to the discussion of denial-of-service vulnerabilities is the > matter of controlling access to remote resources. I suppose that after the > following bug was closed, no improvements were made to the standard library: > > http://bugs.py

Re: [Python-Dev] Slides from today's parallel/async Python talk

Am 14.03.2013 03:05, schrieb Trent Nelson: > Just posted the slides for those that didn't have the benefit of > attending the language summit today: > > > https://speakerdeck.com/trent/parallelizing-the-python-interpreter-an-alternate-approach-to-async Wow, neat! Your idea with P

[Python-Dev] Status of XML fixes

Hello, I like to give an update on the XML vulnerability fixes. Brett has asked me a couple of days ago but I haven't had time to answer. I was/am busy with my daily job. Any attempt to fix the XML issues *will* change the behavior of the library and result into an incompatibility with older rele

Re: [Python-Dev] Status of XML fixes

Am 17.03.2013 19:25, schrieb Eli Bendersky: > I'll gladly review the _elementtree changes and can help with the expat > & pyexpat changes as well. Until now I had the impression that the > patches aren't ready for review yet. If they are, that's great. The modifications to expat, pyexpat and _elem

Re: [Python-Dev] Status of XML fixes

Am 17.03.2013 19:59, schrieb Antoine Pitrou: >> Why keep the libraries vulnerable for another year (3.4 final is expected >> for early 2014), if there is something we can do about them now? > > Well, Christian said that his stdlib patch wasn't ready yet. The patch is > 90% finished. All the hard

Re: [Python-Dev] cpython (2.7): Issue 17538: Document XML vulnerabilties

Am 26.03.2013 19:41, schrieb Antoine Pitrou: > On Tue, 26 Mar 2013 17:53:39 +0100 (CET) > christian.heimes wrote: >> + >> +The XML processing modules are not secure against maliciously constructed >> data. >> +An attacker can abuse vulnerabilities for e.g. denial of service attacks, to >> +access

Re: [Python-Dev] Safely importing zip files with C extensions

Am 28.03.2013 17:09, schrieb Brett Cannon: > Which must be done carefully to prevent a security issue. It shouldn't > be unzipped anywhere but into a directory only writable by the process. Cleanup is going to be tricky or even impossible. Windows locks loaded DLLs and therefore prevents their re

Re: [Python-Dev] The end of 2.7

Am 06.04.2013 23:11, schrieb Georg Brandl: > Am 06.04.2013 23:02, schrieb Benjamin Peterson: >> Per my last message, 2.7.4 has at long last been released. I apologize >> for the long interval between 2.7.3 and 2.7.4. To create more >> determinism in the future, I will be soon updating PEP 373 with

Re: [Python-Dev] casefolding in pathlib (PEP 428)

Am 12.04.2013 14:43, schrieb Ronald Oussoren: > At least for OSX the kernel will normalize names for you, at least for HFS+, > and therefore two names that don't compare equal with '==' can refer to the > same file (for example the NFKD and NFKC forms of Löwe). > > Isn't unicode fun :-) Seriousl

Re: [Python-Dev] PEP 428: stat caching undesirable?

Am 01.05.2013 16:39, schrieb Guido van Rossum: > I've not got the full context, but I would like to make it *very* > clear in the API (e.g. through naming of the methods) when you are > getting a possibly cached result from stat(), and I would be very > concerned if existing APIs were going to get

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Am 10.05.2013 12:55, schrieb Ben Hoyt: > Higher-level functions like os.walk() would then check the fields they > needed are not None, and only call os.stat() if needed, for example: > > # Build lists of files and directories in path > files = [] > dirs = [] > for name, st in os.scandir(path): >

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Am 10.05.2013 14:16, schrieb Antoine Pitrou: > But what if some systems return more than the file type and less than a > full stat result? The general problem is POSIX's terrible inertia. > I feel that a stat result with some None fields would be an acceptable > compromise here. POSIX only defines

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Am 11.05.2013 16:34, schrieb Nick Coghlan: > Here's the full set of fields on a current stat object: > > st_atime > st_atime_ns > st_blksize > st_blocks > st_ctime > st_ctime_ns > st_dev > st_gid > st_ino > st_mode > st_mtime > st_mtime_ns > st_nlink > st_rdev > st_size > st_uid And there are mor

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Am 13.05.2013 00:04, schrieb Ben Hoyt: > In fact, I don't think .cached_lstat should be exposed to the user. > They just call entry.lstat(), and it returns a cached stat or calls > os.lstat() to get the real stat if required (and populates the > internal cached stat value). And the entry.is* functi

Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info

Am 13.05.2013 02:21, schrieb Ben Hoyt: > Are you suggesting just accessing .cached_lstat could call os.lstat()? > That seems very bad to me. It's a property access -- it looks cheap, > therefore people will expect it to be. From PEP 8 "Avoid using > properties for computationally expensive operatio

Re: [Python-Dev] Mysterious Python pyc file corruption problems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 16.05.2013 17:40, schrieb Barry Warsaw: > We've since found a few cases where Python 3.3 pyc files are > probably corrupted, so that shoots down my theory about a race > condition on reading/writing pyc files, since 3.3 implements > atomic-rename

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

Am 03.06.2013 07:20, schrieb Donald Stufft: > Ideally this would take the shape of attempting to locate the system > certificate store if possible, and if that doesn't work falling back to > the bundled certificates. That way the various Linux distros can easily > have their copies of Python depend

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

Am 03.06.2013 21:52, schrieb Antoine Pitrou: > cadefault=True will probably be fail if the system certs are not > properly configured in OpenSSL, e.g. under Windows or with a hand-made > OpenSSL build. > And, because of the way the OpenSSL API works, there's no way of > knowing if it is the case or

[Python-Dev] ssl improvements and testing question

Hi, I'm working on a couple of improvements for the ssl module: http://bugs.python.org/issue17134 http://bugs.python.org/issue18138 http://bugs.python.org/issue18143 http://bugs.python.org/issue18147 #17134 is going to provide a way to use Window's crypt32.dll to load CA certs from Window's CA c

Re: [Python-Dev] cpython: fixd refleak

Am 13.06.2013 20:59, schrieb Antoine Pitrou: > How about > > return Py_BuildValue("", ofile_env, ofile, odir_env, odir); > > ? Oh right, I forgot about 'N'. The PyArg_Parse*() methods don't have it. Do you want me to modify the code to use Py_BuildValue()? Christian ___

Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators

Am 15.06.2013 14:22, schrieb Nick Coghlan: > However, it's still desirable to be able to monitor those direct > allocations in debug mode, thus it makes sense to have a GIL protected > direct allocation API as well. You could try to hide the existence of > the latter behaviour and treat it as a pri

Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators

Am 15.06.2013 14:57, schrieb Victor Stinner: > Le 15 juin 2013 03:54, "Victor Stinner" > a écrit : > >> Ok, I reverted my commit. >> >> I will work on a PEP to explain all these new functions and their use > cases. > > I created the PEP 445 to reserve the number. It is ready for a review > but a

Re: [Python-Dev] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()

Am 18.06.2013 12:56, schrieb Jeremy Kloth: > On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner > wrote: >> diff --git a/Modules/_ctypes/callproc.c b/Modules/_ctypes/callproc.c >> --- a/Modules/_ctypes/callproc.c >> +++ b/Modules/_ctypes/callproc.c >> @@ -70,6 +70,7 @@ >> >> #include >> #include "

Re: [Python-Dev] cpython (3.3): ctypes: AIX needs an explicit #include to get alloca()

Am 18.06.2013 13:32, schrieb Victor Stinner: > 2013/6/18 Christian Heimes : >> Am 18.06.2013 12:56, schrieb Jeremy Kloth: >>> On Mon, Jun 17, 2013 at 2:02 PM, victor.stinner >>>> +#include >>> >>> This header is not present on Windows, thus bre

<    1   2   3   4   5   6   7   8   9   10   >