Tor doesn't support this kind of proxy (https://bugs.torproject.org/26306),
but I want to support the same kinds of proxies with uTLS as are
supported using the native Go net/http, for ease of explaining the proxy
restrictions in the man page.

We use the same uTLS ClientHelloID for the TLS connection to the HTTPS
proxy, as we use for the TLS connection through the tunnel.

This adapts a technique that Yawning used in obfs4proxy for meek_lite:
https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3
https://lists.torproject.org/pipermail/tor-dev/2019-January/013633.html

It's activated by the new utls= SOCKS arg or --utls command line option.
The argument is the name of a uTLS ClientHelloID; e.g.,
HelloChrome_Auto. We omit HelloCustom (not useful externally),
HelloGolang (just don't use utls), and HelloRandomized (may negotiate
HTTP/1.1 or HTTP/2 at different times, which is incompatible with the
way the integration works).

When using HTTP/1, we copy default timeouts etc. from the Go
net/http.DefaultTransport. Unfortunately I don't know a way to do the
same for HTTP/2. Configuring an http.Transport and then calling
http2.ConfigureTransport on it doesn't work; it leads to the same
problem of an HTTP/1 client speaking to an HTTP/2 server.

We recognize utls=none and utls=HelloGolang as an alias for omitting
utls=. This is for compatibility with obfs4proxy meek_lite.
https://bugs.torproject.org/29077#comment:13

Let both their terminateTimeouts run concurrently.

First send it a SIGTERM; then kill it if that doesn't work. On Windows,
just kill it immediately without waiting.

First close its stdin and send SIGTERM; and then kill it if that doesn't
work. Set TOR_PT_EXIT_ON_STDIN_EOF=1 unconditionally in the subprocess.
On Windows it's the same, except don't send SIGTERM.

https://bugs.torproject.org/15125
https://bugs.torproject.org/25613

On Windows, I observed once that if meek-client.exe can't be found,
tor.exe and its child process terminateprocess-buffer.exe continued
running. I suspect terminateprocess-buffer was hung up in io.Copy--the
child process stdin pipe was closed, but as it has nothing to copy, it
couldn't detect the fact. Now have it do the stdin copy in a separate
goroutine, and also close the child stdin pipe explicitly.

This way, we still exit when the parent process dies, even if for
whatever reason Firefox doesn't give us a helper address.

https://bugs.torproject.org/29559

Since 0ec986eb. This is the case with
all pluggable transports now.

It causes an error when it uses something unsupported, like
username:password.

This was a regression added in 3fe68658.

socks5 since go1.9:
https://golang.org/doc/go1.9#net/http
https://github.com/golang/go/issues/18508
https://github.com/golang/go/commit/36f55a8b6125c9ae951487a0ad074b5c991f7b92

https since go1.10:
https://golang.org/doc/go1.10#net/http
https://github.com/golang/go/issues/11332
https://github.com/golang/go/commit/f5cd3868d52babd106e0509a67295690246a5252

As opposed to url= and front= SOCKS args.

The requirement to wait until handlers are finished, as well as the
complicated signal counting logic, was removed from pt-spec.txt in 2014.

https://bugs.torproject.org/26389

Compare
https://gitweb.torproject.org/pluggable-transports/goptlib.git/commit/?id=15f83653abbcced9003c96cc14edc5b2f82e0e0e

Copy them into an instance from the global settings, don't read the
global settings directly.

The previous path had an additional "devtools/":
resource://gre/modules/devtools/Console.jsm

The current documentation gives the path without "devtools/":
https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Console.jsm

The path seems to have changed in ESR58, thereby breaking the extension:
https://bugs.torproject.org/26118
https://bugs.torproject.org/26477#comment:2

Add support for a TOR_BROWSER_MEEK_PROFILE environment variable which,
if present, contains the path to the HTTP helper browser profile.

Ignore SIGINT, honor TOR_PT_EXIT_ON_STDIN_CLOSE.