user/brade/meek, branch bug25405-01

Bug 25405: cannot use Moat if a meek bridge is configured

2018-03-26T15:52:22+00:00

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

Update server shutdown procedure.

2018-03-21T07:32:17+00:00

Ignore SIGINT, honor TOR_PT_EXIT_ON_STDIN_CLOSE.

Exit immediately after SIGTERM is there are no signals running.

2018-03-21T07:32:17+00:00

The logic erroneously assumed that there was at least one handler
running at the time a signal was received. If there was not, it would
wait forever for something handler-related to happen.

https://bugs.torproject.org/24875

Update programVersion = "0.30".

2018-03-07T06:45:23+00:00

Regen man pages.

2018-03-07T03:39:01+00:00

Use autocert Manager.HTTPHandler (ACME HTTP-01 challenge)

2018-03-07T03:39:01+00:00

The former TLS-SNI challenge type is gone.
https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5a55777ed9a9c1024c00b241

The new HTTP-01 challenge type requires a listener on port 80. The
former TLS-SNI challenge just piggybacked on an additional HTTPS
listener on port 443, if necessary. The new listener on port 80 just
handles ACME business and nothing else.

https://bugs.torproject.org/24928

Minor man page enhancements.

2018-03-07T03:17:21+00:00

Update programVersion = "0.29".

2018-02-16T06:16:47+00:00

Have meek-client-torbrowser give meek-client a stdin that doesn't close.

2018-02-16T06:16:12+00:00

https://bugs.torproject.org/24642

Running meek-client-torbrowser with the environment variable
TOR_PT_EXIT_ON_STDIN_CLOSE=1 would cause meek-client to exit
immediately, as it sensed that its stdin was closed.
meek-client-torbrowser was running the meek-client subprocess with a nil
Stdin, which causes its stdin to be /dev/null (or NUL on Windows), which
returns an immediate EOF. So instead, give meek-client an StdinPipe and
just keep it open. (We could alternatively keep track of it and close it
when necessary, but that would take further refactoring.)

The commit where things would have first broken was
0ec986eb2b4bc23d81e6e8beffd382890f55bfb1 (part of tag 0.28), which
added TOR_PT_EXIT_ON_STDIN_CLOSE awareness to meek-client. But it was
not meek-client's fault.

This bug did not affect any releases of Tor Browser, despite that on
Windows we unconditionally set TOR_PT_EXIT_ON_STDIN_CLOSE=1 via
terminateprocess-buffer, because Tor Browser is still using tag 0.25,
which doesn't have the TOR_PT_EXIT_ON_STDIN_CLOSE change in meek-client.

Show an error when missing a meek-client command line.

2018-01-11T21:04:34+00:00

Running meek-client-torbrowser without arguments would panic as it tried
to index the nonexistent arguments.

2018/01/11 21:02:07 running firefox command ["firefox" "--invisible" "-no-remote" "-profile" "TorBrowser/Data/Browser/profile.meek-http-helper"]
2018/01/11 21:02:07 firefox started with pid 23721
2018/01/11 21:02:08 killing PID 23721
panic: runtime error: index out of range

goroutine 1 [running]:
panic(0x4e95a0, 0xc42000a110)
        /usr/lib/go-1.7/src/runtime/panic.go:500 +0x1a1
main.runMeekClient(0xc420010589, 0xf, 0xc42000a2c0, 0x0, 0x0, 0x0, 0x10, 0xc42000e440)
        meek-client-torbrowser.go:267 +0x416
main.main()
        meek-client-torbrowser.go:354 +0x3d2