Re: [tor-bugs] #29100 [Core Tor/Fallback Scripts]: Update src/app/config/fallback_dirs.inc to ../tor/src/app/config/fallback_dirs.inc post-split

[Tor Bug Tracker & Wiki]

#29100: Update src/app/config/fallback_dirs.inc to
../tor/src/app/config/fallback_dirs.inc post-split
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer:  nickm  |Sponsor:
---+--
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:7 nickm]:
 > Looks good! I've added a small comment -- please feel free to adjust or
 merge at your discretion.

 Thanks, I made most of the script variables configurable via env vars.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31000 [Core Tor/Tor]: Authorities should cap relay consensus weight as a new consensus method

[Tor Bug Tracker & Wiki]

#31000: Authorities should cap relay consensus weight as a new consensus method
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-dirauth, tor-|  Actual Points:
  bwauth |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 We should disable this new feature on small networks.

 (For example, if the limit is 5%, but the number of relays is less than
 20, it is mathematically impossible to achieve the limit. And if the
 number is slightly more than 20, the weights are going to be very skewed.)

 We should also think about whether we want a hard-coded limit, or we want
 the limit to be a consensus parameter. It would be annoying to have to add
 a consensus method every time we decide to change the limit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31000 [Core Tor/Tor]: Authorities should cap relay consensus weight as a new consensus method

[Tor Bug Tracker & Wiki]

#31000: Authorities should cap relay consensus weight as a new consensus method
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-dirauth, tor-|  Actual Points:
  bwauth |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 To be clear, the proposed idea is that when the directory authorities are
 creating the consensus, they should, as part of the algorithm to turn the
 votes into a consensus, make sure that no relay has more than x% of the
 consensus weight.

 We earlier imagined having torflow (or later sbws) make sure that it would
 never give too high a weight to any single relay. But if each bwauth
 chooses its numbers independently, and then the dir auths just take the
 medium of each, that won't actually ensure that no relay will have more
 than x% of consensus weight. The only place to reliably guarantee it is in
 the consensus formation process.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28797 [Core Tor/Fallback Scripts]: Set up CI on the fallback script with a small number of relays

[Tor Bug Tracker & Wiki]

#28797: Set up CI on the fallback script with a small number of relays
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 The command:
 {{{
 $ TOR_FB_MAX_FALLBACK_COUNT=10 ./updateFallbackDirs.py
 }}}
 is a good starting point, but we also need to be able to set the log level
 to warning (see #28987).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28987 [Core Tor/Fallback Scripts]: Add a log level option to the fallback script

[Tor Bug Tracker & Wiki]

#28987: Add a log level option to the fallback script
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28797 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:   => #28797


Comment:

 We'll need to be able to set the log level to warn to stay under the
 Travis log limit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28987 [Core Tor/Fallback Scripts]: Add a log level option to the fallback script

[Tor Bug Tracker & Wiki]

#28987: Add a log level option to the fallback script
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 These log levels are integers, so we probably want to use
 logging.getLevelName() on the pre-defined levels, then case-insensitively
 match them with the env string.

 https://docs.python.org/2/library/logging.html#logging.getLevelName

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21029 [Core Tor/Fallback Scripts]: Log the git commit hash to the fallback output file

[Tor Bug Tracker & Wiki]

#21029: Log the git commit hash to the fallback output file
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID:  #30969 | Points:  0.3
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => duplicate
 * parent:   => #30969


Comment:

 Duplicate of #30969.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23473 [Core Tor/Fallback Scripts]: Add support for ed25519 fallbacks ids to the fallback script

[Tor Bug Tracker & Wiki]

#23473: Add support for ed25519 fallbacks ids to the fallback script
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  tor-ed25519, fallback  |  Actual Points:
Parent ID:  #26685 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => duplicate
 * parent:  #15059 => #26685


Comment:

 Duplicate of some children of #26685.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24787 [Core Tor/Fallback Scripts]: Revise the fallback stability requirements based on current network load

[Tor Bug Tracker & Wiki]

#24787: Revise the fallback stability requirements based on current network load
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Fallback Scripts|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  fallback, 034-triage-20180328,   |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Things seem fine right now, we can make another ticket if we need to.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #21282 [Core Tor/Fallback Scripts]: Adjust fallback log levels

[Tor Bug Tracker & Wiki]

#21282: Adjust fallback log levels
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords:  fallback   |  Actual Points:
Parent ID:  #29100 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => duplicate
 * parent:   => #29100


Comment:

 Done in #29100.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30542 [Applications/Tor Browser]: pinch-to-zoom viewport vs other screen/window

[Tor Bug Tracker & Wiki]

#30542: pinch-to-zoom viewport vs other screen/window
-+-
 Reporter:  Thorin   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, tbb-mobile,  |  Actual Points:
  tbb-parity |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 Thanks sysrqb. I'm not worried about #27083 here (and I used FF+RFP as TB
 for Android wasn't out at the time), just focused on second issue

 > `screen resolution`, `available resolution`, `outer window`, `inner
 window`, and `view port`. And these remain as the original values after
 pinch-to-zoom:

 Not for me.

 If you look at https://github.com/ghacksuserjs/TorZillaPrint/issues/34 **I
 get the inverse of your result** (if I read it right): i.e. css media is
 static, but the JS results change => indication of hidpi or something:
 maybe letterboxing kicking in solves this (I haven't tried yet)?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30955 [Core Tor/Tor]: Update the fallback entry in the man page

[Tor Bug Tracker & Wiki]

#30955: Update the fallback entry in the man page
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fallback, 041-should, doc, fast-fix  |  Actual Points:  0.1
Parent ID:  #28793   | Points:  0.1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Thanks, I pushed a fixup.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29103 [Core Tor/Fallback Scripts]: Add a licence, readme, and code of conduct to fallback-scripts

[Tor Bug Tracker & Wiki]

#29103: Add a licence, readme, and code of conduct to fallback-scripts
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:  0.1
Parent ID:  #28793 | Points:  0.1
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Thanks, I added "Who needs to run these scripts?" to the README.

 Let me know if you'd like any further changes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30543 [Applications/Tor Browser]: device orientation leaks

[Tor Bug Tracker & Wiki]

#30543: device orientation leaks
+--
 Reporter:  Thorin  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-fingerprinting, tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by Thorin):

 Orientation wouldn't even be a stable metric, IMO: and most mobile device
 users would orientate the same per site: i.e it is driven by content? I've
 never seen it in any fp scripts, TBH.

 I'm not hardware savvy: but do laptop and desktop support this, e.g with
 rotating screens. We could ignore android, and only apply orientation to
 win/mac/linux. i.e least apply landscape to `css media orientation` like
 we do for the two `css media resolutions`. matchMedia I'm not sure about.
 And their will be other methods, I'm sure.

 Or we could not bother. Going full screen will leak orientation. A lot of
 desktop/laptop users (I assume, once letterboxing is implemented: even if
 that only enhances rather than replaces new win sizes) will go FS,
 maximize, or resize to match orientation to get real estate usage: i.e
 inner window = your orientation. So I think it may be a losing battle. I
 also wonder how much this may affect functionality on some sites. And
 lastly, the solution IMO is Tor uptake: e.g tripling the user base etc
 simplistically negates what we do here now.

 +1 for not spoofing orientation

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29801 [Core Tor/Tor]: Write a proposal for IPv6 "Happy Eyeballs" on Tor clients (was: Add teor's suggestions for Prop#299 (referring IPv4 or IPv6 based on IP Version Failure Count))

[Tor Bug Tracker & Wiki]

#29801: Write a proposal for IPv6 "Happy Eyeballs" on Tor clients
---+--
 Reporter:  neel   |  Owner:  neel
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop299  |  Actual Points:
Parent ID:  #17835 | Points:
 Reviewer:  nickm  |Sponsor:
---+--
Changes (by teor):

 * parent:  #27491 => #17835


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #14939 [Applications/Tor Browser]: Support ipv6 addresses in Tor Circuit DIsplay

[Tor Bug Tracker & Wiki]

#14939: Support ipv6 addresses in Tor Circuit DIsplay
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-circuit-display, tbb-usability  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 This issue confused a user on IRC today:

 after some playing around with my tor browser bundle, I found I had to
 set ClientUseIPv6 to 1, and also set ClientUseIPv4 to 0. after doing that,
 despite TBB telling me IPv4 addresses in the circuit list, wireshark
 confirmed it was in-fact connecting over IPv6 :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #8337 [Applications/Tor Browser]: Trusteer crashes Tor Browser

[Tor Bug Tracker & Wiki]

#8337: Trusteer crashes Tor Browser
--+
 Reporter:  mo|  Owner:  (none)
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash,  tbb-7.0-frequent  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  assigned => needs_information


Comment:

 For a while there we had a horrible experience with Trusteer and our
 users. But I haven't heard many problems with it and Tor Browser lately.
 Is it still being an issue? Or did we finally make progress with getting
 them to fix their software?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #8337 [Applications/Tor Browser]: Trusteer crashes Tor Browser

[Tor Bug Tracker & Wiki]

#8337: Trusteer crashes Tor Browser
--+--
 Reporter:  mo|  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash,  tbb-7.0-frequent  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by keb):

 Trusteer should be automatically disabled by TorBrowser, like all other
 untrusted add-ons.
 It is not needed by banks despite them "recommending" it.  I fix infected
 PCs for a living and every single one with Trusteer on it had broken or
 slow performance in all browsers.
 Also, the threat to privacy is much higher with Trusteer. It is closed
 source software that installs at the browser, application and driver
 levels.  It could be capturing identity and financial information from
 hundreds of banks, sending all to a single company.
 I would go so far as to suggest TorBrowser and the website recommend
 uninstalling Trusteer Rapport to ensure it is off the machine, if it is
 detected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31000 [Core Tor/Tor]: Authorities should cap relay consensus weight as a new consensus method (was: Authorities should cap relay consensus weight as a new consensus)

[Tor Bug Tracker & Wiki]

#31000: Authorities should cap relay consensus weight as a new consensus method
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-dirauth, tor-|  Actual Points:
  bwauth |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Oops I did that thing where I

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31000 [Core Tor/Tor]: Authorities should cap relay consensus weight as a new consensus

[Tor Bug Tracker & Wiki]

#31000: Authorities should cap relay consensus weight as a new consensus
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-dirauth, tor-|  Actual Points:
  bwauth |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => needs_information


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #31000 [Core Tor/Tor]: Authorities should cap relay consensus weight as a new consensus

[Tor Bug Tracker & Wiki]

#31000: Authorities should cap relay consensus weight as a new consensus
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  needs-proposal, tor-dirauth, tor-
 Severity:  Normal   |  bwauth
Actual Points:   |  Parent ID:
   Points:  3|   Reviewer:
  Sponsor:   |
-+-
 arma says on IRC:
 {{{
 armadev: teor4: is there a ticket for capping the total weight a given
 relay can get? i remember you mentioning that this should happen as a new
 consensus method, i.e. so the authorities actually collectively cap it,
 rather than relying on each vote individually to do it. i think that's a
 compelling idea.
 }}}

 I'm not sure if the cap should be the same across the network, or if it
 should be different based on each relay's MaxAdvertisedBandwidth.

 If we want to base it on MaxAdvertisedBandwidth, we should also make
 MaxAdvertisedBandwidth a separate number in relay descriptor bandwidth
 lines, rather than combining it with bandwidth rate and bandwidth burst.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30636 [Metrics/Analysis]: Something funky is going in Iran: numbers of relay users flies off to 1M+

[Tor Bug Tracker & Wiki]

#30636: Something funky is going in Iran: numbers of relay users flies off to 
1M+
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ir|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 half million just dropped

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 >  I clicked the Tor Project group link phw sent me, and I think it did
 something

 You now might be in the same boat I was where phw needs to manually add
 you, as above.  But not until you create the account.

 > but I'm puzzled as to how to make an account with tp.o email address?

 Sign out from any Google accounts you may be logged into.

 Go to https://accounts.google.com and "Create an account"

 You'll notice a blue link that says "Use my current email address instead"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30998 [Circumvention/Snowflake]: Some connections to the snowflake bridge from proxies are failing

[Tor Bug Tracker & Wiki]

#30998: Some connections to the snowflake bridge from proxies are failing
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * priority:  High => Low


Comment:

 Replying to [comment:4 arlolra]:
 > > > Firefox can’t establish a connection to the server ...
 > > So it might be an error just with browser-based proxies?
 >
 > Did you try with Chrome?
 Ah.. it does work in Chrome. Thanks. I'll keep this open to remind us to
 address the extension bugs in Firefox.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 I clicked the Tor Project group link phw sent me, and I think it did
 something but I'm puzzled as to how to make an account with tp.o email
 address?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30998 [Circumvention/Snowflake]: Some connections to the snowflake bridge from proxies are failing

[Tor Bug Tracker & Wiki]

#30998: Some connections to the snowflake bridge from proxies are failing
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arlolra):

 > > Firefox can’t establish a connection to the server ...
 > So it might be an error just with browser-based proxies?

 Did you try with Chrome?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30998 [Circumvention/Snowflake]: Some connections to the snowflake bridge from proxies are failing

[Tor Bug Tracker & Wiki]

#30998: Some connections to the snowflake bridge from proxies are failing
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * priority:  Immediate => High


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30934 [Circumvention/Snowflake]: Add a "Turn Off/On" toggle

[Tor Bug Tracker & Wiki]

#30934: Add a "Turn Off/On" toggle
-+--
 Reporter:  arlolra  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 I got a start on implementing this here:
 https://github.com/cohosh/snowflake/tree/webext-toggle

 The first commit is a UI update from antonela.

 The
 
[https://github.com/cohosh/snowflake/commit/e74bf4fd26c9719395210190f03fd3f9c661a5c5
 second commit] is a refactoring of the broker poll. To disable snowflake,
 we need to somehow break the infinite poll loop that cycles between
 `countdown` and `findClients`. I pulled this out into a `setInterval` call
 and slightly changed how to determine whether there are available
 proxyPairs.

 Finally in
 
[https://github.com/cohosh/snowflake/commit/89fe80d0a1226a533deae5fa5b18b98e7150c936
 the third commit], to add the Off/On toggle functionality, we have to
 change how the webpage handles this. It doesn't make sense to use cookies
 and completely reload the web extension as before, so I added an enabled
 variable to the UI class an messaging back and forth to update this.

 There's still a few more things to do:
 - take a look at the bug in #30998
 - change the snowflake image to reflect whether or not it's enabled
 - update unit tests

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #9316 [Circumvention/BridgeDB]: BridgeDB should export statistics

[Tor Bug Tracker & Wiki]

#9316: BridgeDB should export statistics
-+-
 Reporter:  asn  |  Owner:  phw
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics, bridgedb, prometheus, ex-   |  Actual Points:
  sponsor-19, anti-censorship-roadmap|
Parent ID:  #19332   | Points:  3
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

 * status:  assigned => needs_review
 * reviewer:   => sysrqb


Comment:

 I pushed a patch to my
 
[https://github.com/NullHypothesis/bridgedb/commit/50d991585adc128d1e557ae32001211066520dac
 fix/9316 branch]. The commit message provides an overview of what the
 patch seeks to accomplish.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 >> For the Firefox extension, I think you can go ahead and publish it, and
 then try to add other developers.
 > Will do.

 I tagged a release as,
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tag/?h=webext-0.0.1

 and published it,
 https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/

 Was able to add phw as a co-owner since their tpo address seems to be
 setup as a Firefox account.  Waiting on dcf and cohosh to supply their
 account info, either here or by mail.

 > I see that you joined the Google group, so you should be able to publish
 the extension through the group the-tor-project.

 I was able to publish it but it's pending review.


 On both sites, the product pages are going to need some sprucing up.  I
 filed #30999 for that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30999 [Circumvention/Snowflake]: Spruce up the product pages

[Tor Bug Tracker & Wiki]

#30999: Spruce up the product pages
-+-
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:  snowflake-
 |  webextension
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This is going to need some screenshots and verbage and whatnot,
 https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #15238 [Core Tor/Torflow]: Improve or replace TorFlow

[Tor Bug Tracker & Wiki]

#15238: Improve or replace TorFlow
--+---
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  SponsorZ security needs-proposal  |  Actual Points:
Parent ID:  #13630| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 This task will be done by sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30998 [Circumvention/Snowflake]: Some connections to the snowflake bridge from proxies are failing

[Tor Bug Tracker & Wiki]

#30998: Some connections to the snowflake bridge from proxies are failing
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Confirmed that it's not happening with a proxy-go instance I'm running in
 snowbox (which connects to the same bridge). So it might be an error just
 with browser-based proxies? Or it happens periodically?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4708 [Core Tor/sbws]: Implement bwauth cap for latency

[Tor Bug Tracker & Wiki]

#4708: Implement bwauth cap for latency
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords:  performance|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws
 * parent:  #13630 =>
 * milestone:   => sbws: unspecified


Comment:

 If we do this, it will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4709 [Core Tor/sbws]: Implement bwauth cap for TCP socket exhaustion

[Tor Bug Tracker & Wiki]

#4709: Implement bwauth cap for TCP socket exhaustion
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords:  performance|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws
 * parent:  #13630 =>
 * milestone:   => sbws: unspecified


Comment:

 If we do this, it will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #2888 [Core Tor/sbws]: Testing framework/dataset for bw auths

[Tor Bug Tracker & Wiki]

#2888: Testing framework/dataset for bw auths
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws
 * parent:  #13630 =>
 * milestone:   => sbws: unspecified


Comment:

 If we do this, it will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #2550 [Core Tor/sbws]: bwauth should reschedule quicker bandwidth test when bandwidthrate changes?

[Tor Bug Tracker & Wiki]

#2550: bwauth should reschedule quicker bandwidth test when bandwidthrate 
changes?
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  ?
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:  #13630 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #3679 [Core Tor/pytorctl]: TorCtl Event Parsing Rewrite

[Tor Bug Tracker & Wiki]

#3679: TorCtl Event Parsing Rewrite
---+-
 Reporter:  atagar |  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/pytorctl  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID:  #13630 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * component:  Torctl => Core Tor/pytorctl
 * severity:  Blocker => Normal


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4359 [Core Tor/sbws]: Minimize time between new relay appearing and having some bw vote for it

[Tor Bug Tracker & Wiki]

#4359: Minimize time between new relay appearing and having some bw vote for it
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:  #13630 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #10791 [Core Tor/sbws]: Detect overtuned exit relays

[Tor Bug Tracker & Wiki]

#10791: Detect overtuned exit relays
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws
 * type:  defect => enhancement
 * parent:  #13630 =>
 * milestone:   => sbws: unspecified


Comment:

 If we do this, it will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4359 [Core Tor/sbws]: Minimize time between new relay appearing and having some bw vote for it

[Tor Bug Tracker & Wiki]

#4359: Minimize time between new relay appearing and having some bw vote for it
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #13630 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * milestone:   => sbws: unspecified


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4359 [Core Tor/sbws]: Minimize time between new relay appearing and having some bw vote for it

[Tor Bug Tracker & Wiki]

#4359: Minimize time between new relay appearing and having some bw vote for it
---+--
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #13630 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws


Comment:

 If we do this, it will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #5457 [Core Tor/sbws]: Bw auths don't count circuit failures in descriptor mode

[Tor Bug Tracker & Wiki]

#5457: Bw auths don't count circuit failures in descriptor mode
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #5456  | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws
 * milestone:   => sbws: unspecified


Comment:

 If we do this, it will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #2395 [Core Tor/Tor]: Break Wed and Wee weights into two classes each

[Tor Bug Tracker & Wiki]

#2395: Break Wed and Wee weights into two classes each
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance loadbalancing tor-   |  Actual Points:
  client needs-proposal  |
Parent ID:  #8453| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #8453


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30998 [Circumvention/Snowflake]: Some connections to the snowflake bridge from proxies are failing

[Tor Bug Tracker & Wiki]

#30998: Some connections to the snowflake bridge from proxies are failing
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Server logs show a lot of TLS handshake errors:
 {{{
 2019/06/26 21:44:37 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 21:49:39 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 21:54:42 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 21:59:42 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:04:44 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:09:46 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:14:49 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:19:51 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:24:53 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:29:55 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:34:57 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:39:59 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:45:02 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:50:05 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 22:55:08 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 23:00:10 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 23:05:13 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 23:10:16 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 23:15:19 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 23:20:22 http: TLS handshake error from [scrubbed]: EOF
 2019/06/26 23:25:24 http: TLS handshake error from [scrubbed]: EOF

 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30998 [Circumvention/Snowflake]: Some connections to the snowflake bridge from proxies are failing

[Tor Bug Tracker & Wiki]

#30998: Some connections to the snowflake bridge from proxies are failing
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Noticed this while testing out some new webextension changes.

 I get the following errors:
 {{{
 Snowflake: WebRTC DataChannel opened! snowflake.js:1154:13
 Firefox can’t establish a connection to the server at
 wss://snowflake.bamsoftware.com/?client_ip=45.72.156.47.
 snowflake.js:1090:11
 Snowflake: websocket-relay error. snowflake.js:1154:13
 Snowflake: websocket-relay closed.
 }}}

 This are reproducible with a clean master branch.

 I'm also getting several bootstraps to 10% during my client tests that
 aren't going through my proxy so I'm guessing others are having the same
 problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #2550 [Core Tor/sbws]: bwauth should reschedule quicker bandwidth test when bandwidthrate changes?

[Tor Bug Tracker & Wiki]

#2550: bwauth should reschedule quicker bandwidth test when bandwidthrate 
changes?
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #13630 | Points:  ?
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * component:  Core Tor/Torflow => Core Tor/sbws
 * milestone:   => sbws: unspecified


Comment:

 If we ever fix this issue. It will be in sbws

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #1136 [Core Tor/Tor]: When Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offline

[Tor Bug Tracker & Wiki]

#1136: When Tor is offline, it doesn't quite run out of relays, so doesn't 
realize
it's offline
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 |  0.2.1.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, shutdown, bootstrap, |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  reopened => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #1136 [Core Tor/Tor]: When Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offline

[Tor Bug Tracker & Wiki]

#1136: When Tor is offline, it doesn't quite run out of relays, so doesn't 
realize
it's offline
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 |  0.2.1.19
 Severity:  Normal   | Resolution:  None
 Keywords:  tor-client, shutdown, bootstrap, |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #1136 [Core Tor/Tor]: When Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offline

[Tor Bug Tracker & Wiki]

#1136: When Tor is offline, it doesn't quite run out of relays, so doesn't 
realize
it's offline
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 |  0.2.1.19
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, shutdown, bootstrap, |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  closed => reopened
 * resolution:  fixed =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #1136 [Core Tor/Tor]: When Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offline

[Tor Bug Tracker & Wiki]

#1136: When Tor is offline, it doesn't quite run out of relays, so doesn't 
realize
it's offline
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 |  0.2.1.19
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, shutdown, bootstrap, |  Actual Points:
  sponsor8-maybe |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => closed
 * resolution:  None => fixed


Comment:

 Cleaning resolution "None" (looks like a bug in Trac itself)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30996 [Core Tor/Tor]: namemap_get_or_create_id reads past its allocated memory

[Tor Bug Tracker & Wiki]

#30996: namemap_get_or_create_id reads past its allocated memory
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-must 041-regression  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 (I am using a much newer valgrind than in that bugzilla report, but, that
 doesn't seem to help me here either. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30996 [Core Tor/Tor]: namemap_get_or_create_id reads past its allocated memory

[Tor Bug Tracker & Wiki]

#30996: namemap_get_or_create_id reads past its allocated memory
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-must 041-regression  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Yuck. I see the valgrind complaint with -O2 but I do not see it with -O0
 or -O1. So I think you are right.

 I have now added
 {{{
 diff --git a/src/lib/container/namemap.c b/src/lib/container/namemap.c
 index a90057b..263e823 100644
 --- a/src/lib/container/namemap.c
 +++ b/src/lib/container/namemap.c
 @@ -145,7 +145,10 @@ namemap_get_or_create_id(namemap_t *map,
  return NAMEMAP_ERR; /* Can't allocate any more. */

mapped_name_t *insert = tor_malloc_zero(
 -   offsetof(mapped_name_t, name) + namelen + 1);
 +offsetof(mapped_name_t, name) + namelen + 1
 +/* Unfortunate hack to let valgrind handle SSE optimizations
 + * in strlen in -O2. See bug 30996. */
 ++ 4);
memcpy(insert->name, name, namelen+1);
insert->intval = new_id;
 }}}

 to my list of patches that make moria1 different from master.

 (I started with a slightly more complex hack, with a bufsize variable and
 a -= and a %4, but a hack is a hack so I'll not quibble. :)

 I'll let you decide if you want to close this as a wontfix and I'll just
 maintain my workaround forever in my growing list of differences, or if
 you want to take my hack into Tor itself.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30997 [Internal Services/Service - jenkins]: Rust/Cargo problem on Jenkins sid-armhf?

[Tor Bug Tracker & Wiki]

#30997: Rust/Cargo problem on Jenkins sid-armhf?
-+-
 Reporter:  catalyst |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  jenkins|
 Severity:  Normal   |   Keywords:  tor-ci-fail
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Looks like maybe Cargo or rustc is broken on sid-armhf?
 {{{
 17:28:51 ( cd "/srv/jenkins-workspace/workspace/tor-ci-linux-master-rust-
 arm/ARCHITECTURE/armhf/SUITE/sid/build-tree-tor/src/rust" ; \
 17:28:51CARGO_TARGET_DIR="/srv/jenkins-workspace/workspace/tor-ci-
 linux-master-rust-arm/ARCHITECTURE/armhf/SUITE/sid/build-tree-
 tor/src/rust/target" \
 17:28:51cargo build --release  \
 17:28:51--frozen \
 17:28:51--manifest-path "/srv/jenkins-workspace/workspace/tor-ci-
 linux-master-rust-arm/ARCHITECTURE/armhf/SUITE/sid/build-tree-
 tor/../tor/src/rust/tor_rust/Cargo.toml" )
 17:28:53 error: process didn't exit successfully: `rustc -vV` (exit code:
 1)
 17:28:53 --- stdout
 17:28:53 rustc 1.34.2
 17:28:53 binary: rustc
 17:28:53 commit-hash: unknown
 17:28:53 commit-date: unknown
 17:28:53 host: armv7-unknown-linux-gnueabihf
 17:28:53 release: 1.34.2
 17:28:53
 17:28:53 --- stderr
 17:28:53 : CommandLine Error: Option '' registered more than once!
 17:28:53 LLVM ERROR: inconsistency in registered CommandLine options
 17:28:53
 17:28:53 make[1]: *** [Makefile:23235:
 src/rust/target/release/libtor_rust.a] Error 101
 17:28:53 make[1]: Leaving directory '/srv/jenkins-workspace/workspace/tor-
 ci-linux-master-rust-arm/ARCHITECTURE/armhf/SUITE/sid/build-tree-tor'
 17:28:53 make: *** [Makefile:6668: all] Error 2
 17:28:53 + true
 17:28:53 + exit 2
 17:28:53 + rc=2
 17:28:53 + echo '=== [build-wrapper] end ==='
 17:28:53
 === [build-wrapper] end ===
 }}}
 I think we didn't make any changes to Tor that could have caused that.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30989 [Internal Services/Service - jenkins]: intermittent jenkins failures for tor-ci

[Tor Bug Tracker & Wiki]

#30989: intermittent jenkins failures for tor-ci
-+
 Reporter:  catalyst |  Owner:  weasel
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, jenkins   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by catalyst):

 Another failure:

 https://jenkins.torproject.org/view/Failed+Unstable/job/tor-ci-linux-
 master-rust/ARCHITECTURE=i386,SUITE=sid/998/console
 {{{
 16:31:32 E: Failed to fetch
 
https://mirrors.wikimedia.org/debian/pool/main/p/python2.7/python2.7-minimal_2.7.16-2_i386.deb
 Could not wait for server fd - select (11: Resource temporarily
 unavailable) [IP: 2620:0:861:1:208:80:154:15 443]
 16:31:32 E: Some files failed to download
 16:31:32 run-parts: /home/jenkins/jenkins-tools/slaves/linux/tor-ci-linux-
 master-rust/setup/15-install-build-depends exited with return code 1
 }}}
 Maybe that one mirror is broken?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29800 [Applications/Tor Browser]: Using Tor in the UAE

[Tor Bug Tracker & Wiki]

#29800: Using Tor in the UAE
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 People direly need that snowflake pluggable transport being available on
 Android.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30988 [Applications/Tor Browser]: No sound

[Tor Bug Tracker & Wiki]

#30988: No sound
--+---
 Reporter:  arkadiy   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  audio sound   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arkadiy):

 I'm using Debian buster/sid. There is sound coming out of vanilla Firefox
 ESR 60.7.2

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #16110 [Applications/Tor Browser]: Improve Time Resolution Defense

[Tor Bug Tracker & Wiki]

#16110: Improve Time Resolution Defense
-+--
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-time-highres  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mikeperry):

 * status:  needs_review => assigned
 * owner:  mikeperry => tbb-team


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #9570 [Applications/Tor Browser]: Many changes to private browsing code of Firefox happened since 17esr out

[Tor Bug Tracker & Wiki]

#9570: Many changes to private browsing code of Firefox happened since 17esr out
--+---
 Reporter:  cypherpunks   |  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  MikePerry201312R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mikeperry):

 * status:  needs_revision => closed
 * resolution:   => fixed


Comment:

 The fix for this was merged a while ago, and my questions were answered.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23111 [Applications/Tor Browser]: A web page is slowing down your browser.

[Tor Bug Tracker & Wiki]

#23111: A web page is slowing down your browser.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  needs_information => closed
 * resolution:   => wontfix


Comment:

 Replying to [comment:11 cypherpunks]:
 > "But it still happily fucks the system when the page is visible. (Not
 100% CPU, more load on 32-bit version.)" similar results on virtual
 machine by using Firefox ESR 60.

 Thanks. This seems to be an inherent Firefox problem. I suspect the
 resources it needs are sufficiently high that the machine you have gets
 strained in "standard" mode. And that not everything is working in "safer"
 mode is kind of a calculated side-effect. Thus, all in all I think that's
 not a bug we'll be fixing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #7542 [Applications/Tor Browser]: Mailto: Gmail, does not work

[Tor Bug Tracker & Wiki]

#7542: Mailto: Gmail, does not work
--+---
 Reporter:  LanceHaverkamp|  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mikeperry):

 * status:  needs_revision => closed
 * resolution:   => wontfix


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #12609 [Applications/Tor Browser]: HTML5 fullscreen API makes TB fingerprintable, disable it!

[Tor Bug Tracker & Wiki]

#12609: HTML5 fullscreen API makes TB fingerprintable, disable it!
-+-
 Reporter:  cypherpunks  |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  linkability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_revision => closed
 * resolution:   => wontfix


Comment:

 We should ensure the prompt works properly, not disable fullscreen.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4810 [Applications/Tor Browser]: Weird screen sizes reported by Panopticlick

[Tor Bug Tracker & Wiki]

#4810: Weird screen sizes reported by Panopticlick
---+
 Reporter:  erikd  |  Owner:  mikeperry
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by mikeperry):

 * status:  needs_revision => closed
 * resolution:   => worksforme


Comment:

 Thanks Thorin. I agree that this bug is old and does not represent any
 current issues, even if more exist. The underlying implementation has
 completely changed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4338 [Applications/Tor Browser]: TBB creates Mozilla folder in user folder

[Tor Bug Tracker & Wiki]

#4338: TBB creates Mozilla folder in user folder
+--
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:
|  needs_information
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  backport-to-mozilla, tbb-disk-leak  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mikeperry):

 * status:  assigned => needs_information


Comment:

 Is this still an issue with modern Tor Browsers?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #4338 [Applications/Tor Browser]: TBB creates Mozilla folder in user folder

[Tor Bug Tracker & Wiki]

#4338: TBB creates Mozilla folder in user folder
+--
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  backport-to-mozilla, tbb-disk-leak  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mikeperry):

 * status:  needs_revision => assigned
 * owner:  mikeperry => (none)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30996 [Core Tor/Tor]: namemap_get_or_create_id reads past its allocated memory

[Tor Bug Tracker & Wiki]

#30996: namemap_get_or_create_id reads past its allocated memory
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-must 041-regression  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 "32 bytes inside a block of size 33" sounds legal to me... but a "read of
 size 4" here would of course not be illegal.

 I note that line 29 is:
 {{{
   return (unsigned) siphash24g(a->name, strlen(a->name));
 }}}

 So unless it's actually complaining about siphash24g, it's complaining
 about strlen().  I wonder if there is an issue with an optimized strlen
 you have?  Sometimes valgrind doesn't understand those.  For example see
 https://bugzilla.redhat.com/show_bug.cgi?id=518247 .

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30996 [Core Tor/Tor]: namemap_get_or_create_id reads past its allocated memory

[Tor Bug Tracker & Wiki]

#30996: namemap_get_or_create_id reads past its allocated memory
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  High |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-must 041-regression  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:  041-must => 041-must 041-regression


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30996 [Core Tor/Tor]: namemap_get_or_create_id reads past its allocated memory

[Tor Bug Tracker & Wiki]

#30996: namemap_get_or_create_id reads past its allocated memory
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-must  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => accepted
 * priority:  Medium => High
 * owner:  (none) => nickm
 * points:   => 0.5
 * milestone:   => Tor: 0.4.1.x-final
 * keywords:   => 041-must


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30864 [Core Tor/Tor]: Move variable manipulation code out of confparse.c

[Tor Bug Tracker & Wiki]

#30864: Move variable manipulation code out of confparse.c
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  2.5
Parent ID:  #29211| Points:  1
 Reviewer:  catalyst  |Sponsor:  Sponsor31-can
--+

Comment (by catalyst):

 Thanks! Overall this is looking fairly good. I'm still having trouble with
 the vagueness of some of the descriptions in the explanatory comments.

 I started to write some line-by-line review comments on files in the pull
 request but found that I was having difficulty suggesting alternative
 text.

 So instead, I figured I should try to summarize (at a high level) what I'm
 finding confusing, in the hopes that it will make it easier to suggest
 alternative text in the pull request comments:

 * It's not clear what the main header file for this interface is. Maybe
 it's `typedvar.h`?
 * In many places, words like "type" and "variable" are used in vague ways,
 and not necessarily to refer to C types or variables.

 I kind of wish there were a high-level overview of how this works. My
 attempt to construct one from my analysis of the code is:

  `typedvar.h` 

 * `typedvar.h` is an interface for accessing objects whose type is
 designated at run-time. (Maybe a kind of dynamic typing? Can we call it
 dynamic typing?) Access includes encoding, decoding, copying, clearing,
 etc.
 * `typedvar.h` functions use `void *` as generic pointers to the
 dynamically typed objects. (Maybe some opaque pointer type would be
 better, but then explicit casts would be needed.)
 * `var_type_def_t` objects are descriptors that instruct the `typedvar.h`
 functions how to manipulate a given dynamic object.
 * Most of the `typedvar.h` functions take pointers to `var_type_def_t`
 objects instead of enumerated type numbers to discover how to manipulate a
 given dynamically typed object.
 * Some `typedvar.h` functions take enumerated values from `config_type_t`
 to look up which `var_type_def_t` object to use. This seems like a bit of
 a layering violation but it's probably an acceptable intermediate
 situation.

  `conftypes.h` 

 * `conftypes.h` holds the enumerated `config_type_t` values previously in
 `confparse.h`. `typedvar.h` functions use these enumerated values to look
 up which `var_type_def_t` describes a given dynamically typed object.

  `type_defs.c` 

 * `type_defs.c` implements most of the functions that `typedvar.h` will
 use for accessing the dynamically typed objects.
 * `type_defs.c` also has the lookup table (and lookup function) to look up
 the appropriate `var_type_def_t` descriptor from a type number from
 `config_type_t`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #30996 [Core Tor/Tor]: namemap_get_or_create_id reads past its allocated memory

[Tor Bug Tracker & Wiki]

#30996: namemap_get_or_create_id reads past its allocated memory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 running valgrind on moria1, running git master
 {{{
 Jun 26 15:48:27.309 [notice] Tor 0.4.2.0-alpha-dev (git-6afe1b00c9c73b1b)
 running on Linux with Libevent 2.2.0-alpha-dev, OpenSSL 1.0.1e-fips, Zlib
 1.2.3, Liblzma N/A, and Libzstd N/A.
 }}}

 I get at startup a pile of these:

 {{{
 ==48499== Invalid read of size 4
 ==48499==at 0x30E83A: namemap_get_or_create_id (namemap.c:29)
 ==48499==by 0x301792: get_subsys_id (dispatch_naming.c:62)
 ==48499==by 0x169D75: subsystems_add_pubsub_upto (subsysmgr.c:131)
 ==48499==by 0x168A95: tor_run_main (main.c:1239)
 ==48499==by 0x165D52: tor_main (tor_api.c:164)
 ==48499==by 0x1659D8: main (tor_main.c:32)
 ==48499==  Address 0x72bdc40 is 32 bytes inside a block of size 33 alloc'd
 ==48499==at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
 ==48499==by 0x322397: tor_malloc_ (malloc.c:45)
 ==48499==by 0x322685: tor_malloc_zero_ (malloc.c:71)
 ==48499==by 0x30E7F6: namemap_get_or_create_id (namemap.c:147)
 ==48499==by 0x301792: get_subsys_id (dispatch_naming.c:62)
 ==48499==by 0x169D75: subsystems_add_pubsub_upto (subsysmgr.c:131)
 ==48499==by 0x168A95: tor_run_main (main.c:1239)
 ==48499==by 0x165D52: tor_main (tor_api.c:164)
 ==48499==by 0x1659D8: main (tor_main.c:32)
 }}}

 Looks like it's allocating some space, and then trying to use more than it
 allocated?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28756 [Applications/Tor Browser]: Sync doesn't work with Tor Browser for Android

[Tor Bug Tracker & Wiki]

#28756: Sync doesn't work with Tor Browser for Android
--+--
 Reporter:  dimqua|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-mobile, tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Unfortunately, this is a significant amount of work, and I doubt we will
 accomplish this within the next year. Mozilla are working on a new browser
 (Fenix), as well, where many of these problems should not exist (or
 hopefully we'll find them and fix them early).

 I'm setting this as wontfix for now, because I don't think this is a
 ticket we can realistically fix due to the amount of time this would
 require and Mozilla's upcoming browser for Android.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28756 [Applications/Tor Browser]: Sync doesn't work with Tor Browser for Android

[Tor Bug Tracker & Wiki]

#28756: Sync doesn't work with Tor Browser for Android
--+--
 Reporter:  dimqua|  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * status:  closed => reopened
 * resolution:  duplicate =>


Comment:

 After chatting with gk, I agreed this ticket is not only about the app
 crashing but the intended goal is actually using Sync, as well. We did
 prevent the crash in #30086, but there are a few remaining problems we
 should fix before allowing Sync again.

 In particular, we must solve #28125 and #27069. We must also decide if
 Firefox Accounts should be added as an Account on the Android device
 (related to #27069) or should Sync only be available as an in-app feature.

 Currently, we completely exclude the Sync functionality when the app is
 built.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29269 [Circumvention/BridgeDB]: Evaluation of bridge statistics

[Tor Bug Tracker & Wiki]

#29269: Evaluation of bridge statistics
---+--
 Reporter:  cohosh |  Owner:  phw
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention/BridgeDB |Version:
 Severity:  Normal | Resolution:
 Keywords:  statistics, ex-sponsor-19  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * keywords:  bridges, statistics, ex-sponsor-19, ex-sponsor19 =>
 statistics, ex-sponsor-19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30777 [Community/Outreach]: Run a "set up new bridges" campaign

[Tor Bug Tracker & Wiki]

#30777: Run a "set up new bridges" campaign
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  project  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Community/Outreach   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor30-must
-+
Changes (by gaba):

 * cc: alison (added)
 * status:  new => assigned
 * owner:  alison => (none)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 > Does it work now?

 Yup, thanks

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #8001, #8051, #12600, #17193, ...

[Tor Bug Tracker & Wiki]

Batch modification to #8001, #8051, #12600, #17193, #22826, #23434, #25647, 
#11101 by gaba:


Action: reassign

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #2162 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Support alternate authentication models

[Tor Bug Tracker & Wiki]

#2162: Support alternate authentication models
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * status:  assigned => closed
 * resolution:   => invalid


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #2161, #1136, #2162, #2395, ...

[Tor Bug Tracker & Wiki]

Batch modification to #2161, #1136, #2162, #2395, #5707, #5734, #6427, #8222, 
#9121, #9216, #10070, #10963, #12387, #12401, #14836, #15706, #22717, #23980, 
#24487, #24956, #25753, #2542, #3978, #4763, #4793, #6065, #7918, #8337, #8593, 
#10434, #10630, #10874, #22422, #2550, #2888, #4132, #4269, #4270, #4359, 
#4446, #5457, #5685, #7757, #8159, #8160, #8453, #11751, #17591, #4794, #5556, 
#7638, #9575, #10969, #11935 by gaba:


Action: reassign

--
Tickets URL: 

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by phw):

 Oh, it looks like you were no longer part of this group. I tried to add
 you directly this time, using your tp.o address. Does it work now?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding: Circsetup machines give out warnings when client-side intro gets NACKed

[Tor Bug Tracker & Wiki]

#30992: circpadding: Circsetup machines give out warnings when client-side intro
gets NACKed
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.4.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  wtf-pad circpad 041-should  |  Actual Points:
Parent ID:  | Points:  0.4
 Reviewer:  |Sponsor:
+--

Comment (by mikeperry):

 Very odd.. not sure why this would change the hop where the padding comes
 from...

 Is there an easy way/test service to reproduce this with? Or do you just
 have to wait for it to happen?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30441 [Circumvention/BridgeDB]: Stop BridgeDB from handing out offline bridges

[Tor Bug Tracker & Wiki]

#30441: Stop BridgeDB from handing out offline bridges
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Major| Resolution:
 Keywords:  user-feedback, blog, anti-   |  Actual Points:
  censorship-roadmap |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by phw):

 I added a log message to BridgeDB that tells us how many bridge requests
 resulted in 0, 1, 2, and 3 bridge lines.  Here are the results for a few
 hours worth of logs:
 {{{
# of bridges | # of requests
-+--
   0 | 188 (14%)
   1 | 381 (29%)
   2 | 395 (38%)
   3 | 235 (18%)
 }}}
 (Interestingly, all requests that resulted in 0 bridges were HTTPS
 requests for obfs2, coming from Tor exit relays.  BridgeDB no longer
 supports obfs2, which is why it responds with 0 bridges.)

 Assuming that these numbers are correct, BridgeDB should be returning at
 least one bridge for every request it has seen over the last few hours.
 That clearly wasn't the case a few days ago but I wonder if it's the case
 now. The only thing that changed is that I added debug log messages and
 restarted BridgeDB a few times.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29800 [Applications/Tor Browser]: Using Tor in the UAE

[Tor Bug Tracker & Wiki]

#29800: Using Tor in the UAE
--+---
 Reporter:  mwolfe|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mwolfe):

 Replying to [comment:4 sysrqb]:
 > mwolfe, do you have any more information for this? Can you provide any
 logs from Tor showing where the error/failure occurs? Do you have Tor
 Browser on a desktop or laptop (and does that work)?
 >
 > In addition, can you provide more information about which apps you used
 on the Android phone? You said you installed Tor for Android. Did you
 install Orbot or Tor Browser? Which configurations did you try?

 Basically, WeChat (what the Chinese use instead of Skype) is blocked in
 the UAE. Skype is also blocked. On my Windows computer, I use a VPN to
 Skype, since Tor does not support Skype.

 I tried Orbot, which is supposed to route everything around the blocks,
 but it didn't work. WeChat just didn't connect. No error message, I just
 could not connect.

 I tried to log in to the WeChat site (which must be accessed by Android,
 though they prefer iOS)  on my Windows or Mac computer using Tor, I can
 try to log in, but it just gives me a QR code (that says it only works
 with an iPhone).

 So I tried to log in to WeChat from Android with Tor, but could not
 connect. It might be that WeChat blocks all Tor exit nodes (I've found
 many sites that use a Firewall that has all or almost all Tor exit nodes
 blocked, and many with a Captcha that only happens with Tor and is set to
 be very hard to get past.

 So sorry, no error logs, I just could not connect to WeChat and create an
 account on my Nokia 6.1 Plus phone.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #2   | Points:  7
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by cypherbits):

 Replying to [comment:12 cypherpunks]:
 > My concern about a proof of work approach is it appears to open a back
 channel where a hidden service operator has influence over client
 behaviour. This could result in clients executing possibly rarely
 used/exploitable codepaths, or new correlation attacks. For example, the
 hidden service operator sets a requirement for a PoW that takes 1.21 KW to
 compute. The operator has also hacked in to an energy company with high
 resolution "smart" meters, then could sit back and watch as users login to
 the service.

 PoW should be a fixed value on the network consensus or hardcoded, if we
 want the HS to be capable of configuring it then we should limit the
 parameters. Thats it.

 --

 On the other hand I have two questions on the implementation and replay
 caches:

 -How does the replay cache works for INTRODUCE1 cells? The bug allowing
 for the same circuit to send many INTRODUCE1 should be closed years ago.

 -Why we actually rotate Introduction Points? and why we do it after x
 INTRODUCE cells and not based on a time, like each 24 hours?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29052 [Applications/Tor Browser]: A Minor Bug in Tor Browser for Android

[Tor Bug Tracker & Wiki]

#29052: A Minor Bug in Tor Browser for Android
--+--
 Reporter:  Adhithyan |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  user disappeared
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * status:  needs_information => closed
 * resolution:   => user disappeared


Comment:

 Not enough information.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30957 [Applications/Tor Browser]: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)

[Tor Bug Tracker & Wiki]

#30957: Allow '.asc' files to be downloaded using Tor browser (PGP ascii)
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 This is a bug in Fennec. Fennec does not provide an option for
 downloading/saving files. It only provides this for images. As far as I
 know, for every other html element type (simple links), it begins
 downloading the file and then the app 1) checks if it can handle the file
 itself (like text files), 2) checks if another app on the device can
 handle it (like pdfs), and 3) simply downloads the file.

 I found these:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1546274

 This isn't exactly the same bug, but it is similar. There are a few other
 bugs related to how Fennec handles downloads, too.

 I suspect this will never be fixed in Fennec. Maybe [https://github.com
 /mozilla-mobile/fenix Fenix] will behave differently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 > Do you see this too?

 The developer dashboard doesn't mention anything about groups I belong to.
 It does have that button but under "Your Listings".

 The "My groups" I referred to above was from https://groups.google.com/ in
 case that wasn't clear.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by phw):

 Replying to [comment:5 arlolra]:
 > > I see that you joined the Google group, so you should be able to
 publish the extension through the group the-tor-project.
 >
 > I accepted the invitation, yes, but didn't have a Google account for
 that address.  So, I created one, but the group doesn't show up in the "My
 groups" listing.  Not really sure what to do about that.
 [[br]]
 I also created a Google account for my tp.o email address.
 [https://chrome.google.com/webstore/developer/dashboard There's a
 developer dashboard] that has a button that says "Add new item". Do you
 see this too? I have it for both my personal account and my group account.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.

[Tor Bug Tracker & Wiki]

#11211: Multiple ServerTransportListenAddr entries should be allowed per 
transport.
-+-
 Reporter:  yawning  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, pt, needs-spec, tor-pt,  |  Actual Points:
  bridgedb-parsers, ipv6, triaged-out-20170124   |
Parent ID:  #10629   | Points:
 Reviewer:   |Sponsor:  T/U
-+-
Changes (by phw):

 * cc: phw (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30986 [Circumvention]: Understand the "long tail" of unclassifiable network traffic

[Tor Bug Tracker & Wiki]

#30986: Understand the "long tail" of unclassifiable network traffic
---+
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #30716 | Points:  5
 Reviewer: |Sponsor:  Sponsor28-must
---+
Changes (by phw):

 * parent:  #29285 => #30716


Old description:

> The obfs family of obfuscation protocols strives to "look like nothing"
> and falls into the long tail of network traffic that is meant to be
> unclassifiable. That is, if an ISP is monitoring its uplink, it shouldn't
> be able to figure out that one of its users is talking obfs4 to a Tor
> bridge. Instead, the obfs4 connection should show up as "unknown" in the
> log files.
>
> We know next to nothing about this long tail that the obfs family hides
> in. What fraction of flows does it constitute? What fraction of bytes?
> What kind of protocols and implementations are difficult to classify? How
> does the long tail differ across uplinks?
>
> Over at #29285 we're brainstorming features for obfs4's successor but
> before moving forward with obfs5, we should get a better understanding of
> this long tail because it allows us to make informed design decisions.
> Packet traces from the [http://mawi.wide.ad.jp/mawi/ WIDE backbone] is
> one of the data sets that may be helpful here.
>
> Let's use this ticket to track progress and collect insights.

New description:

 The obfs family of obfuscation protocols strives to "look like nothing"
 and falls into the long tail of network traffic that is meant to be
 unclassifiable. That is, if an ISP is monitoring its uplink, it shouldn't
 be able to figure out that one of its users is talking obfs4 to a Tor
 bridge. Instead, the obfs4 connection should show up as "unknown" in the
 log files.

 We know next to nothing about this long tail that the obfs family hides
 in. What fraction of flows does it constitute? What fraction of bytes?
 What kind of protocols and implementations are difficult to classify? How
 does the long tail differ across uplinks?

 Over at #30716 we're brainstorming features for obfs4's successor but
 before moving forward with obfs5, we should get a better understanding of
 this long tail because it allows us to make informed design decisions.
 Packet traces from the [http://mawi.wide.ad.jp/mawi/ WIDE backbone] is one
 of the data sets that may be helpful here.

 Let's use this ticket to track progress and collect insights.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 > I see that you joined the Google group, so you should be able to publish
 the extension through the group the-tor-project.

 I accepted the invitation, yes, but didn't have a Google account for that
 address.  So, I created one, but the group doesn't show up in the "My
 groups" listing.  Not really sure what to do about that.

 > For the Firefox extension, I think you can go ahead and publish it, and
 then try to add other developers.

 Will do.

 > Shall we keep this ticket open until we managed to publish the extension
 for both Google and Firefox?

 Yes, please.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30584 [Applications/Tor Browser]: interaction avec l'application Gmail sur Android

[Tor Bug Tracker & Wiki]

#30584: interaction avec l'application Gmail sur Android
--+---
 Reporter:  boullu|  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 Bonjour, merci pour cette information. Pouvez-vous décrire les
 fonctionnalités de l'application Gmail lorsque "Navigateur Tor" est
 installé?

 ---

 Hello, thank you for this information. Can you describe which
 functionality breaks in the Gmail app when "Tor Browser" is installed?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30931 [Circumvention/Snowflake]: Setup accounts for publishing the webextension

[Tor Bug Tracker & Wiki]

#30931: Setup accounts for publishing the webextension
-+--
 Reporter:  arlolra  |  Owner:  phw
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by phw):

 Arlo, I think we're good to go here. I see that you joined the Google
 group, so you should be able to publish the extension through the group
 `the-tor-project`. For the Firefox extension, I think you can go ahead and
 publish it, and then try to add other developers. Shall we keep this
 ticket open until we managed to publish the extension for both Google and
 Firefox?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #27503 [Applications/Tor Browser]: Disabling accessibility on Windows breaks screen readers

[Tor Bug Tracker & Wiki]

#27503: Disabling accessibility on Windows breaks screen readers
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  GeorgKoppen201903, TorBrowserTeam201906R,  |
  tbb-8.5|
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-

Comment (by onionsoup):

 I just tested the 64 build, and it works perfectly!
 Not sure if this is the right place to put it, but thank you so much for
 making accessibility a priority! It is very, very much appreciated.
 Replying to [comment:88 pospeselr]:
 > Test builds built against tor-browser-60.7.0esr-9.0-2 with security
 fixes I mentioned before:
 >
 > i686: https://people.torproject.org/~richard/builds/torbrowser-install-
 tbb-nightly_en-US-i686-27503-candidate4.exe
 > amd64: https://people.torproject.org/~richard/builds/torbrowser-install-
 tbb-nightly_en-US-amd64-27503-candidate4.exe

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30543 [Applications/Tor Browser]: device orientation leaks

[Tor Bug Tracker & Wiki]

#30543: device orientation leaks
+--
 Reporter:  Thorin  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-fingerprinting, tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 This one is tricky. I'm not sure if spoofing the device orientation is
 really important, but I think we should be consistent. We should either
 spoof all of these values or none of them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30542 [Applications/Tor Browser]: pinch-to-zoom viewport vs other screen/window

[Tor Bug Tracker & Wiki]

#30542: pinch-to-zoom viewport vs other screen/window
-+-
 Reporter:  Thorin   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, tbb-mobile,  |  Actual Points:
  tbb-parity |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  tbb-fingerprinting, tbb-mobile => tbb-fingerprinting, tbb-
 mobile, tbb-parity


Comment:

 Thanks Thorin. I see two problems here. The first is related to exact
 screen dimensions (#27083) and the other is inconsistency of reported
 values. On the webpage on Android, I see these are (approximately) the
 same (based on pinch-to-zoom level): `screen resolution`, `available
 resolution`, `outer window`, `inner window`, and `view port`. And these
 remain as the original values after pinch-to-zoom: `[css] screen
 resolution` and `[css] inner window`.

 It seems like there isn't a feedback channel from the pinch-to-zoom
 function into the CSS engine (whatever that is). I also wonder if rounding
 the zoom level into buckets will help with this (in addition to any screen
 rounding and/or letterboxing we add). By this I mean on desktop, you can
 only zoom-in and zoom-out by fixed values, but pinch-to-zoom is relatively
 arbitrary. We can think about only allowing specific zoom levels.

 And, as a side note, this seems partly broken with Firefox Nightly on
 Android, so we should test this after the 68esr rebase.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30964 [Core Tor/Tor]: Fix shellcheck warning about unused variable in test_rebind.sh

[Tor Bug Tracker & Wiki]

#30964: Fix shellcheck warning about unused variable in test_rebind.sh
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  dgoulet-merge  |  Actual Points:  0
Parent ID: | Points:  0
 Reviewer:  ahf|Sponsor:
---+
Changes (by dgoulet):

 * status:  merge_ready => closed
 * resolution:   => fixed


Comment:

 Merged!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30549 [Applications/Tor Browser]: Add script to remove expired sub-keys from a keyring file

[Tor Bug Tracker & Wiki]

#30549: Add script to remove expired sub-keys from a keyring file
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201906R, tbb-rbm  |  Actual Points:
Parent ID:  #30548  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  TorBrowserTeam201906, tbb-rbm => TorBrowserTeam201906R, tbb-
   rbm
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:8 gk]:
 > Could you update `drop-expired-sub-keys` with the process you envision
 in commit:5? That way someone later without all the background we have
 knows what to do with the script(s).

 In branch `bug_30549_v4` I added a README file explaining the process:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_30549_v4=059bb1f569084ac1c6e9d17cd3959c33afeb37d7

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28756 [Applications/Tor Browser]: Sync doesn't work with Tor Browser for Android

[Tor Bug Tracker & Wiki]

#28756: Sync doesn't work with Tor Browser for Android
--+---
 Reporter:  dimqua|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-mobile, tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  needs_information => closed
 * resolution:   => duplicate


Comment:

 Thanks for reporting this. It should be fixed in #30086.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #29498 [Applications/Tor Browser]: Outbound proxy not working in Tor Browser Android.

[Tor Bug Tracker & Wiki]

#29498: Outbound proxy not working in Tor Browser Android.
--+---
 Reporter:  zero_trust|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-parity|  Actual Points:
Parent ID:  #30994| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * parent:   => #30994


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #22893 [Core Tor/Tor]: prop224: Make intro point per-service and not per-descriptor

[Tor Bug Tracker & Wiki]

#22893: prop224: Make intro point per-service and not per-descriptor
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224-extra,   |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  7
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-
Changes (by asn):

 * points:  3 => 7


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs