GHC 2016-11-24

2016-11-24 17:51:03, https://git.io/v1KUW in jarun/googler

Can't even reproduce with 3.6.0b4 on Ubuntu 12.04.

```python
import socket
import ssl
sock = socket.create_connection(('www.google.com', 443))
context = ssl.SSLContext(ssl.PROTOCOL_TLS)
context.options |= ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3 | ssl.OP_NO_TLSv1 | ssl.OP_NO_TLSv1_1
context.wrap_socket(sock)
```

yields

```
<ssl.SSLSocket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('10.0.2.15', 39931), raddr=('172.217.0.36', 443)>
```

For the record, Travis is using Ubuntu 12.04 with OpenSSL 1.0.1 from Mar 2012, where TLS 1.1/1.2 support might be incomplete (?):

```
$ openssl ciphers -v TLSv1
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
...
$ openssl ciphers -v TLSv1.1
Error in cipher list
140276711921312:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1173:
$ openssl ciphers -v TLSv1.2
Error in cipher list
140509283358368:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1173:
```

I guess let's revert this and worry about it later.

2016-11-24 17:05:33, https://git.io/v1KU8 in jarun/googler

That's weird, can't reproduce locally. Do they have some sort of openssl linking issue?

2016-11-24 16:54:27, https://git.io/v1KqT in jarun/googler

.travis.yml: add 3.6-dev to the matrix
======================================

Python 3.6 is less than one month from release. Time to add 3.6 to the matrix.

2016-11-24 16:46:27, https://git.io/v1Kqk in jarun/googler

googler: revamp TLS 1.2 support
===============================

OpenSSL has deprecated all version specific protocols. As such, version
specific protocols including PROTOCOL_TLSv1_2 have been deprecated in
Python since 3.5.3. PROTOCOL_TLS coupled with SSLContext options to
disable older protocol versions is the new way to go. See
https://docs.python.org/3.5/library/ssl.html#ssl.PROTOCOL_TLSv1_2 and
https://docs.python.org/3.5/library/ssl.html#protocol-versions.

We are now using feature test (hasattr) instead of version test which is
generally preferred.

Also, key_file and cert_file code has been removed since they're None
anyway (they are only set when key_file and cert_file are passed to
HTTPSConnection, something we don't have).

2016-11-24 16:19:53, https://git.io/v1KU4 in jarun/googler

Except it hurts newcomers' perception of the language when it's in a supposedly popular tutorial for beginners (of dubious quality). You don't see K&R dissing ANSI C or C99. To quote eevee,

> it’s complete and utter nonsense, on a platform aimed at people who can’t yet recognize it as nonsense. I am so mad.

I'm as mad as him.

2016-11-24 16:10:12, https://git.io/v1KUB in jarun/googler

Speaking of trends, have you seen the totally ludicrous https://learnpythonthehardway.org/book/nopython3.html posted less than two days ago? And a complete rebuttal https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/.

2016-11-24 15:48:47, https://git.io/v1KqI in jarun/googler

googler: fix tunneling in TLS1_2Connection
==========================================

`HTTPSConnection.connect` calls `self._tunnel` already when `self._tunnel_host` is set. (CPython 3.3.6, 3.4.5, 3.5.2, 3.6.0b4.) Ref: https://github.com/python/cpython/blob/3.3/Lib/http/client.py#L819-L824.

Fixes #146.

A quick comparison of `http/client.py` between the Py33 and Py34 branches doesn't tell me why the problem isn't seen on 3.4, though.

I still have reservations about using internals, but this is the quickest fix, for a code path that I don't care much about 😜.

2016-11-24 15:45:43, https://git.io/v1KU0 in jarun/googler

I took another look and found the fix.

> do you think this is the right time to move on to Python 3.5 and above?

Assuming you mean 3.4: I don't feel the urge to drop 3.3 support. 3.3 is a common target due to its good compatibility with 2.7; that's the reason we were targeting 3.3 in the first place IIRC. Of course it no longer matters, but we aren't using any 3.4+ feature other than TLS 1.2, which is optional.

However, if you feel like dropping it I won't object.

2016-11-24 15:00:15, https://git.io/v1KUE in Homebrew/homebrew-core

> TBH I don't know what ffmpeg needs those for.

FFmpeg supports a bunch of streaming protocols — RTMP and RTSP for instance — that may require TLS, among other things.

> Also, AFAIK --with-openssl is not the default, so why would it link with the system OpenSSL?

FFmpeg's configure autodetects many optional dependencies. However, I just checked and `--enable-openssl` defaults to `no`, so no need to worry about it.

2016-11-24 01:02:31, https://git.io/v1KUu in Homebrew/homebrew-core

Might be worth checking whether `/usr/lib/libssl.0.9.8.dylib` is linked when `--disable-securetransport` is specified. If it is, we might want to add `--disable-openssl` unless `--with-openssl` is specified.