Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 30.08.2014 17:22, Alex Gaynor wrote: > The Windows certificate store is used by ``load_default_certs``: > > * https://github.com/python/cpython/blob/master/Lib/ssl.py#L379-L381 > * https://docs.python.org/3.4/library/ssl.html#ssl.enum_certificates The Windows part of load_default_certs() has o

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 30.08.2014 00:22, Antoine Pitrou wrote: > SSL_CERT_DIR and SSL_CERT_FILE are used, if set, when > SSLContext.load_verify_locations() is called. > > Actually, come to think of it, this allows us to write a better > test for that method. Patch welcome! The environment vars are used only when SSL

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 31.08.2014 16:16, R. David Murray wrote: > Self -signed certificates are not crazy in an internal corporate > environment even when properly playing the defense in depth game. Once > you've acked the cert the first time, you will be warned if it changes > (like an ssh host key). Sure, as Nick

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 31.08.2014 08:24, Nick Coghlan wrote: > To answer David's specific question, the existing knobs at the OpenSSL > level (SSL_CERT_DIR and SSL_CERT_FILE ) let people add an internal CA, > opt out of the default CA system, and trust *specific* self-signed > certs. This works only on Unix platforms

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 31.08.2014 19:29, Antoine Pitrou wrote: > You certainly shouldn't do so. If an application has special needs that > require trusting a self-signed certificate, then it should expose a > configuration setting to let users specify the cert's location. Stuffing > self-signed certs into the system t

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 31.08.2014 08:09, Nick Coghlan wrote: > As Antoine says here, I'm also opposed to adding more Python specific > configuration options. However, I think there may be something > worthwhile we can do that's closer to the way browsers work, and has > the significant benefit of being implementable a

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 31.08.2014 22:30, Paul Moore wrote: > On 31 August 2014 21:15, Antoine Pitrou wrote: >> What do you call your local cert store? > > I was referring to Christian's comment >> It's very simple to trust a self-signed certificate: just download it and >> stuff it into the trust store. I was refe

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 01.09.2014 08:44, Nick Coghlan wrote: > Yes, it would have exactly the same security failure modes as > sitecustomize, except it would only fire if the application > imported the ssl module. > > The "-S" and "-I" switches would need to disable the implied > "sslcustomize", just as they disabl

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 01.09.2014 17:35, Nick Coghlan wrote: > Oh, now I get what you mean - yes, sitecustomize already poses the same > kind of problem as the proposed sslcustomize (hence the existence of the > related command line options). If an attacker is able to place a module like sitecustomize.py in an import

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 02.09.2014 23:32, Antoine Pitrou wrote: >> Furthermore, "disable verification" is a nonsensical thing to do with TLS. > > It's not. For example, if you have an expired cert, all you can do > AFAIK is to disable verification. It's possible to ignore or just warn about expired certs with simple

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 03.09.2014 19:29, Ethan Furman wrote: > Excellent. Last question (I hope): it is possible to (easily) create an > SSLContext that will verify against a self-signed certificate? Yes: context = ssl.create_default_context(cafile="/path/to/selfsigned.pem") That works iff the certificate is va

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 03.09.2014 19:54, Guido van Rossum wrote: > Let's take the plunge on this issue for the next 2.7 release (3.5 being > a done deal). Yes, some people will find that they have an old script > accessing an old service which breaks. Surely some of the other changes > in the same 2.7 bugfix release w

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 03.09.2014 21:37, Victor Stinner wrote: > Thanks, you replied before I asked the question :-) (If > certificates are validated by default, how do you disable the > checks?) > > Sorry, I didn't follow the whole discussion and Python 2.7 changes > related to security. Does Python 2.7 support loa

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 03.09.2014 21:37, Guido van Rossum wrote: > OK, that changes my position for 2.7 (but not for 3.5). I had > assumed there was a way to disable the cert check by changing one > parameter to the urlopen() call. (And I had wanted to add that > there should be a clear FAQ about the subject.) If this

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 09.09.2014 05:03, Nick Coghlan wrote: > > On 9 Sep 2014 10:48, "Jim J. Jewett" > wrote: >> I assume that adding _unverified_urlopen or urlopen(context=...) do >> provide incremental improvements compatible with the eventual full >> opt-in. If so, adding them is pr

Re: [Python-Dev] PEP476: Enabling certificate validation by default

On 19.09.2014 18:53, Alex Gaynor wrote: > Hi all, > > I've just updated the PEP to reflect the API suggestions from Nick, and the > fact that the necessary changes to urllib were landed. > > I think this is ready for pronouncement, Guido? There is still the issue with SSL_CERT_DIR and SSL_CERT_F

Re: [Python-Dev] PEP476: Enabling certificate validation by default

On 21.09.2014 01:03, Nick Coghlan wrote: > We may also need some clarification from Ned regarding the status of > OpenSSL and the potential impact switching from dynamic linking to > static linking of OpenSSL may have in terms of the > "OPENSSL_X509_TEA_DISABLE" setting. You may want to ask Hynek,

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

On 26.09.2014 20: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 produ

Re: [Python-Dev] libffi embedded in CPython

On 19.12.2014 10:52, Paul Moore wrote: > Probably the easiest way of moving this forward would be for someone > to identify the CPython-specific patches in the current version, and > check if they are addressed in the latest libffi version. They haven't > been applied as they are, I gather, but may

Re: [Python-Dev] Starting CPython development w/ Docker

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-04-20 15:52, Saul Shanabrook wrote: > I started trying some CPythong development a week ago at PyCon and > first got testing working using Docker on my mac. This had the > advantage of not having to worry about installing and dependencies, >

Re: [Python-Dev] Fwd: Coverity Scan update

On 2015-05-12 17:28, Guido van Rossum wrote: > -- Forwarded message -- > From: "Dakshesh Vyas" mailto:dv...@coverity.com>> > Date: May 12, 2015 1:08 AM > Subject: Coverity Scan update > To: "gu...@python.org " > > Cc: > > Hello Gui

Re: [Python-Dev] PEP 553: Built-in debug()

On 2017-09-07 09:50, Barry Warsaw wrote: > On Sep 6, 2017, at 23:10, Terry Reedy wrote: >> >> Environmental variables are set to strings, not objects. It is not clear >> how you intend to handle the conversion. > > The environment variable names a module import path. Without quibbling about >

[Python-Dev] make multissltests

For your information, You can now automatically compile and check the ssl module with multiple versions of OpenSSL and LibreSSL. The multissltest script downloads tar.gz, compiles the source and installs headers + shared lib into a local directory. It takes rather long the first time because OpenS

Re: [Python-Dev] Investigating time for `import requests`

On 2017-10-02 04:04, INADA Naoki wrote: > *3. ssl* > > import time:      2007 |       2007 |                     ipaddress > import time:      2386 |       2386 |                     textwrap > import time:      2723 |       2723 |                     _ssl > ... > import time:       306 |        9

[Python-Dev] Python startup optimization: script vs. service

Hello python-dev, it's great to see that so many developers are working on speeding up Python's startup. The improvements are going to make Python more suitable for command line scripts. However I'm worried that some approaches are going to make other use cases slower and less efficient. I'm talki

Re: [Python-Dev] Python startup optimization: script vs. service

On 2017-10-02 14:05, George King wrote: > I’m new to this issue, but curious: could the long-running server > mitigate lazy loading problems simply by explicitly importing the > deferred modules, e.g. at the top of __main__.py? It would require some > performance tracing or other analysis to figure

Re: [Python-Dev] Python startup optimization: script vs. service

On 2017-10-02 15:26, Victor Stinner wrote: > 2017-10-02 13:10 GMT+02:00 INADA Naoki : >> https://github.com/python/cpython/pull/3796 >> In this PR, lazy loading only happens when uuid1 is used. >> But uuid1 is very uncommon for nowdays. > > Antoine Pitrou added a new C extension _uuid which is imp

Re: [Python-Dev] Python startup optimization: script vs. service

On 2017-10-02 16:59, Barry Warsaw wrote: > On Oct 2, 2017, at 10:48, Christian Heimes wrote: >> >> That approach could work, but I think that it is the wrong approach. I'd >> rather keep Python optimized for long-running processes and introduce a >> new mode / opti

Re: [Python-Dev] Python startup optimization: script vs. service

On 2017-10-02 19:29, Brett Cannon wrote: > My current design for an opt-in lazy importing setup includes an > explicit function for importlib that's mainly targeted for the stdlib > and it's startup module needs, but could be used by others: > https://notebooks.azure.com/Brett/libraries/di2Btqj7zSI

Re: [Python-Dev] [edk2] Official port of Python on EDK2

On 2017-11-01 10:07, Thiebaud Weksteen wrote: > Hi, > > UEFI has become the standard for firmware (BIOS) interface. Intel has > provided an open source implementation under the name EDK2 (part of > the TianoCore initiative) [1] for some time. This implementation has > evolved significantly and now

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On 2017-11-28 21:31, Raymond Hettinger wrote: > >> I also cc python-dev to see if anybody here is strongly in favor or against >> this inclusion. > > Put me down for a strong -1. The proposal would occasionally save a few > keystokes but comes at the expense of giving Python a more Perlish lo

[Python-Dev] [ssl] The weird case of IDNA

Hi, tl;dr This mail is about internationalized domain names and TLS/SSL. It doesn't concern you if you live in ASCII-land. Me and a couple of other developers like to change the ssl module in a backwards-incompatible way to fix IDN support for TLS/SSL. Simply speaking the IDNA standards (interna

Re: [Python-Dev] [ssl] The weird case of IDNA

On 2017-12-30 11:28, Antoine Pitrou wrote: > On Fri, 29 Dec 2017 21:54:46 +0100 > Christian Heimes wrote: >> >> On the other hand ssl module is currently completely broken. It converts >> hostnames from bytes to text with 'idna' codec in s

Re: [Python-Dev] [ssl] The weird case of IDNA

On 2017-12-30 13:19, Skip Montanaro wrote: > Guido wrote: > > This being a security issue I think it's okay to break 3.6. might > even backport to 3.5 if it's easy? > > > Is it also a security issue with 2.x? If so, should a fix to 2.7 be > contemplated? IMO the IDNA encoding problem is

[Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

Hi, I'm still working on a ssl module PEP for 3.7 [1], but it's probably not going to be finished before beta 1 deadline. I have a bunch of fixes and improvements for the ssl module in queue, most of them require OpenSSL 1.0.2 features. The features are also present and working properly since Libr

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-13 14:23, Antoine Pitrou wrote: > On Sat, 13 Jan 2018 13:54:33 +0100 > Christian Heimes wrote: >> >> If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land >> bunch of useful goodies like proper hostname verification [2], proper >> fix fo

[Python-Dev] Deprecate PEP 370 Per user site-packages directory?

Hi, PEP 370 [1] was my first PEP that got accepted. I created it exactly one decade and two days ago for Python 2.6 and 3.0. Back then we didn't have virtual environment support in Python. Ian Bicking had just started to create the virtualenv project a couple of months earlier. Fast forward 10 ye

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On 2018-01-13 19:04, Random832 wrote: > On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote: >> Hi, >> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one >> decade and two days ago for Python 2.6 and 3.0. Back then we didn't have >>

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On 2018-01-13 20:08, Oleg Broytman wrote: > Hi! > > On Sat, Jan 13, 2018 at 06:06:16PM +0100, Christian Heimes > wrote: >> Hi, >> >> PEP 370 [1] was my first PEP that got accepted. I created it exactly one >> decade and two days ago for Python 2.6 and 3.0.

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On 2018-01-13 19:57, Antoine Pitrou wrote: > On Sat, 13 Jan 2018 19:18:41 +0100 > Christian Heimes wrote: >> On 2018-01-13 19:04, Random832 wrote: >>> On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote: >>>> Hi, >>>> >>>> PEP 370 [1]

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-13 21:02, Brett Cannon wrote: > +1 from me as well for the improved security. Thanks, Brett! How should we handle CPython's Travis CI tests? The 14.04 boxes have OpenSSL 1.0.1. To the best of my knowledge, Travis doesn't offer 16.04. We could either move to container-based testing with

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-14 01:03, Steven D'Aprano wrote: > On Sat, Jan 13, 2018 at 02:23:19PM +0100, Antoine Pitrou wrote: >> On Sat, 13 Jan 2018 13:54:33 +0100 >> Christian Heimes wrote: >>> >>> If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land &

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-14 03:48, Paul G wrote: > One thing to note is that if getting Travis working with Python 3.7 is a > pain, a huge number of libraries on PyPI probably just won't test > against Python 3.7, which is not a great situation to be in. > > It's probably worth contacting Travis to give them a

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-14 11:17, Antoine Pitrou wrote: > On Sat, 13 Jan 2018 23:45:07 +0100 > Christian Heimes wrote: >> On 2018-01-13 21:02, Brett Cannon wrote: >>> +1 from me as well for the improved security. >> >> Thanks, Brett! >> >> How should we handle CP

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-14 09:24, Matt Billenstein wrote: > Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has > deprecated (and no longer ships the header files for) the version shipped with > recent versions of osx. > > Perhaps this is an option to support the various flavors of Linu

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On 2018-01-14 04:16, Barry Warsaw wrote: > On Jan 13, 2018, at 12:06, Christian Heimes wrote: > >> These days a lot of packages are using setuptools' entry points to >> create console scripts. Entry point have no option to create a console >> script with -s or -I fl

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-14 16:54, Ned Deily wrote: > On Jan 14, 2018, at 08:39, Christian Heimes wrote: >> On 2018-01-14 09:24, Matt Billenstein wrote: >>> Correct me if I'm wrong, but Python3 on osx bundles openssl since Apple has >>> deprecated (and no longer ships the heade

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >=2.5.3

On 2018-01-16 08:08, Steve Dower wrote: > From my perspective, we can’t keep an OpenSSL-like API and use Windows > platform libraries (we *could* do a requests-like API easily enough, but > even urllib3 is painfully low-level). > >   > > We have to continue shipping our own copy of OpenSSL on Win

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On 2018-01-16 12:28, Wes Turner wrote: > > > On Tuesday, January 16, 2018, Steve Dower > wrote: > > From my perspective, we can’t keep an OpenSSL-like API and use > Windows platform libraries (we *could* do a requests-like API easily > enough, but even

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have created a daily cronjob to populate Travis' cache with OpenSSL builds. Until the cache is filled, Linux CI will take an extra 5 minute. Christian [1] https://github.com/python/cpython/pull/5180 __

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL>=2.5.3

On 2018-01-16 22:47, Steve Dower wrote: > I think you mean out-of-band updates, and by “you” I'm going to pretend > you mean PyCA ;) Err, yes :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubs

[Python-Dev] LibreSSL support

On 2018-01-16 21:17, Christian Heimes wrote: > FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have > created a daily cronjob to populate Travis' cache with OpenSSL builds. > Until the cache is filled, Linux CI will take an extra 5 minute. I have messed up my in

Re: [Python-Dev] LibreSSL support

On 2018-01-18 19:42, Wes Turner wrote: > Is there a build flag or a ./configure-time autodetection that would > allow for supporting LibreSSL while they port X509_VERIFY_PARAM_set1_host? X509_VERIFY_PARAM_set1_host() is a fundamental and essential piece in the new hostname verification code. I can

Re: [Python-Dev] LibreSSL support

On 2018-01-18 20:54, Wes Turner wrote: > LibreSSL is not a pressing need for me; but fallback to the existing > insecure check if LibreSSL is present shouldn't be too difficult? Please give it a try and report back. Patches welcome :) Christian ___ Pyt

Re: [Python-Dev] LibreSSL support

On 2018-01-18 21:49, Chris Jerdonek wrote: > > On Thu, Jan 18, 2018 at 7:34 AM Christian Heimes <mailto:christ...@python.org>> wrote: > > On 2018-01-16 21:17, Christian Heimes wrote: > We have two options until LibreSSL has addressed the issue: > >

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

On 2018-01-19 06:36, Benjamin Peterson wrote: > +1 to both of your specific proposals. > > More generally, I think it makes good sense to allow dropping support for a > platform in the next major Python release after vendor support for the > platform stops. Even we say we support something, it w

Re: [Python-Dev] LibreSSL support

On 2018-01-19 10:43, Steve Holden wrote: > On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith <mailto:n...@pobox.com>> wrote: > > On Jan 18, 2018 07:34, "Christian Heimes" <mailto:christ...@python.org>> wrote: > > On 2018-01-16 21:

Re: [Python-Dev] LibreSSL support

On 2018-01-19 15:42, Christian Heimes wrote: > On 2018-01-19 10:43, Steve Holden wrote: >> On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith > <mailto:n...@pobox.com>> wrote: >> >> On Jan 18, 2018 07:34, "Christian Heimes" > <mailto:christ..

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

On 2018-02-01 10:19, Oleg Sivokon wrote: > >> so why shouldn’t the one with the most users? > > Because it makes compilation difficult, and cross-compilatin completely > impossible? Why is it difficult: a package maintainer needs to (1) buy MS > Windows (2) create a special workflow for compil

[Python-Dev] Deprecate crypt module and revert PR 3854

Hi, in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to Python's crypt mdodule. I vetoed against addition of the APIs because all these hashing algorithms are not state of the art. Their quality ranges from old to horribly, horriblye broken beyond any repair. Shortly after the PR ha

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On 2018-02-02 18:05, Serhiy Storchaka wrote: > 02.02.18 18:18, Guido van Rossum пише: >> I'm all for nudging people in the direction of xcrypt. I assume we >> can't just switch the C-level crypt with xcrypt and leave the Python >> API unchanged? >> >> However until a usable solution exist (either i

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On 2018-02-02 21:31, Antoine Pitrou wrote: > On Fri, 2 Feb 2018 16:23:20 +0100 > Christian Heimes wrote: >> Hi, >> >> in PR 3854 [1] Serhiy added blowfish, extended DES and NT-Hash to >> Python's crypt mdodule. I vetoed against addition of the APIs because >

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On 2018-02-02 21:21, Nathaniel Smith wrote: > On Feb 2, 2018 7:24 AM, "Christian Heimes" <mailto:christ...@python.org>> wrote: > > Shortly after the PR has landed, I was made aware that glibc has > deprecated crypt(3) API [2] and favor of an external li

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

On 2018-02-02 17:18, Guido van Rossum wrote: > I'm all for nudging people in the direction of xcrypt. I assume we can't > just switch the C-level crypt with xcrypt and leave the Python API > unchanged? > > However until a usable solution exist (either in the stdlib or as 3rd > party) I don't think

Re: [Python-Dev] Python Test suite hangining

On 2018-03-05 13:13, Brett Cannon wrote: > > > On Sun, 4 Mar 2018 at 11:38 TonyFlury via Python-Dev > mailto:python-dev@python.org>> wrote: > > All, > Sorry to trouble you all  - but I am trying to get the Python 3.8 > test suite running on Ubuntu 16.0.4. > > As per the dev guid

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

On 2018-04-02 22:48, Lukasz Langa wrote: > Pickle protocol version 4.0 was originally defined back in PEP 3154 and > shipped as part of Python 3.4 back in 2011. Yet it's still not the default. > There's a number of things that would run faster with it like multiprocessing. > > This is too late f

[Python-Dev] ssl module and LibreSSL CVE-2018-8970

Hi, I like to share the story of a critical security bug with you. Contrary to other issues in TLS/SSL, it's a story with happy ending. Nobody was harmed. The bug was fixed before it affected the general population. Introduction Python's ssl.match_hostname() function was a source o

Re: [Python-Dev] Trying to build from source, test-poplib fails

On 2018-04-08 01:33, Skip Montanaro wrote: >> Do you have ca-certificates installed? > > It seems so: > > % apt search ca-certificates | grep installed > > ca-certificates/artful,artful,now 20170717 all [installed] > ca-certificates-mono/artful,artful,now 4.6.2.7+dfsg-1ubuntu1 all > [installed,a

Re: [Python-Dev] Trying to build from source, test-poplib fails

On 2018-04-09 10:30, Serhiy Storchaka wrote: >> I get the same issues too, and this has been happening for quite some >> time.  The tests and/or poplib itself may be written in a fragile way. > > I get the different issue with test_poplib (running with the -j option). > All tests except test_multi

Re: [Python-Dev] bpo-28055: Fix unaligned accesses in siphash24(). (GH-6123)

On 2018-05-13 06:57, Serhiy Storchaka wrote: > https://github.com/python/cpython/commit/1e2ec8a996daec65d8d5a3d43b66a9909c6d0653 > commit: 1e2ec8a996daec65d8d5a3d43b66a9909c6d0653 > branch: master > author: Rolf Eike Beer > committer: Serhiy Storchaka > date: 2018-05-13T13:57:31+03:00 > summary:

Re: [Python-Dev] Hashes in Python3.5 for tuples and frozensets

On 2018-05-16 18:10, Raymond Hettinger wrote: > > >> On May 16, 2018, at 5:48 PM, Anthony Flury via Python-Dev >> wrote: >> >> However the frozen set hash, the same in both cases, as is the hash of the >> tuples - suggesting that the vulnerability resolved in Python 3.3 wasn't >> resolved acr

[Python-Dev] Failing tests on master (asyncio, multiprocessing)

Hi, several of my PRs as well as local tests have started failing recently. On my local Fedora 27 machine, four sendfile related tests of test_asyncio's BaseLoopSockSendfileTests suite are failing reproducible. For example Travis CI job https://travis-ci.org/python/cpython/jobs/380852981 fails in

Re: [Python-Dev] Failing tests on master (asyncio, multiprocessing)

On 2018-05-19 11:29, Eitan Adler wrote: > On 19 May 2018 at 02:05, Christian Heimes wrote: >> Hi, >> >> several of my PRs as well as local tests have started failing recently. >> On my local Fedora 27 machine, four sendfile related tests of >> test_asyncio'

Re: [Python-Dev] PEP 485 isclose() implementation review requested

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-05-18 01:02, Chris Barker wrote: > * Is there a better way to create a False or True than:: > > PyBool_FromLong(0) and PyBool_FromLong(1) You can use the macros Py_RETURN_TRUE and Py_RETURN_FALSE instead of return PyBool_FromLong(0). > *

Re: [Python-Dev] PEP 485 isclose() implementation review requested

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-05-18 17:49, Chris Barker wrote: > Thanks Cristian, that clears up a couple things -- got it > compiling without warning. > > But I also discovered that I must have not pushed the latest copy > yesterday. > > It's on a machine at home -- I'

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

On 2015-05-29 23:14, Gregory P. Smith wrote: > > On Fri, May 29, 2015 at 12:24 AM Nick Coghlan > wrote: > > > On 29 May 2015 11:01 am, "Victor Stinner" > wrote: > > > > Why not continue to enhance Python 3 instead of w

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-05-30 14:03, Antoine Pitrou wrote: > No, it's up to the proponent to prove that the effect exists, with > a magnitude large enough to make any interesting difference. That's > part of the process when suggesting a change. > > If it doesn't,

[Python-Dev] OpenSSL Security Advisory [9 Jul 2015]

Hi, this just came in. According to Zachary all Windows builds use 1.0.2c. The version is vulnerable to a critical bug in the CA validation code of OpenSSL. The bug can be abused to turn any valid server certificate into a CA cert. We should consider a security release of Python ASAP. Alternat

Re: [Python-Dev] OpenSSL Security Advisory [9 Jul 2015]

On 2015-07-09 15:29, Christian Heimes wrote: > Hi, > > this just came in. According to Zachary all Windows builds use 1.0.2c. > The version is vulnerable to a critical bug in the CA validation code of > OpenSSL. The bug can be abused to turn any valid server certificate into >

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On 2015-11-17 01:00, Guido van Rossum wrote: > Hm, making Christian the BDFL-delegate would mean two out of three > authors *and* the BDFL-delegate all working for Red Hat, which clearly > has a stake (and IIUC has already committed to this approach ahead of > PEP approval). SO then it would look l

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On 2015-11-24 01:18, Nick Coghlan wrote: > On 24 November 2015 at 05:35, Christian Heimes wrote: >> On 2015-11-17 01:00, Guido van Rossum wrote: >>> Hm, making Christian the BDFL-delegate would mean two out of three >>> authors *and* the BDFL-delegate all working

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

On 2015-11-24 00:47, Nick Coghlan wrote: > Updated version of the PEP posted: https://hg.python.org/peps/rev/8decac213ebf > > On 24 November 2015 at 05:35, Christian Heimes wrote: >> 1) The example implementation of the function doesn't check the >> sys.flags.igno

Re: [Python-Dev] Fun with ancient unsupported platforms

On 2016-01-28 15:57, Larry Hastings wrote: > > > Check out and cd into Python trunk. > > % grep -Ri win16 * | wc > 10 66 625 > > % grep -Ri nextstep | wc > 23 1191328 > > % grep -Ri rhapsody * | wc > 47 2693390 > > % grep -Ri msdos * | wc > 56

Re: [Python-Dev] Adding a threadlocal to the Python interpreter

On 2016-05-18 15:20, Daniel Holth wrote: > I would like to take another stab at adding a threadlocal "str(bytes) > raises an exception" to the Python interpreter, but I had a very hard > time understanding both how to add a threadlocal value to either the > interpreter state or the threadlocal dict

Re: [Python-Dev] Adding a threadlocal to the Python interpreter

On 2016-05-19 04:30, Nick Coghlan wrote: > On 18 May 2016 at 23:20, Daniel Holth wrote: >> I would like to take another stab at adding a threadlocal "str(bytes) raises >> an exception" to the Python interpreter, but I had a very hard time >> understanding both how to add a threadlocal value to eit

[Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

Hi everybody, I have three hashing-related patches for Python 3.6 that are waiting for review. Altogether the three patches add ten new hash algorithms to the hashlib module: SHA3 (224, 256, 384, 512), SHAKE (SHA3 XOF 128, 256), BLAKE2 (blake2b, blake2s) and truncated SHA512 (224, 256). SHA-3 /

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-27 03:44, Victor Stinner wrote: > Le 27 mai 2016 12:05 PM, "Donald Stufft" > a écrit : >> BLAKE2 is an interesting one, because while SHA3 is a NIST standard > (so it’s going to gain adoption because of that), BLAKE2 is at least as > strong as SHA3 but is better

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-27 03:54, M.-A. Lemburg wrote: > On 27.05.2016 06:54, Raymond Hettinger wrote: >> >>> On May 25, 2016, at 3:29 AM, Christian Heimes wrote: >>> >>> I have three hashing-related patches for Python 3.6 that are waiting for >>> review.

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-27 09:41, Chris Barker wrote: > I'm probably showing my ignorance here, but couldn't we swap in the > OpenSSL implementation when that becomes available? No, not any time soon. As soon as we guarantee SHA3 support we have to keep our own implementation for a couple of additional release

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-27 14:41, M.-A. Lemburg wrote: > On 27.05.2016 22:58, Ryan Gonzalez wrote: >> On May 27, 2016 3:04 PM, "Victor Stinner" wrote: >>> >>> Le vendredi 27 mai 2016, M.-A. Lemburg a écrit : The current patch is 1.2MB for SHA-3 - that's pretty heavy for just a few hash function

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-28 14:06, Guido van Rossum wrote: > But you could choose which implementation to use at compile time based > on the autoconf output, right? We compile all modules and then let hashlib decide which implementation is used. hashlib prefers OpenSSL but falls back to our builtin modules. For

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-28 14:06, Brett Cannon wrote: > We can always make the test vector file an external download like we do > for some of the codec tests. That is actually a great idea! :) Thanks Brett ___ Python-Dev mailing list Python-Dev@python.org https://m

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-27 15:52, Nathaniel Smith wrote: > On Fri, May 27, 2016 at 3:08 PM, M.-A. Lemburg wrote: >> On 27.05.2016 23:46, Donald Stufft wrote: >>> On May 27, 2016, at 5:41 PM, M.-A. Lemburg wrote: If we add this now, there should at least be an exit strategy to remove the co

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

On 2016-05-28 23:51, Victor Stinner wrote: > Python 3.5 requires a 64 bit signed integer to build. Search for _PyTime > type in pytime.h ;-) Awesome! Thanks :) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/py

Re: [Python-Dev] C99

On 2016-06-03 23:11, Benjamin Peterson wrote: > PEP 7 requires CPython to use C code conforming to the venerable C89 > standard. Traditionally, we've been stuck with C89 due to poor C support > in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. > C99 does not offer anything ear

Re: [Python-Dev] C99

On 2016-06-04 10:47, Guido van Rossum wrote: > Funny. Just two weeks ago I was helping someone who discovered a > compiler that doesn't support the new relaxed variable declaration > rules. I think it was on Windows. Maybe this move is a little too > aggressively deprecating older Windows compilers

Re: [Python-Dev] C99

On 2016-06-04 11:59, Guido van Rossum wrote: > As long as we don't require extension module authors to use them -- > they may have their own compatibility requirements. On Windows extension modules must be compiled with a specific version of MSVC any way. For Python 3.6 VS 2015 or newer is a hard

Re: [Python-Dev] C99

On 2016-06-04 12:07, Guido van Rossum wrote: > I'm talking about 3rd party extensions. Those may require source > compatibility with older Python versions. All I'm asking for is to not > require source-level use of C99 features. Of course requiring a > specific compiler to work with specific CPytho

Re: [Python-Dev] cpython: replace custom validation logic in the parse module with a simple DFA validator

On 2016-06-02 11:32, benjamin.peterson wrote: > https://hg.python.org/cpython/rev/4a9159ea2536 > changeset: 101601:4a9159ea2536 > user:Benjamin Peterson > date:Thu Jun 02 11:30:18 2016 -0700 > summary: > replace custom validation logic in the parse module with a simple DFA > v

Re: [Python-Dev] Looking for volunteers to test Tulip on Windows

Am 19.10.2013 00:56, schrieb Guido van Rossum: > Thanks! That's probably fine for now -- it means the standard library > doesn't know where the root certificates are. We had a huge discussion > about this over on python-tulip: > https://groups.google.com/forum/#!topic/python-tulip/c_lqdFjPEbE > >

  1   2   3   4   5   6   7   8   9   10   >