Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-10 Thread Cory Benfield
> On 9 Jun 2017, at 20:54, Donald Stufft wrote: > > > All that being said, if someone *does* want pip to use WinHTTP, requests > provides a mechanism where you can plug in your own network handling code, so > someone could write a requests-winhttp adapter that did that, and

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-09 Thread Cory Benfield
> On 9 Jun 2017, at 20:41, Steve Dower wrote: > > These are totally fine for implementing a requests-like API that relies on > system configuration for HTTPS connections. They are not sufficient for > building a server, but they should be sufficient for downloading the

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-08 Thread Cory Benfield
> On 8 Jun 2017, at 21:17, Donald Stufft wrote: > >> >> On Jun 8, 2017, at 3:57 PM, Steve Dower > > wrote: >> >> Awesome, this is exactly what I needed to see. >> >> What if Python 2.7 just exposed the OpenSSL

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-08 Thread Cory Benfield
> On 7 Jun 2017, at 20:06, Jim Baker wrote: > > Sorry, I wish this were true, but PyOpenSSL is not available on Jython, > because we do not yet support CFFI for Jython. CFFI support is something we > have looked at, but we have not implemented. (There is a related and

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-07 Thread Cory Benfield
> On 7 Jun 2017, at 14:29, Victor Stinner wrote: > > 2017-06-07 10:56 GMT+02:00 Nathaniel Smith : >> Another testing challenge is that the stdlib ssl module has no way to >> trigger a renegotiation, and therefore there's no way to write tests >> to

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-07 Thread Cory Benfield
> On 6 Jun 2017, at 18:49, Jim Baker wrote: > > With Nick's suggestion of _tls_bootstrap, this has certainly become more > complicated. I'm still thinking of the ramifications for future Jython 2.7 > support, if Python dev goes down this path. It still seems easier to me

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-05 Thread Cory Benfield
> On 5 Jun 2017, at 12:00, Nick Coghlan wrote: > > Would you be OK with the notion of a "just for pip bootstrapping" > private backend in _ensurepip_ssl? > > That is, the only officially supported async-backed requests > configuration on Py2 would be with the PyOpenSSL

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-05 Thread Cory Benfield
> On 3 Jun 2017, at 07:25, Nick Coghlan wrote: > > As a result, as awkward and annoying as it would be, I'm wondering if > the structure of the requests migration may need to be something like: > > - switch unconditionally to an async backend on Py3 > - switch conditionally

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-05 Thread Cory Benfield
> On 2 Jun 2017, at 17:59, Donald Stufft wrote: > > I suspect (though I’d let him speak for himself) that Cory would rather > continue to be sync only than require pip to go back to not using requests. We are not wedded to supporting pip, but I think the interaction between

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-05 Thread Cory Benfield
> On 2 Jun 2017, at 17:39, Nick Coghlan wrote: > > On 3 June 2017 at 02:22, Donald Stufft wrote: >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on Windows because having pip import >>

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-02 Thread Cory Benfield
> On 2 Jun 2017, at 10:42, Victor Stinner wrote: > > Writing new code seems more risky and error-prone than backporting > already "battle-tested" MemoryBIO from master. I also expect that > writing code to validate certificate will be longer than the "100 > lines of C

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-02 Thread Cory Benfield
> On 1 Jun 2017, at 20:59, Steve Dower wrote: > > On 01Jun2017 1010, Nathaniel Smith wrote: >> I believe that for answering this question about the ssl module, it's really >> only Linux users that matter, since pip/requests/everyone else pushing for >> this only want

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 17:14, Chris Angelico wrote: > > > Do you have figures for how many people use pip on Windows vs Linux vs Mac OS? I have figures for the download numbers, which are an awkward proxy because most people don’t CI on Windows and macOS, but they’re the best

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 15:10, David Wilson wrote: > Finding someone to audit the signature checking capabilities of [0] will > have vastly lower net cost than getting the world into a situation where > pip no longer runs on the >1e6 EC2 instances that will be running Ubuntu

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 14:53, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Thu, 1 Jun 2017 14:37:55 +0100 > Cory Benfield <c...@lukasa.co.uk> wrote: >>> >>> And indeed it doesn't. Unless the target user base for pip is widely >>> different

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 14:21, Antoine Pitrou <anto...@python.org> wrote: > > > Le 01/06/2017 à 15:12, Cory Benfield a écrit : >> >> I don’t know what to do with that answer, really. I gave you some data (80%+ >> of requests downloads over the last mon

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 12:20, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Thu, 1 Jun 2017 12:01:41 +0100 > Cory Benfield <c...@lukasa.co.uk> wrote: >> In principle, sure. In practice, that means most of our users don’t use >> those features and so

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 12:09, David Wilson <dw+python-...@hmmz.org> wrote: > > On Thu, Jun 01, 2017 at 11:47:31AM +0100, Cory Benfield wrote: > >> I have, but discarded the idea. > > I'm glad to hear it was given sufficent thought. :) > > I have one fina

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 11:51, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Thu, 1 Jun 2017 11:45:14 +0100 > Cory Benfield <c...@lukasa.co.uk> wrote: >> >> I am claiming that using OpenSSL certificate validation with root stores >> that are not in

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 11:39, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Thu, 1 Jun 2017 11:22:21 +0100 > Cory Benfield <c...@lukasa.co.uk> wrote: >> >> Who is the “we” that should move on? Python core dev? Or the Python >> ecosyst

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 11:39, David Wilson <dw+python-...@hmmz.org> wrote: > > Hi Cory, > > On Thu, Jun 01, 2017 at 11:22:21AM +0100, Cory Benfield wrote: > >> We want to support as many TLS backends as possible. > > Just a wild idea, but have you investiga

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 11:28, Antoine Pitrou <anto...@python.org> wrote: > > > Le 01/06/2017 à 12:23, Cory Benfield a écrit : >> >> No it can’t. >> >> OpenSSL builds chains differently, and disregards some metadata that Windows >> and macOS s

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 11:18, Antoine Pitrou wrote: > > On Thu, 1 Jun 2017 20:05:48 +1000 > Chris Angelico wrote: >> >> As stated in this thread, OS-provided certificates are not handled by >> that. For instance, if a local administrator distributes a

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-06-01 Thread Cory Benfield
> On 1 Jun 2017, at 10:23, Antoine Pitrou wrote: > > Yes, I disagree. We needn't backport that new API to Python 2.7. > Perhaps it's time to be reasonable: Python 2.7 has been in bugfix-only > mode for a very long time. Python 3.6 is out. We should move on. Who is the

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

2017-05-31 Thread Cory Benfield
> On 31 May 2017, at 08:42, Victor Stinner <victor.stin...@gmail.com> wrote: > > Hi, > > I wrote a PEP based on the previous thread "Backport ssl.MemoryBIO on > Python 2.7?". Thanks for Cory Benfield, Alex Gaynor and Nick Coghlan > who helped me to write

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

2017-05-23 Thread Cory Benfield
> On 23 May 2017, at 20:34, David Wilson <dw+python-...@hmmz.org> wrote: > > On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote: > >> There are discussions around Requests unvendoring its dependencies >> thanks to the improved nature of pip. This mi

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

2017-05-23 Thread Cory Benfield
> On 23 May 2017, at 17:58, Victor Stinner <victor.stin...@gmail.com> wrote: > > 2017-05-23 19:54 GMT-05:00 Cory Benfield <c...@lukasa.co.uk>: >> In the absence of a Python 2.7 backport, Requests is required to basically >> use the same solution that Twisted cu

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

2017-05-23 Thread Cory Benfield
> On 23 May 2017, at 17:46, Victor Stinner <victor.stin...@gmail.com> wrote: > > > He described me his PEP and I strongly support it (sorry, I missed it > when he posted it on python-dev), but we decided (Guido van Rossum, > Christian Heimes, Cory Benfield and

Re: [Python-Dev] PEP 543: A Unified TLS API for Python

2017-02-24 Thread Cory Benfield
> On 24 Feb 2017, at 09:55, Nick Coghlan wrote: > > Heh, I guess you must have already caught everyone with a strong opinion > about this by way of security-sig :) So it seems. =D > On the procedural front, the main open question is whether or not Guido wants > to review

[Python-Dev] PEP 543: A Unified TLS API for Python

2017-02-13 Thread Cory Benfield
/dev/peps/pep-0543/ — PEP: 543 Title: A Unified TLS API for Python Version: $Revision$ Last-Modified: $Date$ Author: Cory Benfield <c...@lukasa.co.uk>, Christian Heimes <christ...@python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Oct-2016 Py

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

2017-02-02 Thread Cory Benfield
> On 2 Feb 2017, at 03:38, Stephen J. Turnbull > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > Cory Benfield writes: > >> The TL;DR is: I understand Christian’s concern, but I don’t think >> it’s important if you’re very, very careful. > > But AIUI, t

Re: [Python-Dev] SSL certificates recommendations for downstreampython packagers

2017-02-01 Thread Cory Benfield
> On 1 Feb 2017, at 14:20, Steve Dower wrote: > > Sorry, I misspoke when I said "certificate validation callback", I meant the > same callback Cory uses below (name escapes me now, but it's unfortunately > similar to what I said). There are two callbacks in OpenSSL,

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

2017-02-01 Thread Cory Benfield
> On 31 Jan 2017, at 18:26, Steve Dower wrote: > > In short, I want to allow Python code to set OpenSSL's certificate validation > callback. Basically, given a raw certificate, return True/False based on > whether it should be trusted. I then have separate code (yet to

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

2017-01-31 Thread Cory Benfield
> On 31 Jan 2017, at 09:56, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 31 January 2017 at 09:19, Cory Benfield <c...@lukasa.co.uk> wrote: >> >> In general, it is unwise to mix trust stores. If you want to use your OS’s >> trust store, the best approa

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

2017-01-31 Thread Cory Benfield
> On 31 Jan 2017, at 09:33, Christian Heimes wrote: > > One small correction, it is possible to export some of the trust > settings to a TRUSTED CERTIFICATE and import them into OpenSSL. It works > correctly in 1.0.1 and since 1.0.2e or f. Trust settings are stored in >

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

2017-01-31 Thread Cory Benfield
> On 30 Jan 2017, at 21:00, David Cournapeau <courn...@gmail.com> wrote: > > > > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <c...@lukasa.co.uk > <mailto:c...@lukasa.co.uk>> wrote: > > > > On 30 Jan 2017, at 13:53, David Cournapeau <

Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

2017-01-30 Thread Cory Benfield
> On 30 Jan 2017, at 13:53, David Cournapeau wrote: > > Are there any official recommendations for downstream packagers beyond PEP > 476 ? Is it "acceptable" for downstream packagers to patch python's default > cert locations ? There *are* no default cert locations on

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Cory Benfield
> On 16 Dec 2016, at 16:07, Ethan Furman wrote: > > On 12/16/2016 11:24 AM, Guido van Rossum wrote: > >> I am beginning to think that `from __future__ import unicode_literals` does >> more harm than good. I don't recall exactly why we introduced it, but with >> the

Re: [Python-Dev] Supported versions of OpenSSL

2016-08-30 Thread Cory Benfield
> On 30 Aug 2016, at 16:07, M.-A. Lemburg wrote: > > That was not my point. It's unfortunate that Python depends on > a library which is inevitably going to need updates frequently, > and which then may have the implication that Python won't compile on > systems which don't

Re: [Python-Dev] Supported versions of OpenSSL

2016-08-29 Thread Cory Benfield
> On 29 Aug 2016, at 15:31, M.-A. Lemburg wrote: > > Ubuntu 14.04 is a widely deployed system and newer Python version > should run on such widely deployed systems without having to > replace important vendor maintained system libraries such as > OpenSSL. That's quite the

Re: [Python-Dev] Supported versions of OpenSSL

2016-08-29 Thread Cory Benfield
> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > > On 28.08.2016 22:40, Christian Heimes wrote: >> ... >> I like to reduce the maintenance burden and list of supported OpenSSL >> versions ASAP. OpenSSL has deprecated 0.9.8 and 1.0.0 last year. 1.0.1 >> will reach EOL by the

Re: [Python-Dev] Supported versions of OpenSSL

2016-08-28 Thread Cory Benfield
> On 28 Aug 2016, at 16:40, Christian Heimes wrote: > > For upcoming 3.6 I would like to limit support to 1.0.2+ and require > 1.0.2 features for 3.7. What is the status of Python.org's OSX builds? > Is it possible to drop 0.9.8? I strongly support this change. Python

Re: [Python-Dev] security SIG? (was: Discussion overload)

2016-06-18 Thread Cory Benfield
> On 18 Jun 2016, at 04:06, Brett Cannon wrote: > > Do we need a security SIG? E.g. would people like Christian and Cory like to > have a separate place to talk about the ssl stuff brought up at the language > summit? Honestly, I’m not sure what we would gain. Unless that

Re: [Python-Dev] security SIG? (was: Discussion overload)

2016-06-18 Thread Cory Benfield
> On 18 Jun 2016, at 11:38, Stephen J. Turnbull wrote: > > I see the security issue as a backyard swimming pool. The law may say > you must put a fence around it, but even 6 year olds can climb the > fence, fall in the pool, and drown. The hard-line security advocate >

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-16 Thread Cory Benfield
> On 16 Jun 2016, at 09:19, Stefan Krah wrote: > > This should only concern code that a) was specifically written for > 3.5.0/3.5.1 and b) implements a serious cryptographic application > in Python. > > I think b) is not a good idea anyway due to timing and side channel >

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-12 Thread Cory Benfield
> On 12 Jun 2016, at 14:43, Theodore Ts'o wrote: > > Well, it can only happen on Linux because you insist on falling back > to /dev/urandom --- and because other OS's have the good taste not to > use systemd and/or Python very early in the boot process. If someone > tried to run

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-12 Thread Cory Benfield
> On 12 Jun 2016, at 07:11, Theodore Ts'o wrote: > > On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: >> >> It was a RaspberryPI that ran a shell script on boot that called >> ssh-keygen. That shell script could have just as easily been a >> Python script that

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-11 Thread Cory Benfield
> On 11 Jun 2016, at 09:24, Larry Hastings wrote: > Only Linux and OS X have never-blocking /dev/urandom. On Linux, you can > choose to block by calling getrandom(). On OS X you have no choice, you can > only use the never-blocking /dev/urandom. (OS X also has a

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-09 Thread Cory Benfield
> On 9 Jun 2016, at 14:48, Doug Hellmann wrote: > > I agree those are the two options. I want the application developer to make > the choice, not us. Right, but right now those two options aren’t available: only one of them is. And one way or another we’re taking an

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-09 Thread Cory Benfield
> On 9 Jun 2016, at 13:53, Doug Hellmann wrote: > > I agree with David. We shouldn't break existing behavior in a way > that might lead to someone else's software being unusable. What does ‘usable’ mean? Does it mean “the code must execute from beginning to end”? Or

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

2016-06-09 Thread Cory Benfield
> On 9 Jun 2016, at 12:54, Christian Heimes wrote: > > Therefore I propose to fix problem 2 and 3: > > - add a new random_seed member to _Py_HashSecret and use it to derive an > initial Mersenne-Twister state for the default random instance of the > random module. > > -

Re: [Python-Dev] New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL

2016-03-15 Thread Cory Benfield
> On 15 Mar 2016, at 01:08, Jim Baker wrote: > > I have no vested interest in this, other than the continuing work we have > done to make Jython compatible with OpenSSL's model, warts and all. > > But the fact that BoringSSL cleans up the OpenSSL API >

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

2016-02-24 Thread Cory Benfield
> On 24 Feb 2016, at 12:19, M.-A. Lemburg <m...@egenix.com> wrote: > > On 24.02.2016 12:28, Cory Benfield wrote: >> >>> On 24 Feb 2016, at 10:32, Nick Coghlan <ncogh...@gmail.com> wrote: >>> >>> Security Considerations >>> -

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

2016-02-24 Thread Cory Benfield
> On 24 Feb 2016, at 10:32, Nick Coghlan wrote: > > Security Considerations > --- > > Relative to the behaviour in Python 3.4.3+ and Python 2.7.9->2.7.11, this > approach does introduce a new downgrade attack against the default security > settings that

Re: [Python-Dev] dynamic linking, libssl.1.0.0.dylib, libcrypto.1.0.0.dylib and Mac OS X

2015-12-24 Thread Cory Benfield
> On 24 Dec 2015, at 11:17, Chris Withers wrote: > > Hi All, > > Here's a couple of examples of this problem in the wild: > > https://github.com/alekstorm/backports.ssl/issues/9 >

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

2015-11-27 Thread Cory Benfield
> On 27 Nov 2015, at 06:04, Nick Coghlan wrote: > > Feature: Configuration API > == > > This change is proposed for inclusion in CPython 2.7.12 and later CPython > 2.7.x > releases. It consists of a new ``ssl._verify_https_certificates()`` to

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

2015-11-25 Thread Cory Benfield
> On 24 Nov 2015, at 12:53, Christian Heimes wrote: > Right, with Antoine and Alex out of scope and you, Victor and me working > for Red Hat, the air is getting thin. Benjamin is familiar with the ssl > module. Or we can follow Alex's advice and ask somebody from the PyCA >

Re: [Python-Dev] Python stdlib ssl.SSLContext is missing mode setting ability

2015-11-19 Thread Cory Benfield
> On 19 Nov 2015, at 03:53, Ben Bangert wrote: > > In Python 2 and 3, the ssl module's SSLContext object has a way to set > SSL options, but not to set SSL modes. > > The set_mode command and some of the available modes: >

Re: [Python-Dev] Python stdlib ssl.SSLContext is missing mode setting ability

2015-11-19 Thread Cory Benfield
> On 19 Nov 2015, at 15:26, Ben Bangert wrote: > > I can't think of any other mode to set, setting this with the > condition cited for that vulnerability looks like a good idea. > > Cheers, > Ben Ok, we’re agreed. The work can be tracked under Issue 25672:

Re: [Python-Dev] typeshed for 3rd party packages

2015-04-24 Thread Cory Benfield
On 24 April 2015 at 15:21, Steven D'Aprano st...@pearwood.info wrote: If the type hints are wrong, there are two errors: false positives, when code which should be allowed is flagged as a type error; and false negatives, when code which should be flagged as an error is not. Ideally, there

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-22 Thread Cory Benfield
On 21 April 2015 at 18:12, Steven D'Aprano st...@pearwood.info wrote: I expect that dealing with duck typing will be very high on the list of priorities for the future. In the meantime, for this specific use-case, you're probably not going to be able to statically check this type hint. Your

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-22 Thread Cory Benfield
On 21 April 2015 at 17:59, Guido van Rossum gu...@python.org wrote: For me, PEP 484 is a stepping stone. Among the authors of PEP 484 there was much discussion about duck typing, and mypy even has some limited support for duck typing (I think you can still find it by searching the mypy code

Re: [Python-Dev] typeshed for 3rd party packages

2015-04-22 Thread Cory Benfield
On 22 April 2015 at 11:46, M.-A. Lemburg m...@egenix.com wrote: Unlike with translations, where missing or poor ones don't have much effect on the usefulness of the software, a type checker would complain loudly and probably show lots of false positives (if you read a type bug as positive),

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-21 Thread Cory Benfield
On 21 April 2015 at 01:45, Chris Angelico ros...@gmail.com wrote: When you're writing a library, it can be a great help to provide type annotations, because every application that uses your library can benefit. It can be a great help to whom? Not to me (the library author), because I can't use

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-21 Thread Cory Benfield
On 21 April 2015 at 12:23, Gustavo Carneiro gjcarne...@gmail.com wrote: Documentation is not checked. It often loses sync with the actual code. Docs say one thing, code does another. Agreed. I don't think anyone would disagree here. I'm talking from the position of being a library author,

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-21 Thread Cory Benfield
On 21 April 2015 at 10:10, Chris Angelico ros...@gmail.com wrote: At this point, you may want to just stop caring about the exact type. Part of the point of gradual typing is that you can short-cut a lot of this. And quite frankly, this isn't really helping anything. Just skip it and say that

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-21 Thread Cory Benfield
On 21 April 2015 at 15:31, Chris Angelico ros...@gmail.com wrote: Granted, there are some vague areas - how many functions take a file-like object, and are they all the same? - but between MyPy types and the abstract base types that already exist, there are plenty of ways to formalize duck

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-21 Thread Cory Benfield
On 21 April 2015 at 16:09, Chris Angelico ros...@gmail.com wrote: Pretty accurate, yeah. Here's how I see it: def incremental_parser(input: FileLike) - List[Token]: tokens = [] data = while True: if not data: data = input.read(64) token =

Re: [Python-Dev] http.client: Determining Content-Length

2015-04-01 Thread Cory Benfield
On 31 March 2015 at 17:55, Demian Brecht demianbre...@gmail.com wrote: Hi all, I'm not sure whether this should be python-list or here, but given it's a premature code review for http.client, I figured I'd post here first. I'm in the process of adding support for chunked transfer encoding

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

2014-09-08 Thread Cory Benfield
On 8 September 2014 18:23, Jim J. Jewett jimjjew...@gmail.com wrote: Summary: There needs to be a simple way to opt out at install time. It would be far better to offer more fine-grained control, but leaving that better solution to downstream is acceptable. Does this argument apply to a

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

2014-09-03 Thread Cory Benfield
On 3 September 2014 01:19, Antoine Pitrou solip...@pitrou.net wrote: Keeping saying it doesn't make it magically true. Sure, but it *is* true, at the very least for HTTP. RFC 2818 (HTTP over TLS) has the following language in section 3.1: If the hostname is available, the client MUST check it

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

2014-08-31 Thread Cory Benfield
On 31 August 2014 07:45, Nick Coghlan ncogh...@gmail.com wrote: There's also the fact that most corporate Python users are unlikely to know that PyPI exists, let alone that it contains a module called requests that does SSL certificate validation by default. Those of us in the corporate world

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

2014-06-18 Thread Cory Benfield
On 17 June 2014 17:41, Yates, Andy (CS Houston, TX) aya...@hp.com wrote: Is it possible to drop in new OpenSSL versions on Windows without rebuilding Python? If you think this is a problem you're going to have more than once, you'll want to look hard at whether it's worth using pyOpenSSL

Re: [Python-Dev] PEP 466 (round 5): selected network security enhancements for Python 2.7

2014-03-26 Thread Cory Benfield
Nick, On 26 March 2014 12:00, Nick Coghlan ncogh...@gmail.com wrote: As one example, the Python 2 ``ssl`` module does not support the Server Name Identification standard. Tiny note: SNI is 'Server Name Indication', not 'Identification'. =) Otherwise, I'm +1 on this as well.

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

2014-03-25 Thread Cory Benfield
On 25 March 2014 08:26, Chris Angelico ros...@gmail.com wrote: Exactly the same. If someone wants to distribute SEPython (that someone might be python.org itself, or ActiveState, or anyone else who has an interest in it), they're welcome to do so; and it could be done either as an all-in-one

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

2014-03-25 Thread Cory Benfield
On 24 March 2014 19:37, Chris Angelico ros...@gmail.com wrote: The opting in could be done at the distro level. Red Hat could ship a thing called /usr/bin/python that runs SEPython, and that package could be identified and numbered in such a way that it's clearly a drop-in replacement for

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

2014-03-25 Thread Cory Benfield
On 25 March 2014 09:01, Chris Angelico ros...@gmail.com wrote: So by that model, current 2.7 is fully compliant, and anything that doesn't actively conflict with that is also compliant. Any script that is written for the current 2.7 is guaranteed also to run on any compliant SEPython; and

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

2014-03-24 Thread Cory Benfield
On 24 March 2014 08:44, Nick Coghlan ncogh...@gmail.com wrote: The position I am coming to is that the enhanced security release should be the default one that we publish binary installers for, but we should also ensure that downstream redistributors can easily do Python 2.7 with legacy SSL

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

2014-03-23 Thread Cory Benfield
On 23 March 2014 at 04:32:17, Terry Reedy (tjre...@udel.edu(mailto:tjre...@udel.edu)) wrote: Instead, I think the PEP should propose a special series of server enhancement releases that are based on the final 2.7 maintenance release (2.7.8 or 2.7.9) but which have have a different

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

2014-03-22 Thread Cory Benfield
On 22 March 2014 at 21:11:24, Nick Coghlan (ncogh...@gmail.com(mailto:ncogh...@gmail.com)) wrote: Folks, I have just posted a proposal to change the way we treat enhancements that relate to Python's support for network security enhancements. I now see these as categorically different from

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

2014-01-24 Thread Cory Benfield
On 24 January 2014 03:06, Stephen J. Turnbull step...@xemacs.org wrote: Are you kidding? These *aren't* the apps that I care about breaking, and I know that the PHBs won't pay attention to what I say about fixing their sites and cert chains (believe me, I've tried, and the answer is as Paul

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

2014-01-24 Thread Cory Benfield
On 23 January 2014 08:37, Stephen J. Turnbull step...@xemacs.org wrote: I don't know what the right answer is, but this needs careful discussion and amelioration, not just you're broken, so take the consequences! Absolutely. =) With that said, having a great big button to turn the change off

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

2014-01-22 Thread Cory Benfield
Donald Stufft donald at stufft.io writes: I would like to propose that a backwards incompatible change be made to Python to make verification of hostname and certificate chain the default instead of requiring it to be opt in. I'm overwhelmingly, dramatically +1 on this. There's no good

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

2014-01-22 Thread Cory Benfield
On 22 January 2014 10:30, Donald Stufft don...@stufft.io wrote: I would like to propose that a backwards incompatible change be made to Python to make verification of hostname and certificate chain the default instead of requiring it to be opt in. I'm overwhelmingly, dramatically +1 on this.