Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mwolfe):

 The UAE has two ISPs: Etisalat and du. When Dubai created free zones, it
 set up its own ISP, du, which had no blocks at all. Then the President in
 Abu Dhabi ordered all ISPs to report to the Telecommunications Regulatory
 Authority, or TRA, and all must block whatever TRA says. So the two are
 basically identical (owned by different sheikhs). On 1 Jan, the TRA
 ordered Tor blocked. This happened before (several years ago, and I have
 an old ticket on it), then Tor was unblocked, and now it's reblocked. But
 obsf4 gets around the block, except for 3 hours 3 days ago. I tried meek,
 and that worked for about 30 minutes, then I closed Tor, and when I tried
 to restart, it could access the network but could not load the network. If
 there was a DDoS then, that would explain it. Not Etisalat (my ISP) or the
 TRA, but the DDoS, since, after 3 hours, obfs4 started working again.

 Friday is the weekly holiday, which is the reason there's a spike. My
 physician told me about Tor in 2000, and I've been using it ever since.
 There are about 6 million people here, and almost all use the Internet
 daily, so 100,000 Tor users could be possible.

 Mostly, torproject.org is blocked, but since I downloaded Tor before it
 was blocked, no problem until they started doing more to block Tor. Now,
 of course, it's a drop down menu item if the regular obfs4 or meek work.
 If they don't, you sent me 3 bridges that are harder to find, so thanks.

 If there's anything I can help with, please ask. I used to use the
 unencrypted e-mail I check several times a day, but then decided that
 wasn't very smart, so now I use encrypted e-mail, which I only check once
 a day. The encrypted e-mail refuses to allow use from more than one
 country unless you give it a mobile it can check and see if you're you, so
 I set up Tor on one computer to always say I'm in the US, so it doesn't
 ask for my mobile number, and I only check that e-mail once a day.

--
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] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 I found [https://docs.rs/c_str_macro/1.0.2/c_str_macro/macro.c_str.html
 c_str_macro] which looks like it might help eliminate the explicit NUL in
 the string literal.  I'm not sure if we want to depend on that crate
 though.

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:9 dcf]:
 > Thanks for this information. I didn't know that. Do you know what the
 port numbers are, or any additional information? If so, please add it to
 the table at [[doc/MetricsTimeline#Unknown]]. (Seems like there should be
 a ticket for the UAE anomalies, but
 Took a bit of DDG search but I finally found the article that was talking
 about that: https://www.bleepingcomputer.com/news/security/nearly-one-
 million-systems-provide-guest-smb-access-most-are-linux/

 > There are 2,306,820 devices connected to the Internet at the moment that
 feature open ports for SMB services, the same protocol that was used to
 infect hundreds of thousands of computers with the WannaCry ransomworm a
 month ago.
 >
 > Of these, 42%, or nearly 970,000, provide "guest" access, meaning anyone
 can access data shared via the SMB file-sharing protocol without needing
 to provide authentication. [...] Samba itself is also plagued by a
 vulnerability called SambaCry that affects all Samba installations
 released in the past seven years. This flaw has been used to take over
 Linux servers with open SMB ports and install cryptocurrency miners. [...]
 Matherly points out that almost half of the devices that have Samba SMB
 guest access enabled are '''located on the network of Etisalat, a large
 ISP in UAE.'''

--
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] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt tor-dirauth pending-disaster  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Here's a clever way to do a unit test:

 Write all 1s to the struct.
 Clear sybils.
 Turn the consensus flags in the struct into a string using the standard
 function.
 Make sure the string is empty.

--
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] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I think Nick is right, checking for NULL functions could rapidly get out
 of control.
 (I don't think we should check for mandatory libraries. But then I asked
 myself: why bother to check at all?)

 I suggest we check that the zstd and lzma library functions are non-NULL
 at configure time. And fail if they are NULL.
 That way, builders get instant feedback if their linker flags or install
 are broken.

 People who design custom build processes will have to make sure they work
 themselves.

--
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] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt tor-dirauth pending-disaster  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [ticket:16849 teor]:
 > clear_status_flags_on_sybil contains a comment saying "it's easy to add
 a new flag but forget to add it to this clause."
 >
 > It looks like we may have forgot the following flags:
 > * is_hs_dir
 > * version_known?
 > * version_supports_extend2_cells?
 > * has_bandwidth
 > * has_exitsummary?
 > * bw_is_unmeasured? (set to 1?)
 > * bandwidth_kb
 > * has_guardfraction
 > * guardfraction_percentage

 It's been 2 years since this ticket was opened, are there's any new flags
 we should also clear?

 > To deal with the root cause, should we instead zero out the entire
 `routerstatus_t`, then copy the fields we need back in?
 > (This would zero new fields on sybils by default.)

 Do you think we should zero the struct, then copy across the fields we
 want to keep?
 Or do you think that touching the entire struct is a bad idea?

 We could make it easier to clear the flags by putting them in their own
 struct. But that's a pretty extreme refactor.

 > We could also implement a unit test for clear_status_flags_on_sybil that
 checks that certain (important?) flags are cleared, or that all flags are
 cleared (?).

 Would you like to write a unit test to make sure we clear important status
 flags?
 (It's important that we clear consensus flags like Guard, Exit, V2Dir, …)

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:7 cypherpunks]:
 > Replying to [comment:6 cypherpunks]:
 > > > I'm pretty sure that the relay users graph is bogus, and that there
 are not really 300,000 users
 > >
 > > With spikes on every [https://en.wikipedia.org/wiki/Jumu%27ah Friday]
 > Can't tell that from looking at shorter and more accurate ranges.

 If you want to look more precisely, you can download the CSV file that
 makes the graph.
 https://metrics.torproject.org/stats/clients.csv
 https://metrics.torproject.org/stats.html#clients
 The column you want is `clients`, which is the second to last.
 {{{#!html
 
 $ grep ,relay,ae, clients.csv
 ...
 2018-01-29,relay,ae,,,222127,451790,315812,77
 2018-01-30,relay,ae,,,200043,424856,336896,78
 2018-01-31,relay,ae,,,210268,369871,407466,80
 2018-02-01,relay,ae,,,257323,398240,445036,78
 2018-02-02,relay,ae,,,289167,485726,493804,80
 2018-02-03,relay,ae,,,215267,444106,390208,81
 2018-02-04,relay,ae,,,193048,382601,363009,85
 2018-02-05,relay,ae,,,203610,398592,361683,56
 
 }}}

 If you zoom in far enough on the graphs, there are grid lines for each
 week. The lines fall on Mondays, so yes, it looks like the spikes on on
 Fridays. I'm not sure if/how that's affected by time zones (i.e. I think
 the graphs count Friday in UTC, not in the UAE time zone).

 > BTW I said this back then on irc but no one seemed to care: it seems
 that one of their ISPs (is it the only one? It's probably named Etisalat
 IIRC) had/still has some ports open that most other ISPs in the world had
 blocked to protect their customers, this is without a shred of doubt a
 botnet.

 Thanks for this information. I didn't know that. Do you know what the port
 numbers are, or any additional information? If so, please add it to the
 table at [[doc/MetricsTimeline#Unknown]]. (Seems like there should be a
 ticket for the UAE anomalies, but

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:1 mwolfe]:
 > After 3 hours, Tor now opens in the UAE without a VPN. I still need meek
 to connect to any websites, but the problem of the network consensus not
 loading has gone away.

 This is strange--if you are able to download the network consensus, then
 you should also be able to connect to websites through Tor. (Unless there
 is some very unusual traffic pattern–based blocking, but that is
 unlikely.) I wonder if this was not actually blocking, but some temporary
 network error, or perhaps slowness caused by the
 [https://lists.torproject.org/pipermail/tor-
 project/2017-December/001604.html ongoing DDoS attack]?

 mwolfe, if you don't mind saying, what is your ISP?
 
([https://en.wikipedia.org/wiki/Category:Internet_service_providers_of_the_United_Arab_Emirates
 According to Wikipedia], there are only 2: Etisalat and du.)

--
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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  must-fix-before-033-stable, tor- |  Actual Points:
  relay, tor-dos, performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 Ok, after discussion on IRC with arma a bit this morning, I've ended up
 with a branch.

 This is untested (although it compiles and chutney is happy), there are no
 unit tests nor "in the wild" proper testing done on it for now.

 I just want to throw it here as a full draft on this because 1) it adds
 quite a bit of code and 2) I want a review of the code logic before going
 in review mode.

 Branch: `bug24767_033_01`

--
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] #21716 [Core Tor/Tor]: Avoid recursive call to routerlist_remove_old_routers via router_rebuild_store

[Tor Bug Tracker & Wiki]

#21716: Avoid recursive call to routerlist_remove_old_routers via
router_rebuild_store
--+
 Reporter:  anstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 No, an infinite loop is not a solution to indirect recursion.
 The code structure needs to be changed to avoid functions calling
 themselves indirectly.

--
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] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-dos tor-hs performance  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Ok, let's think about the service side in 0.3.4 and later.

--
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] #23873 [Core Tor/Tor]: Remove the return value of node_get_prim_orport()

[Tor Bug Tracker & Wiki]

#23873: Remove the return value of node_get_prim_orport()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  #24403  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 Thanks!
 Someone should review and compile this patch in the next few weeks.

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:6 cypherpunks]:
 > > I'm pretty sure that the relay users graph is bogus, and that there
 are not really 300,000 users
 >
 > With spikes on every [https://en.wikipedia.org/wiki/Jumu%27ah Friday]
 Can't tell that from looking at shorter and more accurate ranges.

 BTW I said this back then on irc but no one seemed to care: it seems that
 one of their ISPs (is it the only one? It's probably named Etisalat IIRC)
 had/still has some ports open that most other ISPs in the world had
 blocked to protect their customers, this is without a shred of doubt a
 botnet.

--
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] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over

[Tor Bug Tracker & Wiki]

#24767: All relays are constantly connecting to down relays and failing over and
over
-+-
 Reporter:  arma |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  must-fix-before-033-stable, tor- |  Actual Points:
  relay, tor-dos, performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:8 arma]:
 > My thoughts for the first design would be:
 >
 > * No need for a complex backoff thing. Just remember the failure for 60
 seconds, and during those 60 seconds, send back a destroy immediately.
 Reducing from n attempts per minute down to 1 per minute should be enough
 to help us survive until the clients get a consensus update and stop
 asking us to try.

 60 seconds seems sensible.
 And it's about the timeframe it takes to restart a relay (tor takes 30s to
 shut down by default).
 Anything less would be ineffective.

 > * We should avoid having this cached-failure thing impact client
 behavior. That is, it should cause *other people's* circuits to get
 destroys, but it shouldn't auto-fail our own client attempts. Maybe we
 should change how the client behaves, but if so, let's do it later, and
 not introduce subtle breakage in something we'll be considering for
 backport.

 Excluding origin circuits seems fine.
 (So does including them, but only on relays. But we already have backoff
 and limits on origin circuits.)

 > * Hm! I was going to say "but rep_hist_note_connect_failed() won't work
 if the relay isn't in our consensus", but actually, it is simply based on
 intended identity digest of the next destination, so it does look like we
 can reuse the data struct. Except, shouldn't we also be caching the
 IP:port that failed? Otherwise somebody can ask us to extend to a victim
 digest at an unworkable IP:port, and we'll cache "failure!" and then
 refuse all the legit cells going to the right address for the next minute.

 When we introduce IPv6 extends from relays (#24404), we only want to fail
 attempts to a single IP address, and not the whole relay. So dual-stack
 relays will get two attempts to other dual-stack relays: an IPv4 attempt,
 and an IPv6 attempt. I like that design, it makes sense to try both.

--
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] #15518 [Core Tor/Tor]: Tor considers routers in the same IPv6 /16 to be "in the same subnet"

[Tor Bug Tracker & Wiki]

#15518: Tor considers routers in the same IPv6 /16 to be "in the same subnet"
-+-
 Reporter:  isis |  Owner:  Samdney
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, path, path-bias, tor-client|  Actual Points:
  easy   |
Parent ID:  #24393   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by Samdney):

 * status:  new => assigned
 * owner:  (none) => Samdney


--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > I'm pretty sure that the relay users graph is bogus, and that there are
 not really 300,000 users

 With spikes on every [https://en.wikipedia.org/wiki/Jumu%27ah Friday]

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * keywords:   => censorship block ae


Comment:

 This is a small bump in bridge users, mostly obfs4, in the past few days.

 [[Image(userstats-relay-country-
 ae-2017-11-08-2018-02-06-off.png,width=600)]]
 [https://metrics.torproject.org/userstats-relay-
 country.html?start=2017-11-08=2018-02-06=ae=off link]

 [[Image(userstats-bridge-country-ae-2017-11-08-2018-02-06.png,width=600)]]
 [https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-11-08=2018-02-06=ae link]

 [[Image(userstats-bridge-combined-
 ae-2017-11-08-2018-02-06.png,width=600)]] [https://metrics.torproject.org
 /userstats-bridge-combined.html?start=2017-11-08=2018-02-06=ae
 link]

 However that bump needs to put in context. I don't think the stats from
 the UAE are completely reliable, because of anomalies that began in 2017.
 (See the entries with places=ae at [[doc/MetricsTimeline#Unknown]]. I'm
 pretty sure that the relay users graph is bogus, and that there are not
 really 300,000 users. The bridge user count has been messed up in the past
 as well.

 [[Image(userstats-relay-country-
 ae-2017-01-01-2018-02-06-off.png,width=600)]]
 [https://metrics.torproject.org/userstats-relay-
 country.html?start=2017-01-01=2018-02-06=ae=off link]

 [[Image(userstats-bridge-country-ae-2017-01-01-2018-02-06.png,width=600)]]
 [https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-01-01=2018-02-06=ae link]

 [[Image(userstats-bridge-combined-
 ae-2017-01-01-2018-02-06.png,width=600)]] [https://metrics.torproject.org
 /userstats-bridge-combined.html?start=2017-01-01=2018-02-06=ae
 link]

--
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] #24453 [Core Tor/Tor]: Reduce log spam when child process creation failed

[Tor Bug Tracker & Wiki]

#24453: Reduce log spam when child process creation failed
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bootstrap, s8-errors  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:   => bootstrap, s8-errors
 * sponsor:   => Sponsor8-can


--
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] #25162 [Core Tor/Tor]: Perhaps, use zstd's "static-only" functions

[Tor Bug Tracker & Wiki]

#25162: Perhaps, use zstd's "static-only" functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Hello71):

 so maybe I'm missing something, but I'm pretty sure
 tor_zstd_get_version_str should just call ZSTD_versionString? or is that
 just because it doesn't work on debian stable? if so, we should comment
 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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * Attachment "userstats-bridge-combined-ae-2017-01-01-2018-02-06.png"
 added.

 https://metrics.torproject.org/userstats-bridge-
 combined.html?start=2017-01-01=2018-02-06=ae

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * Attachment "userstats-bridge-country-ae-2017-01-01-2018-02-06.png"
 added.

 https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-01-01=2018-02-06=ae

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * Attachment "userstats-relay-country-ae-2017-01-01-2018-02-06-off.png"
 added.

 https://metrics.torproject.org/userstats-relay-
 country.html?start=2017-01-01=2018-02-06=ae=off

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * Attachment "userstats-bridge-combined-ae-2017-11-08-2018-02-06.png"
 added.

 https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-11-08=2018-02-06=ae

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * Attachment "userstats-bridge-country-ae-2017-11-08-2018-02-06.png"
 added.

 https://metrics.torproject.org/userstats-bridge-
 country.html?start=2017-11-08=2018-02-06=ae

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * Attachment "userstats-relay-country-ae-2017-11-08-2018-02-06-off.png"
 added.

 https://metrics.torproject.org/userstats-relay-
 country.html?start=2017-11-08=2018-02-06=ae=off

--
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] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 I'm conflicted about this.

 I don't think doing this is a particularly good solution. I added the
 changes to the zlib code in case we move away from Tor's
 `TOR_SEARCH_LIBRARY()` where this issue isn't detected.

 The other option is that we add the `configure` checks that
 `TOR_SEARCH_LIBRARY()` adds to `configure` to ensure that our zstd/lzma
 code works in the same way.

 This is of course still an issue for OpenSSL, Libevent, and other external
 dependencies we may have.

 Would you prefer a `configure` check to this or should we do something
 entirely different?

--
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] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by catalyst):

 Replying to [comment:6 nickm]:
 > So  would you be okay with this patch if it were NOTICE instead?
 Yes.  Or hearing some rationale for why INFO is more appropriate than
 NOTICE.

--
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] #25165 [Applications/Tor Browser]: Remove "Start " in "Start Tor Browser" shortcut

[Tor Bug Tracker & Wiki]

#25165: Remove "Start " in "Start Tor Browser" shortcut
--+--
 Reporter:  scootergrisen |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Trivial   |   Keywords:  Windows shortcut
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In Windows the shourtcut for starting Tor Browser is called "Start Tor
 Browser".
 I suggest removing the "Start " part so its just "Tor Browser".
 Other software shortcuts just have the name of the software and does not
 start with "Start " in front 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] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 I'm okay with these.  I'd like others (arma? karsten?) to get a chance to
 sign off on them first, though.

--
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] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+--

Comment (by igt0):

 Updated the code:

 Tor Browser Build:

 Bug 25013: Remove torbutton from the tor browser build
 ​https://github.com/igortoliveira/tor-browser-
 build/commit/9fd151714fe5d992d9cce12e3bb59259eea154d2

 Tor Browser:

 Bug 25013: Move Tor Button source code to the browser/extensions
 directory
 ​https://github.com/igortoliveira/tor-
 browser/commit/910da3b9edb7068a1084443e75653487997bd978

 Bug 25013: Integrate Tor Button in the browser build system
 ​https://github.com/igortoliveira/tor-
 browser/commit/e931e6ae94c5a884b6f2c8ccb96568952bcd

 Bug 25013: Use anonymous function to keep the torbutton.js and
 preferences.js scope limited to the parent function
 ​https://github.com/igortoliveira/tor-
 browser/commit/16c360da0b7edc0218fdeac7e5300f83e9bbc0a6

 Bug 25013: Initialize startup.homepage in the startup-observer
 component
 ​https://github.com/igortoliveira/tor-
 browser/commit/a28341162bf034299f4b060098e62cf515716e37

 Bug 25013: Add translation tool
 https://github.com/igortoliveira/tor-
 browser/commit/18b32a5144aa915327cf4584873bcb25a18b625e

--
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] #25162 [Core Tor/Tor]: Perhaps, use zstd's "static-only" functions

[Tor Bug Tracker & Wiki]

#25162: Perhaps, use zstd's "static-only" functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 Looks good to me.

--
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] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 This removes some stats from a SIGUSR1 signal but it also reduces
 considerably the size of the or history map in rephist.c

 If you think we should keep this for the stats that it gives us, feel free
 to toss the branch out.

 See branch: `ticket25163_033_01`

--
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] #22089 [Applications/Tor Browser]: Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

[Tor Bug Tracker & Wiki]

#22089: Add Decentraleyes to slighten off a bit Exit traffic and work around 
some
CDNs blocking of Tor
-+-
 Reporter:  imageverif   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * Attachment "0001-Bug-22089-Add-the-Decentraleyes-addon-to-the-Tor-
 Browser.patch" 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] #24473 [Webpages/Website]: People page edit - remove Linda

[Tor Bug Tracker & Wiki]

#24473: People page edit - remove Linda
--+-
 Reporter:  ewyatt|  Owner:  atagar
 Type:  task  | Status:  closed
 Priority:  Low   |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by atagar):

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


Comment:

 Hi all, think I'm gonna resolve this. I reached out to the council to
 check about suspending Linda's membership (since she's clearly gone) so we
 could proceed but didn't hear back. Without that her membership will
 expire in four months or so at which point I'll take care of this.

--
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] #22089 [Applications/Tor Browser]: Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

[Tor Bug Tracker & Wiki]

#22089: Add Decentraleyes to slighten off a bit Exit traffic and work around 
some
CDNs blocking of Tor
-+-
 Reporter:  imageverif   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  new => needs_review


--
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] #25164 [Applications/Tor Browser]: Reproducable Tor Browser for Android builds

[Tor Bug Tracker & Wiki]

#25164: Reproducable Tor Browser for Android builds
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:  #19675
   Points:|   Reviewer:
  Sponsor:|
--+
 Make sure the apks builds are reproducable.

--
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] #22089 [Applications/Tor Browser]: Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

[Tor Bug Tracker & Wiki]

#22089: Add Decentraleyes to slighten off a bit Exit traffic and work around 
some
CDNs blocking of Tor
-+-
 Reporter:  imageverif   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 In light of the DDoS that the Tor network is undergoing, I thought it
 would be the best time to write a patch for this since with it, (1)
 popular traffic to CDNs for JS libraries will be virtually gone, helping
 thus to ward off some exit traffic; (2) it helps with usability when a CDN
 blocks a particular Tor exit used in a circuit for a website that relies
 on said CDN for a JS library.

--
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] #22089 [Applications/Tor Browser]: Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

[Tor Bug Tracker & Wiki]

#22089: Add Decentraleyes to slighten off a bit Exit traffic and work around 
some
CDNs blocking of Tor
-+-
 Reporter:  imageverif   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * Attachment "0001-Bug-22089-Add-Decentraleyes.patch" 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] #25116 [Core Tor/Tor]: hs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuit

[Tor Bug Tracker & Wiki]

#25116: hs: circuit_log_ancient_one_hop_circuits() should probably not log 
single
onion service rendezvous circuit
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, sos, easy, 031-backport  |  Actual Points:
  029-backport 032-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-hs, sos, easy => tor-hs, sos, easy, 031-backport
 029-backport 032-backport
 * status:  needs_review => merge_ready
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.2.x-final


Comment:

 great! merging  to 0.3.3, marking for possible backport.

--
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] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=mcs
 The latest patch looks good to me, and it compiles and seems to work on
 macOS.

--
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] #25022 [Metrics/Website]: Convert all scripts used for building to Ant tasks

[Tor Bug Tracker & Wiki]

#25022: Convert all scripts used for building to Ant tasks
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 web.git/commit/?h=task-25022 this commit], which replaces the last script
 used in metrics-web (I hope).

 I think it is also not necessary anymore to store the specs' jsps, but I
 don't remember the exact reasoning.

--
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] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by nickm):

 So  would you be okay with this patch if it were NOTICE 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] #25162 [Core Tor/Tor]: Perhaps, use zstd's "static-only" functions

[Tor Bug Tracker & Wiki]

#25162: Perhaps, use zstd's "static-only" functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * component:  - Select a component => Core Tor/Tor


Comment:

 Okay, I've added the configure option.  If you still like it, let's take
 this in 0.3.4.

--
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] #24232 [Webpages/Website]: 404 Dead Link in "Who Uses Tor"

[Tor Bug Tracker & Wiki]

#24232: 404 Dead Link in "Who Uses Tor"
--+
 Reporter:  t0mmy |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by t0mmy):

 * status:  needs_review => closed
 * 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] #24335 [Webpages/Website]: Ramy Raoof bio edit needed

[Tor Bug Tracker & Wiki]

#24335: Ramy Raoof bio edit needed
--+
 Reporter:  t0mmy |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by t0mmy):

 * status:  needs_review => closed
 * 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] #25162 [- Select a component]: Perhaps, use zstd's "static-only" functions

[Tor Bug Tracker & Wiki]

#25162: Perhaps, use zstd's "static-only" functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 - `358b609e9dfd503cc25985d197a92610cbbe9f3d` looks good, but maybe it
 would make sense to have a `configure` option to make it easy to test if
 the code still works when `ZSTD_STATIC_LINKING_ONLY` is disabled if that
 is a concern?
 - `7cb954209d2c3b12d0d60a46a74f2c31ad6d48c5` looks good.
 - `f98cb5d3552666ede73137d998162094d5a31a1a` looks good.
 - `a77a366b87fb04a878392284241fe72850b4dd88` looks good.

--
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] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
-+-
 Reporter:  arma |  Owner:  arma
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client 031-backport  |  Actual Points:
  032-backport   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-

Comment (by nickm):

 (The branch is now `arma_bug22212_031` in my public repo, with a fixed
 changes file.)

--
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] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
-+-
 Reporter:  arma |  Owner:  arma
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client 031-backport  |  Actual Points:
  032-backport   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-
Changes (by nickm):

 * keywords:  tor-client => tor-client 031-backport 032-backport


Comment:

 Merged to 0.3.3, marking for possible backport.

--
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] #25037 [Webpages/Website]: Add press clips to website

[Tor Bug Tracker & Wiki]

#25037: Add press clips to website
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 I'm not able to add a new version of the file with a new clip; Trac keeps
 thinking it's spam. Emailing file 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] #24824 [Metrics/Website]: Either sleep() or wait() in a synchronized block

[Tor Bug Tracker & Wiki]

#24824: Either sleep() or wait() in a synchronized block
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Changed to `Thread.sleep()`, added the missing `this.`, rebased to master,
 pushed, deployed. Closing. 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

Re: [tor-bugs] #16849 [Core Tor/Tor]: clear_status_flags_on_sybil might want to clear more flags

[Tor Bug Tracker & Wiki]

#16849: clear_status_flags_on_sybil might want to clear more flags
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, SponsorS-deferred, technical-  |  Actual Points:
  debt tor-dirauth pending-disaster  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


--
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] #25159 [Metrics/Consensus Health]: Don't omit unused known flags from relay summary

[Tor Bug Tracker & Wiki]

#25159: Don't omit unused known flags from relay summary
--+--
 Reporter:  Sebastian |  Owner:  tom
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Sebastian):

 * status:  new => needs_review


--
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] #20815 [Applications/Tor Browser]: UI dev work of security slider experience on Orfox

[Tor Bug Tracker & Wiki]

#20815: UI dev work of security slider experience on Orfox
--+--
 Reporter:  isabela   |  Owner:  synzvato
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, android   |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:   => #24855


--
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] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Looks okay at first glance, but: do we really want to go down this road?
 Will we wind up doing this for every shared library we use in Tor,
 including libevent and openssl?

 Also, zlib is mandatory: we can't keep going if zlib isn't going to work.

--
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] #24653 [Applications/Tor Browser]: Apply security slider improvements made on desktop back to mobile

[Tor Bug Tracker & Wiki]

#24653: Apply security slider improvements made on desktop back to mobile
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-torbutton, tbb-  |  Actual Points:
  security-slider|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 Should be this closed as a dup/replaced by #24855?

--
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] #24368 [Core Tor/Tor]: Tune zstd parameters to decrease memory usage during streaming

[Tor Bug Tracker & Wiki]

#24368: Tune zstd parameters to decrease memory usage during streaming
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, compression, zstd, tor-  |  Actual Points:
  dir, 032-backport  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * Attachment "zstd_mem_menchmarks.py" 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] #24368 [Core Tor/Tor]: Tune zstd parameters to decrease memory usage during streaming

[Tor Bug Tracker & Wiki]

#24368: Tune zstd parameters to decrease memory usage during streaming
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, compression, zstd, tor-  |  Actual Points:
  dir, 032-backport  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 I've run some initial experimentation, and here's what I found:

 Adjusting the pre-set values shouldn't be necessary if instead we tell
 zstd to build its own parameters (using `ZSTD_getCParams()` or
 `ZSTD_getParams`), with the `estimatedSrcSize` argument to tell zstd how
 big we expect the input to be.

 I also think that our current estimates are higher than zstd actually
 uses, which is a good thing.  I'm attaching a python script that I used
 for these tests; it requires the "zstandard" package.

 Now the catch here is that we can't actually adjust the parameters to
 anything besides the presets unless we use the "advanced" (a.k.a "static-
 only" zstd APIs).  I've opened ticket #25162 about doing that safely.  But
 the complexity is enough that I think we should call this an 0.3.4.x
 ticket: it is more than simply tweaking a couple of numbers.

--
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] #24957 [Applications/Tor Browser]: Orfox Help menu item goes to mozilla support page

[Tor Bug Tracker & Wiki]

#24957: Orfox Help menu item goes to mozilla support page
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #24926 [Applications/Tor Browser]: Should Tor Browser for Android support the PanicKit Panic Trigger Intent?

[Tor Bug Tracker & Wiki]

#24926: Should Tor Browser for Android support the PanicKit Panic Trigger 
Intent?
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #24920 [Applications/Tor Browser]: Orfox has tabs and private tabs, we only want private tabs

[Tor Bug Tracker & Wiki]

#24920: Orfox has tabs and private tabs, we only want private tabs
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #24919 [Applications/Tor Browser]: Orfox still prompts for enabling Sync

[Tor Bug Tracker & Wiki]

#24919: Orfox still prompts for enabling Sync
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
--+---
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-rephist, code-removal
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The rephist subsystem seems to track EXTEND cells attempt (on the client
 side) but the overall results of this is not used except in
 `rep_hist_dump_stats()`. This is the only use of `link_history_t` also
 afaict. See:

 {{{
 void rep_hist_note_extend_succeeded(const char *from_name,
 const char *to_name);
 void rep_hist_note_extend_failed(const char *from_name, const char
 *to_name);
 }}}

 Furthermore, tor tracks downtime and uptime of relays but actually never
 use that information anywhere. See:

 {{{
 void rep_hist_note_connect_failed(const char* nickname, time_t when);
 void rep_hist_note_connect_succeeded(const char* nickname, time_t when);
 void rep_hist_note_disconnect(const char* nickname, time_t when);
 void rep_hist_note_connection_died(const char* nickname, time_t when);
 }}}

 The side effect of this is that we keep adding objects to the
 `history_map` that are wasting memory and never used in the end except
 when we dump statistics.

 By removing this, we would cleanup quite a bit of code and effectively
 make the `or_history_t` object *ONLY* useful to directory authorities for
 relay reachability tracking.

--
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] #25093 [Webpages/Website]: https://newsletter-master.torproject.org is down

[Tor Bug Tracker & Wiki]

#25093: https://newsletter-master.torproject.org is down
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * status:  new => closed
 * 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] #23144 [Applications/Orbot]: Orfox UserAgent is very old. Please upgrade to modern version (52 or above).

[Tor Bug Tracker & Wiki]

#23144: Orfox UserAgent is very old. Please upgrade to modern version (52 or
above).
+
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-mobile  |  Actual Points:
Parent ID:  #19675  | Points:
 Reviewer:  |Sponsor:
+
Changes (by sysrqb):

 * status:  new => closed
 * resolution:   => fixed
 * parent:  19675 => #19675


Comment:

 This was already corrected in https://github.com/guardianproject/tor-
 browser/commit/9669dbf94b6be41c7a67c965b8995d933c1b4e9e.

--
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] #22171 [Applications/Tor Browser]: Review networking calls in esr45-esr52 diff of ./android/* closer

[Tor Bug Tracker & Wiki]

#22171: Review networking calls in esr45-esr52 diff of ./android/* closer
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-mobile  |  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


Comment:

 We may be able to close this and use the other proxy-bypass-audit tickets
 instead, but we can evaluate after we start auditing.

--
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] #25162 [- Select a component]: Perhaps, use zstd's "static-only" functions

[Tor Bug Tracker & Wiki]

#25162: Perhaps, use zstd's "static-only" functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See my branch `25162_zstd_static`. What do you think?

--
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] #22170 [Applications/Tor Browser]: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy safety on Android

[Tor Bug Tracker & Wiki]

#22170: Check uses of ch.boye.httpclientandroidlib.impl.client.* for proxy 
safety
on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-mobile,|  Actual Points:
  TorBrowserTeam201802   |
Parent ID:  #19675   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #21863 [Applications/Tor Browser]: Ensure proxy safety on Android when switching to ESR 52

[Tor Bug Tracker & Wiki]

#21863: Ensure proxy safety on Android when switching to ESR 52
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-mobile, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201802   |
Parent ID:  #19675   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by sysrqb):

 * parent:  19675 => #19675


Comment:

 This may be a dup of #22170 and maybe #19077, #19076. It may be smart
 making this a parent of those.

--
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] #19076 [Applications/Tor Browser]: Make sure that networking code in AndroidMediaResourceServer is no problem for OrFox

[Tor Bug Tracker & Wiki]

#19076: Make sure that networking code in AndroidMediaResourceServer is no 
problem
for OrFox
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #22059 [Applications/Tor Browser]: Remove screencasting code on mobile as well

[Tor Bug Tracker & Wiki]

#22059: Remove screencasting code on mobile as well
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, tbb-proxy-bypass  |  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


Comment:

 Orfox already disables this pref, but we should audit it and confirm.

--
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] #19077 [Applications/Tor Browser]: Make sure that networking code in sutagent is no problem for OrFox

[Tor Bug Tracker & Wiki]

#19077: Make sure that networking code in sutagent is no problem for OrFox
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #18864 [Applications/Tor Browser]: Make sure Orfox is not affected by Android code using SOCKS_DGRAM

[Tor Bug Tracker & Wiki]

#18864: Make sure Orfox is not affected by Android code using SOCKS_DGRAM
--+---
 Reporter:  gk|  Owner:  (none)
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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] #24796 [Applications/Tor Browser]: Review all requested and required Android permissions

[Tor Bug Tracker & Wiki]

#24796: Review all requested and required Android permissions
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19675| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * parent:  19675 => #19675


--
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: #19675, #24855, #24856

[Tor Bug Tracker & Wiki]

Batch modification to #19675, #24855, #24856 by sysrqb:
parent to #5709

--
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] #25161 [Metrics/CollecTor]: Fix another memory problem with the webstats bulk import

[Tor Bug Tracker & Wiki]

#25161: Fix another memory problem with the webstats bulk import
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Replying to [comment:1 iwakeh]:
 > I didn't take a close look at the proposed code changes/additions, yet.
 In #25100 I suggested to partition the import by date, b/c that gives the
 reduction of heap usage and also is fine for the bulk import where we know
 one-file-one-date is true.

 Yes, my code implements such a partition by date. Though you have a point
 there with one-file-one-date. I could simplify the code a lot. Let me do
 that. (I think it won't affect the memory issue, though.)

 > > Or is this just the operation where we happen to run out of memory
 from accumulating stuff over time, and where fixing this issue would just
 mean that we're failing somewhere else, shortly after?
 >
 > I think this is the case.  We're also - opposed to all other CollecTor
 modules - compressing before writing.

 Okay. So maybe there's room for improvement here.

 > What heap setting is used, 8G?  How many cores are available?

 `-Xmx16g` with 16 GiB RAM available. 4 cores.

--
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] #25161 [Metrics/CollecTor]: Fix another memory problem with the webstats bulk import

[Tor Bug Tracker & Wiki]

#25161: Fix another memory problem with the webstats bulk import
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Quote from #25100 comment 16:

  The second quarter 2017 of logs from weschniakowii amounts to 32M
 (compressed) and can be processed in 36min using 8G. The entire year won't
 work with just 8G.

  85min and 16G are needed for the entire available archives of
 meronense and weschniakowii together (compressed 59M). The used heap
 median usage is 8.5G and the max 15.8G.

  So, depending on the hardware a conservative import strategy might be
 to import slices of quarters with subsequent CollecTor runs.

--
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: #19675, #24855, #24856

[Tor Bug Tracker & Wiki]

Batch modification to #19675, #24855, #24856 by sysrqb:
parent to 5709

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22059, #24796, #18864, #19076, ...

[Tor Bug Tracker & Wiki]

Batch modification to #22059, #24796, #18864, #19076, #19077, #21863, #22170, 
#22171, #23144, #24919, #24920, #24926, #24957 by sysrqb:
parent to 19675

--
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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * owner:  (none) => dcf
 * component:  - Select a component => Obfuscation/Censorship analysis


Comment:

 
[https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki/CensorshipByCountry/UAE
 Censorship Wiki. UAE]

--
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] #25161 [Metrics/CollecTor]: Fix another memory problem with the webstats bulk import

[Tor Bug Tracker & Wiki]

#25161: Fix another memory problem with the webstats bulk import
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 I didn't take a close look at the proposed code changes/additions, yet.
 In #25100 I suggested to partition the import by date, b/c that gives the
 reduction of heap usage and also is fine for the bulk import where we know
 one-file-one-date is true.

 > Or is this just the operation where we happen to run out of memory from
 accumulating stuff over time, and where fixing this issue would just mean
 that we're failing somewhere else, shortly after?

 I think this is the case.  We're also opposed to all other CollecTor
 modules compressing before writing.

 What heap setting is used, 8G?  How many cores are available?

--
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] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

 * cc: irl (added)


Comment:

 Replying to [comment:17 iwakeh]:
 > The commits look fine (also commented on #16513 for the two related to
 that ticket), pass the usualy tests

 Sounds great. Thanks for checking!

 > I leave this on review as the solution plan and graphs might need
 feedback from others, too.

 irl, that would be you. Any thoughts? :)

 > Next steps in comment:16 seem fine to me.

 Okay.

--
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] #23706 [Core Tor/Tor]: Tor's seccomp sandbox does not know about the syscall epoll_pwait

[Tor Bug Tracker & Wiki]

#23706: Tor's seccomp sandbox does not know about the syscall epoll_pwait
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  seccomp, sandbox, musl,  |  Actual Points:
  029-backport, 031-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  seccomp, sandbox, musl => seccomp, sandbox, musl,
 029-backport, 031-backport
 * status:  new => merge_ready
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.1.x-final


Comment:

 Marking it as a backport candidate, maybe.

--
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] #25162 [- Select a component]: Perhaps, use zstd's "static-only" functions

[Tor Bug Tracker & Wiki]

#25162: Perhaps, use zstd's "static-only" functions
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I think maybe we can make this safe if we explicitly check that the
 compile version matches the runtime version. (Thanks to Hello71 for the
 tip)

--
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] #23706 [Core Tor/Tor]: Tor's seccomp sandbox does not know about the syscall epoll_pwait

[Tor Bug Tracker & Wiki]

#23706: Tor's seccomp sandbox does not know about the syscall epoll_pwait
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  seccomp, sandbox, musl  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by ahf):

 I believe this was fixed in `d2d6a1b082fa0eac8b6478889a0c28bf05e48073`?

--
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] #24824 [Metrics/Website]: Either sleep() or wait() in a synchronized block

[Tor Bug Tracker & Wiki]

#24824: Either sleep() or wait() in a synchronized block
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


--
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] #24824 [Metrics/Website]: Either sleep() or wait() in a synchronized block

[Tor Bug Tracker & Wiki]

#24824: Either sleep() or wait() in a synchronized block
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 As this is not about synchronizing concurrent access to the index, but
 simply for letting a requesting thread wait until an index might be
 available, the Thread.sleep solution seems more appropriate.
 (Unrelated: There is a `this.` missing in the while condition.)

--
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] #25161 [Metrics/CollecTor]: Fix another memory problem with the webstats bulk import

[Tor Bug Tracker & Wiki]

#25161: Fix another memory problem with the webstats bulk import
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I'm running a modified CollecTor that sanitizes webstats with some tweaks
 towards bulk importing existing webstats. In particular, it reads files in
 slices of 10 MiB plus another 2 MiB that overlap with the next slice. I
 just pushed the changes [https://gitweb.torproject.org/karsten/metrics-
 db.git/commit/?h=webstats-
 slices=6c1a266d726ceedf4518e7521a6ed58a6764aca4 here].

 First of all, the runtime is okay. Not great, but okay. It takes 36
 minutes to sanitize 10 MiB. We have 927 MiB of files, so 93 slices, which
 is going to take ~2.5 days.

 However, I ran into an out-of-memory problem at the 6th slice:

 {{{
 2018-02-06 13:30:36,499 INFO o.t.c.w.SanitizeWeblogs:116 Processing 20
 logs for dist.torproject.org on archeotrichon.torproject.org.
 2018-02-06 13:40:28,968 ERROR o.t.c.c.CollecTorMain:71 The webstats module
 failed: null
 java.lang.OutOfMemoryError: null
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
 at
 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at
 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 at
 java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
 at
 java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
 at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
 at
 java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160)
 at
 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at
 java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
 at
 java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.findCleanWrite(SanitizeWeblogs.java:127)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.startProcessing(SanitizeWeblogs.java:91)
 at
 org.torproject.collector.cron.CollecTorMain.run(CollecTorMain.java:67)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM
 limit
 at
 java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300)
 at java.lang.StringCoding.encode(StringCoding.java:344)
 at java.lang.StringCoding.encode(StringCoding.java:387)
 at java.lang.String.getBytes(String.java:958)
 at
 
org.torproject.descriptor.log.LogDescriptorImpl.collectionToBytes(LogDescriptorImpl.java:119)
 at
 
org.torproject.descriptor.log.WebServerAccessLogImpl.(WebServerAccessLogImpl.java:72)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.storeSanitized(SanitizeWeblogs.java:147)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.lambda$findCleanWrite$3(SanitizeWeblogs.java:127)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs$$Lambda$38/1233367077.accept(Unknown
 Source)
 at
 java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
 at
 java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
 at
 
java.util.concurrent.ConcurrentHashMap$EntrySpliterator.forEachRemaining(ConcurrentHashMap.java:3606)
 at
 java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
 at
 java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
 at
 java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
 at 

Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:46 karsten]:
 > How about `mostRecentStatusMillis`?

 Perfect!

--
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] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 The commits look fine (also commented on #16513 for the two related to
 that ticket), pass the usualy tests

 I leave this on review as the solution plan and graphs might need feedback
 from others, too.

 Next steps in comment:16 seem fine to me.

--
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] #24133 [Webpages/Website]: community.torproject.org work

[Tor Bug Tracker & Wiki]

#24133: community.torproject.org work
--+--
 Reporter:  isabela   |  Owner:  isabela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #21222| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Hi!
 I have been working on the Comms portal + the six internal pages.

 A lot of sections need content. I'd like to have it in order to review the
 most accurate mockups on the next iteration.

 Feel free to navigate the portal and make comments on the prototype:

 !https://marvelapp.com/4471ig9/screen/35696611

--
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] #22990 [Metrics/Library]: Add a heartbeat log message indicating progress and estimated time left

[Tor Bug Tracker & Wiki]

#22990: Add a heartbeat log message indicating progress and estimated time left
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Fixup commit 03d5496 looks good. Squashed everything, rebased to master,
 and pushed. Closing. 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

Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by karsten):

 How about `mostRecentStatusMillis`?

--
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] #24340 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall prctl) (asan only) (was: (Sandbox) Caught a bad syscall attempt (syscall prctl))

[Tor Bug Tracker & Wiki]

#24340: (Sandbox) Caught a bad syscall attempt (syscall prctl) (asan only)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox, libasan  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

--
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] #24339 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall mprotect) (asan only) (was: (Sandbox) Caught a bad syscall attempt (syscall mprotect))

[Tor Bug Tracker & Wiki]

#24339: (Sandbox) Caught a bad syscall attempt (syscall mprotect) (asan only)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final
 * type:  defect => enhancement


Comment:

 Moving to 0.3.4

--
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] #24340 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall prctl)

[Tor Bug Tracker & Wiki]

#24340: (Sandbox) Caught a bad syscall attempt (syscall prctl)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox, libasan  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * type:  defect => enhancement
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Moving to 0.3.4.

--
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] #24368 [Core Tor/Tor]: Tune zstd parameters to decrease memory usage during streaming

[Tor Bug Tracker & Wiki]

#24368: Tune zstd parameters to decrease memory usage during streaming
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, compression, zstd, tor-  |  Actual Points:
  dir, 032-backport  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * owner:  (none) => ahf
 * status:  new => assigned


--
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] #25154 [Applications/Tor Browser Sandbox]: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64

[Tor Bug Tracker & Wiki]

#25154: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64
--+-
 Reporter:  ln5   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 Replying to [comment:6 yawning]:
 > My plan has been to cease work on it utterly after the 7.5 stable time
 frame, so you'll get your wish sooner than later, go bother someone else.

 Sorry, didn't mean it in an offensive way since I valued your work on the
 sandbox and continue to value your other non-sandboxy work.

 > That said, there's things that Mozilla's sandbox will never handle
 correctly that are applicable to Tor Browser.

 True, but at least we can take comfort in the fact that the situation is
 orders of magnitude better than it was pre-sandboxed-ESR52.

--
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] #21716 [Core Tor/Tor]: Avoid recursive call to routerlist_remove_old_routers via router_rebuild_store

[Tor Bug Tracker & Wiki]

#21716: Avoid recursive call to routerlist_remove_old_routers via
router_rebuild_store
--+
 Reporter:  anstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by aruna1234):

 It's not a typical recursion, where the function calls itself, but is
 surely an issue, as this:

 if (!(flags & RRS_DONT_REMOVE_OLD))
 routerlist_remove_old_routers();
 leads to a call to routerlist_remove_old_routers(), which in turn leads to
 two calls to the calling function.

 Maybe a while loop replacing the if condition would resolve this?

 while(!(flags & RRS_DONT_REMOVE_OLD))...

 make check ran without fail.

--
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] #25154 [Applications/Tor Browser Sandbox]: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64

[Tor Bug Tracker & Wiki]

#25154: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64
--+-
 Reporter:  ln5   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Replying to [comment:5 cypherpunks]:
 > lol just nuke `sandboxed-tor-browser` already, or kill it with fire.
 FF60 ESR has currently sandbox level '''4''', from `about:support` in the
 latest nightly,

 My plan has been to cease work on it utterly after the 7.5 stable time
 frame, so you'll get your wish sooner than later, go bother someone else.
 That said, there's things that Mozilla's sandbox will never handle
 correctly that are applicable to Tor Browser.

--
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] #25154 [Applications/Tor Browser Sandbox]: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64

[Tor Bug Tracker & Wiki]

#25154: Tab crashing in sandboxed 8.0a1, sandbox 0.0.16, linux x86_64
--+-
 Reporter:  ln5   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by cypherpunks):

 lol just nuke `sandboxed-tor-browser` already, or kill it with fire. FF60
 ESR has currently sandbox level '''4''', from `about:support` in the
 latest nightly,

 || Seccomp-BPF (System Call Filtering) || true ||
 || Seccomp Thread Synchronization || true ||
 || User Namespaces ||true||
 || Content Process Sandboxing ||true||
 || Media Plugin Sandboxing ||   true  ||
 || Content Process Sandbox Level ||  4   ||
 || Effective Content Process Sandbox Level ||   4   ||

--
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