Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:31:08Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20495Unexplained drop in meek users, 2016-10-19 to 2016-11-102020-06-13T18:31:08ZDavid Fifielddcf@torproject.orgUnexplained drop in meek users, 2016-10-19 to 2016-11-10There was a drop in bridge users on October 19 or 20, 2016:
![userstats-bridge-country-cn-2016-07-30-2016-10-28.png](uploads/userstats-bridge-country-cn-2016-07-30-2016-10-28.png) [link](https://metrics.torproject.org/userstats-bridge-co...There was a drop in bridge users on October 19 or 20, 2016:
![userstats-bridge-country-cn-2016-07-30-2016-10-28.png](uploads/userstats-bridge-country-cn-2016-07-30-2016-10-28.png) [link](https://metrics.torproject.org/userstats-bridge-country.html?start=2016-07-30&end=2016-10-28&country=cn)
The by-transport graph shows that almost all meek users disappeared:
![userstats-bridge-combined-cn-2016-07-30-2016-10-28.png](uploads/userstats-bridge-combined-cn-2016-07-30-2016-10-28.png) [link](https://metrics.torproject.org/userstats-bridge-combined.html?start=2016-07-30&end=2016-10-28&country=cn)https://gitlab.torproject.org/legacy/trac/-/issues/20290Upgrade meek to 0.242020-06-15T23:38:18ZDavid Fifielddcf@torproject.orgUpgrade meek to 0.24Version [0.24](https://gitweb.torproject.org/pluggable-transports/meek.git/log/?id=0.24) has a fix for #20030, which prevented meek-client-torbrowser from cleaning up is subprocesses when built with Go 1.6 or later.
Here's the diff from...Version [0.24](https://gitweb.torproject.org/pluggable-transports/meek.git/log/?id=0.24) has a fix for #20030, which prevented meek-client-torbrowser from cleaning up is subprocesses when built with Go 1.6 or later.
Here's the diff from the version we're using now. The only substantive changes are those that have to do with #20030.
https://gitweb.torproject.org/pluggable-transports/meek.git/diff/?id=0.24&id2=0.22-18371-3
A patch is forthcoming.https://gitlab.torproject.org/legacy/trac/-/issues/20250meek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.32021-03-27T04:55:11ZTracmeek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.3Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.
On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.
With 10.12,...Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.
On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.
With 10.12, (tested with admin and standard accounts), the initial tor connection UI completes, the browser opens and the initial meek connection is established. However, briefly after the browser window has opened with the successful about:tor page it is clear something is wrong. Monitoring internet traffic with a network monitor it is clear that the traffic to the meek server stops almost immediately after the browser has opened.
Having read some of the control port issues for other 10.12 users, I tested this issue with the extensions.torlauncher.control_port_use_socket pref set to false in prefs.js and without it, but it had no effect either way.
Attached are the tor, meek-client and meek-client-torbrowser logs. Really hope someone can help with this since meek is the only way to use tor in my country without having the police banging down the door.
Tor Log:
AUTHENTICATE <HASH>
250 OK
SETEVENTS STATUS_CLIENT NOTICE WARN ERR
250 OK
650 NOTICE Opening Socks listener on 127.0.0.1:9150
650 NOTICE Bootstrapped 5%: Connecting to directory server
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server"
650 NOTICE Bootstrapped 10%: Finishing handshake with directory server
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server"
650 NOTICE Bootstrapped 15%: Establishing an encrypted directory connection
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=15 TAG=onehop_create SUMMARY="Establishing an encrypted directory connection"
650 NOTICE Bootstrapped 20%: Asking for networkstatus consensus
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=20 TAG=requesting_status SUMMARY="Asking for networkstatus consensus"
650 NOTICE Bootstrapped 25%: Loading networkstatus consensus
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=25 TAG=loading_status SUMMARY="Loading networkstatus consensus"
650 STATUS_CLIENT NOTICE CONSENSUS_ARRIVED
650 STATUS_CLIENT NOTICE ENOUGH_DIR_INFO
650 NOTICE Bootstrapped 80%: Connecting to the Tor network
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=80 TAG=conn_or SUMMARY="Connecting to the Tor network"
650 NOTICE Bootstrapped 90%: Establishing a Tor circuit
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=90 TAG=circuit_create SUMMARY="Establishing a Tor circuit"
650 NOTICE Tor has successfully opened a circuit. Looks like client functionality is working.
650 NOTICE Bootstrapped 100%: Done
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"
650 STATUS_CLIENT NOTICE CIRCUIT_ESTABLISHED
650 NOTICE New control connection opened from 127.0.0.1.
650 NOTICE New control connection opened from 127.0.0.1.
#NOTICE THE LINE BELOW:
650 WARN The connection to the SOCKS4 proxy server at 127.0.0.1:57343 just failed. Make sure that the proxy server is up and running.
650 NOTICE Delaying directory fetches: No running bridges
650 NOTICE Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)
meek-client log:
0:05 using helper on 127.0.0.1:49193
0:05 listening on 127.0.0.1:49196
0:33 using helper on 127.0.0.1:49199
0:33 listening on 127.0.0.1:49202
meek-client-torbrowser log:
0:00 running firefox command ["/Applications/TorBrowser.app/Contents/MacOS/firefox" "--invisible" "-no-remote" "-profile" "/Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper"]
0:00 firefox started with pid 3644
0:01 running meek-client command ["PluggableTransports/meek-client" "--log" "meek-client.txt" "--helper" "127.0.0.1:49193"]
0:01 meek-client started with pid 3646
0:27 sig terminated
0:27 sending signal terminated to PID 3646
0:27 killing PID 3646
0:27 killing PID 3644
0:32 running firefox command ["/Applications/TorBrowser.app/Contents/MacOS/firefox" "--invisible" "-no-remote" "-profile" "/Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper"]
0:32 firefox started with pid 3660
0:33 running meek-client command ["PluggableTransports/meek-client" "--log" "meek-client.txt" "--helper" "127.0.0.1:49199"]
0:33 meek-client started with pid 3661
1:00 sig terminated
1:00 sending signal terminated to PID 3661
1:00 killing PID 3661
1:00 killing PID 3660
**Trac**:
**Username**: tordevSZ0David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/19732"Tor circuit for this site" labels meek bridge as being in China2020-06-15T23:36:49ZDavid Fifielddcf@torproject.org"Tor circuit for this site" labels meek bridge as being in ChinaTor Browser 6.5a1
I configured meek-azure in Torbutton. The circuit display shows "China" for the country of the bridge.
![meek-azure-geoip-china.png](uploads/meek-azure-geoip-china.png)
IIRC it used to say "Unknown". Maybe there is a g...Tor Browser 6.5a1
I configured meek-azure in Torbutton. The circuit display shows "China" for the country of the bridge.
![meek-azure-geoip-china.png](uploads/meek-azure-geoip-china.png)
IIRC it used to say "Unknown". Maybe there is a geoip lookup error for the 0.0.2.0 dummy bridge address.https://gitlab.torproject.org/legacy/trac/-/issues/19646Mac OS: wrong location for meek browser profile2020-06-13T18:32:26ZMark SmithMac OS: wrong location for meek browser profileWith Tor Browser 6.0 and newer, Meek is not working at all for some Mac OS users. Anonymous said on https://blog.torproject.org/blog/tor-browser-60-released:
Note to all OSX users encountering similar error: make sure before upgrade/cle...With Tor Browser 6.0 and newer, Meek is not working at all for some Mac OS users. Anonymous said on https://blog.torproject.org/blog/tor-browser-60-released:
Note to all OSX users encountering similar error: make sure before upgrade/clean install for 6.0+ that user installing has sudo privileges. TorBrowser needs write access to /Applications/TorBrowser-Data/ which will fail unless the user is an administrator. sudo privileges can be removed after installation and first run without problems.
Kathy and I were able to reproduce this problem on Mac OS 10.11.5 using a clean install of Tor Browser 6.0 (placed in /Applications) when logged in as a non-admin user.
The problem is that the meek-client-torbrowser code that creates the Meek browser profile does not account for the fact that the user data should be stored under ~/Library/Application Support/TorBrowser-Data when the browser is in /Applications. In fact, Meek works correctly when running as a privileged (admin) user, but the Meek helper profile is incorrectly placed under /Applications/TorBrowser-Data/ (the main browser profile is correctly placed under ~/Library/Application Support/TorBrowser-Data).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/19487Meek and ReachableAddresses2020-06-13T14:58:55ZcypherpunksMeek and ReachableAddressesThis came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `Fasci...This came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `FascistFirewall`. While the ports they can reach might be set correctly, when using `meek` `tor` sees the destination address as a fake destination. You end up with a log that looks like this:
```
NOTICE: Bridge at '0.0.2.0:1' isn't reachable by our firewall policy. Skipping.
```
This happens because they haven't defined `0.0.2.0:1` as being a reachable address, while in reality it's using (most likely) port 443 on some CDN, which might actually be defined reachable.
Maybe not a common issue but an interesting edge case that may be clarified, avoided, or documented somewhere.Tor: unspecifiedDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/18611Improve semantics for pluggable transports with dummy addresses2020-06-13T14:55:20ZteorImprove semantics for pluggable transports with dummy addressesIn #18517, we noted that some pluggable transports (for example, meek) use a dummy IP address in the bridge line, because the actual addresses are specified using some other method.
The address specified in the bridge line is passed by ...In #18517, we noted that some pluggable transports (for example, meek) use a dummy IP address in the bridge line, because the actual addresses are specified using some other method.
The address specified in the bridge line is passed by tor to the pluggable transport, which then ignores it. But there's no way for tor to know whether the address is going to be ignored.
Ignoring an address has a number of implications:
* there's no standard IPv4 or IPv6 "dummy" address
* even if two bridge lines use the same "dummy" address and port, bridge_resolve_conflicts should not consider them to be conflicting
(Are there any more?)
* anything that checks the address of the bridge will return erroneous results
I'm not sure there's any easy way of fixing this, but I'm writing it down so we know about it. Perhaps it needs a change to the semantics of the bridge line so we can leave out address and port if they're going to be ignored anyway.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18585Cannot specify custom meek bridges2020-06-13T05:03:43ZcypherpunksCannot specify custom meek bridgesOrbot should allow custom meek bridges to be defined in the bridges settings menu. The default bridges are expensive and rate-limited. Orbot needs to start the `ClientTransportPlugin meek_lite` transport when there is a meek bridge line....Orbot should allow custom meek bridges to be defined in the bridges settings menu. The default bridges are expensive and rate-limited. Orbot needs to start the `ClientTransportPlugin meek_lite` transport when there is a meek bridge line.
A patch is attached.Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/18517meek is broken in Tor Browser 6.0a32022-03-22T13:25:53ZGeorg Koppenmeek is broken in Tor Browser 6.0a3meek does not work any longer in Tor Browser 6.0a3. It seems this is caused by an underlying bug in tor. After some amount of testing and bisecting commit 23b088907fd23da417f5caf2b7b5f664f317ef4a is the first that introduces the new beha...meek does not work any longer in Tor Browser 6.0a3. It seems this is caused by an underlying bug in tor. After some amount of testing and bisecting commit 23b088907fd23da417f5caf2b7b5f664f317ef4a is the first that introduces the new behavior. Trying to start meek with it results in
```
Mar 10 13:50:53.000 [notice] Ignoring directory request, since no bridge nodes are available yet.
Mar 10 13:50:54.000 [notice] Delaying directory fetches: No running bridges
```
and nothing thereafter: the startup is stalled.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18167Don't trust "bridge-ips" blindly for user number estimates2020-06-13T18:09:04ZKarsten LoesingDon't trust "bridge-ips" blindly for user number estimatesI think I found a bug in the user number estimates that led to the [confusion on #13171](https://trac.torproject.org/projects/tor/ticket/13171#comment:14).
When I developed the [algorithm for estimating user numbers](https://research.to...I think I found a bug in the user number estimates that led to the [confusion on #13171](https://trac.torproject.org/projects/tor/ticket/13171#comment:14).
When I developed the [algorithm for estimating user numbers](https://research.torproject.org/techreports/counting-daily-bridge-users-2012-10-24.pdf), bridges only reported how many directory requests they responded to (`"dirreq-v3-resp"`), but not how these directory requests were distributed to countries (`"dirreq-v3-reqs"`). What they did report was how many different IP addresses by country connected to the bridge (`"bridge-ips"`). The goal back then was to provide better user numbers per country, so I put in the assumption that the geographic distributions of directory responses and connecting IP addresses would be roughly the same. And I think that assumption is still valid for most cases.
However, the meek version _before_ the #13171 fix broke this assumption. Here's an example from a meek bridge that didn't have this fix yet (descriptor digest `462a2bcc..`):
```
extra-info UtahMeekBridge 88F745840F47CE0C6A4FE61D827950B06F9E4534
published 2015-12-09 22:53:48
dirreq-v3-resp ok=17656,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=6160,busy=0
bridge-ips de=16,cn=8,us=8
```
It's rather unlikely that 17656 responses were sent back to 32 IP addresses or less. Still, following the assumption above, we're saying that half of those 17656 responses were sent back to Germany and one quarter each to China and the U.S.A., and that seems dangerously wrong.
I'm going to attach a scatter plot in a minute, `dirreq-resp-by-bridge-ips-2016-01-27.png`, that puts the numbers of `"dirreq-v3-resp ok=..."` and `"bridge-ips"` in relation for statistics reported between December 1, 2015 and last week. The two meek bridges `88F7..` and `AA03..` stand out quite a bit there as clusters close to the y axis.
I have a few possible fixes in mind. The first part would be to ignore all statistics where 1 unique IP address was reported to make, say, 10 directory requests or more. That would remove all dots to the left of the dashed line in the graph.
The second part of the fix would be to switch from combining `"dirreq-v3-resp"` and `"bridge-ips"` numbers and instead use reported distributions of directory requests to countries (`"dirreq-v3-reqs"`) that were not available 3.5 years ago. But [starting roughly 2 years ago](https://trac.torproject.org/projects/tor/ticket/5824#comment:17), these statistics are being published by more and more bridges.
Here's a descriptor (`fe171d40..`) that was published last week by the same bridge as above, now named `MeekGoogle`, which was after the meek-specific #13171 fix:
```
extra-info MeekGoogle 88F745840F47CE0C6A4FE61D827950B06F9E4534
published 2016-01-22 13:11:10
dirreq-v3-reqs us=7200,ru=1576,de=1520,[..],cn=88,[..]
dirreq-v3-resp ok=22016,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=6016,busy=0
bridge-ips us=3016,ru=632,gb=536,de=528,[..],cn=40,[..]
bridge-ip-versions v4=8752,v6=64
bridge-ip-transports <OR>=8,meek=8808
```
I'm attaching a second scatter plot, `dirreq-resp-by-dirreq-reqs-2016-01-27.png`, that compares the numbers of `"dirreq-v3-resp ok=..."` to `"dirreq-v3-reqs"`. The correlation is close to linear, which makes sense, because the number of directory requests should roughly match the number of directory responses. I think we can make the user number estimates a bit more accurate by making this switch. We would still fall back to `"bridge-ips"` if `"dirreq-v3-reqs"` is empty, but that would mostly affect older statistics.
Part three of the plan would be to remove the `"bridge-ips"` line entirely from little-t-tor, because we wouldn't use it anymore. It's worth noting that we'd lose the ability to filter out meek bridges that don't have the #13171 fix and that don't report usable `"dirreq-v3-reqs"` statistics. Or rather, we wouldn't spot future meek-like bridges affected by a similar bug.
Here's why. The first bridge descriptor above also contained a `"dirreq-v3-reqs"` line that I left out before:
```
extra-info UtahMeekBridge 88F745840F47CE0C6A4FE61D827950B06F9E4534
published 2015-12-09 22:53:48
dirreq-v3-resp ok=17656,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=6160,busy=0
dirreq-v3-reqs us=17648,cn=8
bridge-ips de=16,cn=8,us=8
```
We wouldn't be able to filter out this bridge without the `"bridge-ips"` line. We would have to assume that the vast majority of requests to this bridge came from the U.S.A., and a tiny minority from China.
I think this is acceptable, because the purpose of statistics shouldn't be to validate the correctness of other statistics.
To summarize my plan, here's what I'd like to do:
1. If a bridge reports both a `"dirreq-v3-resp`" and a `"bridge-ips"` line, check if the first number is smaller than 10 times the second number; if not, ignore these directory-request statistics reported by this bridge.
2. If a bridge only reports a `"bridge-ips"` line and no `"dirreq-v3-reqs"` line, assume that the country distributions are the same, which is what we're doing right now.
3. If a bridge reports a `"dirreq-v3-reqs"` line, use that for user number estimates and ignore the `"bridge-ips"` line in case it's present.
Hope this report was not too confusing. Feedback much appreciated.https://gitlab.torproject.org/legacy/trac/-/issues/17476Error console complaining it can't find meek helper2020-06-13T04:41:31ZArlo BreaultError console complaining it can't find meek helper
> 1446228928138 addons.xpi WARN Problem getting last modified time for /Users/blablbabla/Applications/Tor Messenger.app/Contents/Resources/extensions/tor-launcher@torproject.org/TorBrowser/Tor/PluggableTransports/TorBrowser.app.meek-ht...
> 1446228928138 addons.xpi WARN Problem getting last modified time for /Users/blablbabla/Applications/Tor Messenger.app/Contents/Resources/extensions/tor-launcher@torproject.org/TorBrowser/Tor/PluggableTransports/TorBrowser.app.meek-http-helper/Contents/MacOS: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.lastModifiedTime]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: re[/gre/modules/addons/XPIProvider.jsm](/gre/modules/addons/XPIProvider.jsm) :: recursiveLastModifiedTime :: line 1561" data: no] Stack trace: recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1561](/gre/modules/addons/XPIProvider.jsm:1561) < recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1571](/gre/modules/addons/XPIProvider.jsm:1571) < recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1571](/gre/modules/addons/XPIProvider.jsm:1571) < recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1571](/gre/modules/addons/XPIProvider.jsm:1571) < recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1571](/gre/modules/addons/XPIProvider.jsm:1571) < recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1571](/gre/modules/addons/XPIProvider.jsm:1571) < recursiveLastModifiedTime()@re[/gre/modules/addons/XPIProvider.jsm:1571](/gre/modules/addons/XPIProvider.jsm:1571) < getModTime()@re[/gre/modules/addons/XPIProvider.jsm:1709](/gre/modules/addons/XPIProvider.jsm:1709) < getInstallState()@re[/gre/modules/addons/XPIProvider.jsm:1872](/gre/modules/addons/XPIProvider.jsm:1872) < XPI_checkForChanges()@re[/gre/modules/addons/XPIProvider.jsm:3755](/gre/modules/addons/XPIProvider.jsm:3755) < XPI_startup()@re[/gre/modules/addons/XPIProvider.jsm:2305](/gre/modules/addons/XPIProvider.jsm:2305) < callProvider()@re[/gre/modules/AddonManager.jsm:221](/gre/modules/AddonManager.jsm:221) < _startProvider()@re[/gre/modules/AddonManager.jsm:828](/gre/modules/AddonManager.jsm:828) < AMI_startup()@re[/gre/modules/AddonManager.jsm:996](/gre/modules/AddonManager.jsm:996) < AMP_startup()@re[/gre/modules/AddonManager.jsm:2656](/gre/modules/AddonManager.jsm:2656) < AMC_observe()@jar:file:///Users/blablabla/Applications/Tor%20Messenger.app/Contents/Resources/omni.ja!/components/addonManager.js:55 < <file:unknown>Sukhbir SinghSukhbir Singhhttps://gitlab.torproject.org/legacy/trac/-/issues/17473Update the meek-amazon fingerprint to B9E7141C594AF25699E0079C1F0146F4094952962020-06-15T23:31:11ZDavid Fifielddcf@torproject.orgUpdate the meek-amazon fingerprint to B9E7141C594AF25699E0079C1F0146F409495296-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The bridge fingerprint for the meek-amazon bridge has changed. It was:
4EE0CC769EB4B15A872F742EDE27D298A59DCADE
but is now:
6DDD1DB8526282837C50E9AB5D14AB50150CD624
People wh...-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The bridge fingerprint for the meek-amazon bridge has changed. It was:
4EE0CC769EB4B15A872F742EDE27D298A59DCADE
but is now:
6DDD1DB8526282837C50E9AB5D14AB50150CD624
People who try using meek-amazon are getting a message like this in
their logs:
Oct 30 09:18:46.000 [warn] Tried connecting to router at 0.0.2.0:2, but identity key was not as expected: wanted 4EE0CC769EB4B15A872F742EDE27D298A59DCADE but got 6DDD1DB8526282837C50E9AB5D14AB50150CD624.
The bridge changed fingerprint when it was rebooted on 2015-10-09 to
renew its TLS certificate:
https://lists.torproject.org/pipermail/tor-talk/2015-October/039234.html
I neglected to test the bridge using a configured bridge fingerprint.
(I only tested it using a configuration that did not specify a
fingerprint.) According to the bridge operator, the old identity key is
lost.
Please update the bridge's key in bridge_prefs.js. I will attach a
patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWM5u3AAoJEOK5PYFc04jlsRcP/il8KGrD1ORuCmSv0leH20ob
NAAsRAAaV12PL9CSKuZS9lQi8InfMvZQSz56MyCkIGkFsgn8TlIq6O8nd1tpC3PM
98S+hwrqbXfs85nGdsYPtWZ4HrKfQkRnxBGErM0ideL6EVLi+fy0B+S83o02ktfl
ZB28xs675FjLoEWZhMCDya3hjFQk/vMJXHEOK3GaFzTb6Gj0ELHUCS2ETcCNTSux
g/U4xO0Z4Kk42DY00VPJwFjRc2PQ3pEQ/cZECO20D1erhELFzfQScaeWMpH6M2cV
gKSxCWpUOpZOuzCriaGveY8Vx1dM0HrmCEdtTwR/U6yN5UtXB06G92u2uuj9UuAQ
FAHaqaKpA7nwiNldyGXFsDHFkNb9DHK5O9Y25brTCT7M8MAC1P3gAha0KmLtDUZz
gSj/BEs1mGOQN2NozW4kT3OmBj5Ar8TjAIqt0P55zHMREbB7ZYxaFiFtiFxIrGwo
HqgIgQu5rU944Ut9SA2nA93onkqdYDp6F+4LgrDfoZUvttRM99nUMPlCrCbtWebn
i6R8RhunN1isjpSIv+M1J0rl5s79WXhHY4Bseja5sgX60AkApukaRwBBY1cgS3QZ
ADqj1mBttTKJM4DeemPOsA0IHyNY+kBHc7AeNAizU4ULozA+5yYGwKJWiARU3z+w
frtlxHT+WoWlswOkq7Xh
=ImMV
-----END PGP SIGNATURE-----https://gitlab.torproject.org/legacy/trac/-/issues/17330Figure out what happens when a user's chosen transport is removed from bridge...2020-06-15T23:30:07ZDavid Fifielddcf@torproject.orgFigure out what happens when a user's chosen transport is removed from bridge_prefs.js in an updateI am planning to deactivate meek-amazon. I planned to first simply remove it as an option in Tor Browser by removing the meek-amazon line from bridge_prefs.js. That leaves the question of what happens when someone is using meek-amazon, a...I am planning to deactivate meek-amazon. I planned to first simply remove it as an option in Tor Browser by removing the meek-amazon line from bridge_prefs.js. That leaves the question of what happens when someone is using meek-amazon, and then they upgrade to a newer Tor Browser that doesn't have meek-amazon in bridge_prefs.js?
If it continues using a cached meek-amazon bridge line, that's great; that's the best outcome. We'll keep the bridge running for a while.
If it crashes or falls back to no pluggable transport, then we'll have to think about it.
Does anyone know offhand what will happen?https://gitlab.torproject.org/legacy/trac/-/issues/16662Enable network.http.spdy.* prefs in meek-http-helper for a matching TLS finge...2020-06-15T23:27:47ZDavid Fifielddcf@torproject.orgEnable network.http.spdy.* prefs in meek-http-helper for a matching TLS fingerprintPer #15512, the TLS fingerprint of meek-http-helper in Tor Browser 5.0a3 does not match that of Firefox 38. This is a patch to enable some prefs related to HTTP/2 and SPDY and make the fingerprint match again.Per #15512, the TLS fingerprint of meek-http-helper in Tor Browser 5.0a3 does not match that of Firefox 38. This is a patch to enable some prefs related to HTTP/2 and SPDY and make the fingerprint match again.https://gitlab.torproject.org/legacy/trac/-/issues/16634Use new CDN endpoint for meek-azure2020-06-15T23:27:44ZDavid Fifielddcf@torproject.orgUse new CDN endpoint for meek-azureAn account problem has left meek-azure not working for a couple of days. I had to upgrade to another kind of Azure account and the CDN settings did not migrate with it. The crucial problem is the CDN endpoint domain name, az668014.vo.mse...An account problem has left meek-azure not working for a couple of days. I had to upgrade to another kind of Azure account and the CDN settings did not migrate with it. The crucial problem is the CDN endpoint domain name, az668014.vo.msecnd.net, that is stranded under an expired account. I set up a new equivalent CDN domain, az786092.vo.msecnd.net, but it needs a change to bridge_prefs.js.
https://lists.torproject.org/pipermail/tor-talk/2015-July/038496.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/16281Updating to 4.5.1 sets DisableNetwork2020-06-15T23:26:32ZGriffin BoyceUpdating to 4.5.1 sets DisableNetworkNot sure if this is intentional or not, so posting a report. I'd had meek enabled before the update, and after the update couldn't get Tor Browser to connect to the internet. The fix was to change TBB settings to no longer use a plugga...Not sure if this is intentional or not, so posting a report. I'd had meek enabled before the update, and after the update couldn't get Tor Browser to connect to the internet. The fix was to change TBB settings to no longer use a pluggable transport.
Here's the log:
```
06/03/2015 06:14:03.485 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
06/03/2015 06:14:03.485 [NOTICE] Opening Socks listener on 127.0.0.1:9150
06/03/2015 06:14:16.441 [WARN] The communication stream of managed proxy './TorBrowser/Tor/PluggableTransports/meek-client-torbrowser' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors.
06/03/2015 06:14:16.441 [NOTICE] Failed to terminate process with PID '14392' ('No child processes').
06/03/2015 06:14:17.242 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
06/03/2015 06:14:17.242 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
06/03/2015 06:14:17.242 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
```
Ubuntu 14.04 x64https://gitlab.torproject.org/legacy/trac/-/issues/16014Windows: staged update fails if Meek is enabled2020-06-15T23:26:07ZMark SmithWindows: staged update fails if Meek is enabledOn Windows, if Meek is enabled, the updater fails while trying to copy files to the staged "update applied" directory. Failure occurs because the file Browser/TorBrowser/Data/Browser/profile.meek-http-helper/parent.lock is in use. The ...On Windows, if Meek is enabled, the updater fails while trying to copy files to the staged "update applied" directory. Failure occurs because the file Browser/TorBrowser/Data/Browser/profile.meek-http-helper/parent.lock is in use. The updater will fallback to an unstaged update and users will be prompted to restart to apply the update. This works but a large updated/ directory is left behind which will not be deleted until another update is staged.
We can fix this problem by skipping this parent.lock file inside the updater when copying files.https://gitlab.torproject.org/legacy/trac/-/issues/15902Upgrade meek to 0.182020-06-15T23:25:45ZDavid Fifielddcf@torproject.orgUpgrade meek to 0.18This is to fix a regression that broke meek in Tor Browser 4.5: #15872.
Here is the diff from 0.17. There are some other changes, but the only one that affects anything that goes into Tor Browser is the change to terminateprocess-buffer...This is to fix a regression that broke meek in Tor Browser 4.5: #15872.
Here is the diff from 0.17. There are some other changes, but the only one that affects anything that goes into Tor Browser is the change to terminateprocess-buffer.go.
https://gitweb.torproject.org/pluggable-transports/meek.git/diff/?id=0.18&id2=0.17https://gitlab.torproject.org/legacy/trac/-/issues/15872Meek doesn't start in Tor Browser 4.5 on Windows 72020-06-15T23:25:42ZTracMeek doesn't start in Tor Browser 4.5 on Windows 7
I downloaded the tor browser 4.5 and installed on a Dell computer with windows 7 ultimate 64bit.
when I use meek and start the browser , it just stuck in the connecting process, and 10 minute past. no attention mark or anything turned u...
I downloaded the tor browser 4.5 and installed on a Dell computer with windows 7 ultimate 64bit.
when I use meek and start the browser , it just stuck in the connecting process, and 10 minute past. no attention mark or anything turned up.(even the button to copy log didn't show up)
the strange thing is meek-client-torbrowser.exe and meek-client.exe don't start. I can's see them in the task manager.other things like obfs and fte all work fine.
I tried a fresh install and creating a new account,but it doesn't work either.
However the tor browser works perfect on a computer with windows 8.1 64bit.
Meanwhile the torbrowser 4.0.8 works fine on both computers.
**Trac**:
**Username**: zazone2002https://gitlab.torproject.org/legacy/trac/-/issues/15606Upgrade meek to 0.172020-06-15T23:25:11ZDavid Fifielddcf@torproject.orgUpgrade meek to 0.17Since #15435, there's an official way to use stdin closure as a signal to terminate PTs. meek 0.17 uses this new way. Here is the small diff:
https://gitweb.torproject.org/pluggable-transports/meek.git/diff/?id=0.17&id2=0.16
The only r...Since #15435, there's an official way to use stdin closure as a signal to terminate PTs. meek 0.17 uses this new way. Here is the small diff:
https://gitweb.torproject.org/pluggable-transports/meek.git/diff/?id=0.17&id2=0.16
The only reason I'm bugging you with this upgrade is it also requires a torrc change to simplify the command line and remove the --exit-on-stdin-eof option.