GHC 2018-02-07

5 comments.
, https://git.io/vAUkp in jarun/ddgr 
Yeah, native is the best.
, https://git.io/vAUkh in jarun/ddgr 
Yes. In fact,

```py
subprocess.Popen(
    command_args, 
    stdin=subprocess.PIPE,
    stdout=subprocess.DEVNULL,
    stderr=subprocess.DEVNULL,
).communicate(string.encode('utf-8'))
```
, https://git.io/vAUkj in jarun/ddgr 
My point is exactly to pass the URL into stdin to eliminate any shell-related issues (no need to encode the URL, just treat it as an opaque string).
, https://git.io/vAUIe in jarun/ddgr 
@jarun Sorry, I indeed missed this among the hundreds of unread emails piling up in my inbox.

This should probably work 100% of the time in practice (except the win32 part, I don't really know win32 quoting rules), yes, so what I'm going to discuss is mostly theoretical, but you may want to hear about it nonetheless.

First, feeding strings from untrusted sources into a shell is always a big security issue. Let's say we put googler behind a rogue proxy, which manipulates the HTML so that we end up with a URL that look like `blah blah'; rm -rf ~; echo 'haha pwned`. Feed that into your `os.system` and bam! (DO NOT TRY.)

Secondly, even if we ignore the security implications, U+0027 APOSTROPHE (`'`) is a valid URI character per RFC 3986, among sub-delims [1], so there's a legit chance you'll run into an URI with an apostrophe and get an error:

```
sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file
```

Now, Google just might always percent-encode the apostrophe, but I can't be certain about that. According to RFC 3986 on normalization [2], since the apostrophe is a reversed character, it is not equivalent to its percent-encoded counterpart, at least not according to the spec. There's also the WHATWG URL Spec [3], which is too mechanical for me to grasp in a glance, but according to jsdom/whatwg-url [4], which claims to be a faithful implementation of the spec, `'` and `%27` do not appear equivalent [5] either; just try the following code in https://npm.runkit.com/whatwg-url:

```js
let { parseURL, serializeURL } = require("whatwg-url")
// should see: false
serializeURL(parseURL("http://example.com/'")) == serializeURL(parseURL("http://example.com/%27"))
```

So you see my concerns with the shell usage.

[1] https://tools.ietf.org/html/rfc3986#section-2.2
[2] https://tools.ietf.org/html/rfc3986#section-6.2.2
[3] https://url.spec.whatwg.org/
[4] https://github.com/jsdom/whatwg-url
[5] https://url.spec.whatwg.org/#url-equivalence
, https://git.io/vAvQG in Homebrew/homebrew-core 
@ilovezfs 

> so that still leaves open the question why this isn't a problem for Python 3.x. Were further changes made to computed gotos stuff in Python 3.x that haven't been backported?

Not sure, computed gotos has been in the Python 3 branch since the py3k days and was first included in v3.1. See https://github.com/python/cpython/commit/b52ec78baf236272800017fdb2b7f243741c1851. [CPython core developer](https://bugs.python.org/issue32616#msg311751) is puzzled by this too.

@bartekrutkowski 

> Are they still going to release another Python2 version with fixes? If so, this issue should be fixed in the upstream to not keep a temporary special case here. However, I remember (but cannot confirm) that the 2.7.14 was supposed to be the last release? If so, it's on the homebrew side to fix it even if temporary.

As a downstream packager we can enable non-default flags or even carry long term patches at our discretion. That's not really a problem. Also, Python 2.7 still has two years of lifespan, and there will be a 2.7.15 in 2018. See [PEP 373](https://www.python.org/dev/peps/pep-0373/).