Re: [tor-bugs] #30544 [Metrics/Library]: Using try-with-resources or close resource

[Tor Bug Tracker & Wiki]

#30544: Using try-with-resources or close resource
-+--
 Reporter:  fava |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Looks good! Merged to master. Thanks!

 Don't worry about ticket status. I receive an email for every change on
 this ticket, so I'll notice whenever there's something to review. It would
 just be more convenient to have the status changed to needs_review,
 because then the ticket would show up in queries, too. But that's not your
 fault!

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R, tbb-update  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201908R =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201908R, tbb-update


--
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] #28325 [Applications/Tor Browser]: Use go 1.11 module versioning support

[Tor Bug Tracker & Wiki]

#28325: Use go 1.11 module versioning support
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  Medium => High


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

Re: [tor-bugs] #28240 [Applications/Tor Browser]: Think about using mingw-w64 with dwarf exception support for rustc cross-compilation for 32bit Windows

[Tor Bug Tracker & Wiki]

#28240: Think about using mingw-w64 with dwarf exception support for rustc 
cross-
compilation for 32bit Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by gk:

Old description:

> Our workaround we currently use to cope with issues cross-compiling rustc
> for 32bit Windows us not upstreamable (see: https://github.com/rust-
> lang/rust/pull/55444 for the arguments). We could think about compiling
> with a mingw-w64 using dwarf exception support instead, see:
> (https://github.com/rust-embedded/cross/blob/master/docker/mingw.sh).
>
> However, we should take into account that we want to switch to a
> mingw-w64/clang-based toolchain soon and should start looking into this
> ticket not before the other (#28238) is done.

New description:

 Our workaround we currently use to cope with issues cross-compiling rustc
 for 32bit Windows is not upstreamable (see: https://github.com/rust-
 lang/rust/pull/55444 for the arguments). We could think about compiling
 with a mingw-w64 using dwarf exception support instead, see:
 (https://github.com/rust-embedded/cross/blob/master/docker/mingw.sh).

 However, we should take into account that we want to switch to a mingw-w64
 /clang-based toolchain soon and should start looking into this ticket not
 before the other (#28238) is done.

--

--
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] #26257 [Applications/Tor Browser]: tor-browser-builder might want to not build rustc

[Tor Bug Tracker & Wiki]

#26257: tor-browser-builder might want to not build rustc
--+--
 Reporter:  isis  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  rust, tbb-rbm |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


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

Re: [tor-bugs] #24465 [Applications/Tor Browser]: Snowflake broken if no libatomic on host

[Tor Bug Tracker & Wiki]

#24465: Snowflake broken if no libatomic on host
--+
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake, tbb-rbm, tbb-easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  snowflake, tbb-rbm => snowflake, tbb-rbm, tbb-easy


--
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] #24386 [Applications/Tor Browser]: Check if projects/firefox/mozconfig-linux-i686 changes are needed

[Tor Bug Tracker & Wiki]

#24386: Check if projects/firefox/mozconfig-linux-i686 changes are needed
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #23656| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Those are not needed (at least not for Firefox 68 ESR). We are done here.

--
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] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 FWIW: We are mostly done with our switch to Firefox 68 ESR toolchain-wise
 which might cause additional work to be done for this bug. `master` as of
 commit 2d3e92fc4f3e7961a469d5f0a50ebc9b067c08cc should have all the
 necessary changes. We don't expect huge changes anymore for the ESR
 68-based Tor Browser cycle.

--
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] #23811 [Applications/Tor Browser]: Investigate MinGW commit for create_locale thing

[Tor Bug Tracker & Wiki]

#23811: Investigate MinGW commit for create_locale thing
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-rbm, ff60-esr |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 We think we are good here with the switch to mingw-w64/clang.

--
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] #9898 [Applications/Tor Browser]: Provide a clean fix for the strcmpi issue in mingw-w64 for NSPR if TBBs are built with rbm

[Tor Bug Tracker & Wiki]

#9898: Provide a clean fix for the strcmpi issue in mingw-w64 for NSPR if TBBs 
are
built with rbm
--+
 Reporter:  gk|  Owner:  tom
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-rbm, ff60-esr |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 Using mingw-w64/clang for Firefox (and this NSPR) solves this issue.

--
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] #29118 [Applications/Tor Browser]: Provide ASLR for mingw-w64/clang by default

[Tor Bug Tracker & Wiki]

#29118: Provide ASLR for mingw-w64/clang by default
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, GeorgKoppen201902,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 We have fixed this bug for all projects which are currently using
 mingw-w64/clang (which is essentially just the browser). Thus, close it
 and let's reopen bugs in case we convert future projects to the new
 toolchain.

--
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] #28753 [Applications/Tor Browser]: Use Gradle with --offline when building the browser part

[Tor Bug Tracker & Wiki]

#28753: Use Gradle with --offline when building the browser part
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => closed
 * keywords:  tbb-mobile, tbb-rbm => tbb-mobile, tbb-rbm,
   TorBrowserTeam201908
 * resolution:   => fixed


Comment:

 That's done with the new toolchain for ESR 68 (#30324) and in particular
 with the patch for #30665.

--
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] #25834 [Applications/Tor Browser]: Use compiler dependent spec files for mingw-w64

[Tor Bug Tracker & Wiki]

#25834: Use compiler dependent spec files for mingw-w64
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tbb-rbm, TorBrowserTeam201809  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

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


Comment:

 We'll get rid of the spec file hack instead. A first step is done with the
 mingw-w64-clang toolchain (see: #28238), the remaining bits will be done
 in #31584.

--
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] #26345 [Applications/Tor Browser]: Disable tracking protection UI in FF67-esr

[Tor Bug Tracker & Wiki]

#26345: Disable tracking protection UI in FF67-esr
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * keywords:  ff68-esr, tbb-9.0-alpha-must, TorBrowserTeam201908 =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201908


--
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:
 |  cypherpunks
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:  1000
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 :(

 https://danwin1210.me/contact.php

--
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] #31010 [Applications/Tor Browser]: Rebase Tor Browser mobile/ patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#31010: Rebase Tor Browser mobile/ patches for Firefox ESR 68
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:  #30429   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:21 sysrqb]:
 > Okay, great! I rebased the commits (except the last one) on top of `tor-
 browser-68.1.0esr-9.0-1` (`adb1614b652a5be21e7f025d15a8ea48401eeb02`). You
 can reproduce this with: `git cherry-pick acat/30429+5..acat30429+5_tor-
 browser_android_68esr_54~` (where `acat/30429+5` is
 `677a3a505f714a9379735a189a43349c4097231a`).
 >
 > In any case, after cherry-picking all of the commits, I made a few
 modifications - including deleting the `Promise.resolve()`, as it was
 previously mentioned :)
 >
 > I have branch `bug31010_4`. There is an additional change needed in
 torbutton because

 Okay, let's try branch `bug31010_5` instead. The torbutton scripts are
 included directly in `` tags, and `torbutton_init()` is called during
 `BrowserApp.startup()` which is called `onLoad` from browser.xul. I think
 this should have the same affect as what happens on desktop.

--
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] #31549 [Core Tor/Tor]: Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

[Tor Bug Tracker & Wiki]

#31549: Authorities should stop listing relays running pre-0.2.9, or running 
0.3.0
through 0.3.4
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  042-can 041-backport consider-   |  Actual Points:
  backport-after-authority-test consider-|
  backport-after-0421|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  042-can 041-backport? =>
 042-can 041-backport consider-backport-after-authority-test consider-
 backport-after-0421
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:5 nickm]:
 > I've made a branch `ticket31549` with PR at
 https://github.com/torproject/tor/pull/1276 .

 I did a review, and requested some minor changes.

 dgoulet also asked a question:
 https://github.com/torproject/tor/pull/1276/files#r319148111

 > It is based on 041, in case we decide to backport.

 When do we want to make this change on the network?

 At the moment:
 * 3 authorities are on 0.4.1 and later.
 * 1 authority is on 0.4.2.0-alpha-dev.
 https://consensus-health.torproject.org/#authorityversions

 Here are the backport constraints:
 * release 0.4.2.1-alpha: End September?
 * finish test on moria1: mid to end September
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current

 Here are the deployment requirements:
 * backport to 0.4.1
 * get majority of authorities on 0.4.1
 * get a majority of authorities to upgrade to the point release containing
 the backport

 So I think we can drop these relays by October, if we want to.

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

Re: [tor-bugs] #31549 [Core Tor/Tor]: Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

[Tor Bug Tracker & Wiki]

#31549: Authorities should stop listing relays running pre-0.2.9, or running 
0.3.0
through 0.3.4
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  042-can 041-backport consider-   |  Actual Points:
  backport-after-authority-test consider-|
  backport-after-0421|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * cc: dgoulet (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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by teor):

 Replying to [comment:32 dgoulet]:
 > Replying to [comment:31 nickm]:
 > > Is there a flag we can stop giving them?
 >
 > We would need to remove HSIntro=4 basically from the 032, 033 and 034
 relays so the service will go in legacy mode and this bug is not in the
 legacy code.

 We could make working versions declare a new HSIntro version, and then
 make clients require that version.

 When we fix high-impact bugs in future, we should consider adding a new
 protocol version, and making clients require it. That's what protocol
 versions are for,

--
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] #31549 [Core Tor/Tor]: Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

[Tor Bug Tracker & Wiki]

#31549: Authorities should stop listing relays running pre-0.2.9, or running 
0.3.0
through 0.3.4
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  042-can 041-backport?  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:6 cypherpunks]:
 > Could we drop everything before 0.3.5 with the EOL of 0.2.9?

 Maybe. If we can convince enough 0.2.9 operators to upgrade,

--
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] #31425 [Circumvention/Snowflake]: Snowflake broker is sluggish and sometimes fails

[Tor Bug Tracker & Wiki]

#31425: Snowflake broker is sluggish and sometimes fails
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Low  |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  broker   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cypherpunks):

 Replying to [comment:6 cohosh]:
 > Please keep your comments on topic. This ticket is for problems with the
 broker being slow.
 I apologize for the misunderstanding but I was on-topic, what I wanted to
 convey was that since there were problems with connecting with snowflake
 there were less users of snowflake and hence less requests to the broker
 and hence this issue seemed to disappear (if we assume that it's caused by
 a rate liming of some sorts). And what may confirm this analysis further
 is that now it takes a ton of time for snowflake to bootstrap since I
 constantly get `504 Gateway Timeout`s, and it takes a ton of time for tabs
 to load again when I need to pick a new snowflake while browsing. This
 again makes snowflake completely  unusable for 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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => closed
 * resolution:   => fixed
 * parent:   => #30322


Comment:

 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] #28533 [Circumvention/BridgeDB]: bridgesdb: replace the message to mail support with a link to the documentation

[Tor Bug Tracker & Wiki]

#28533: bridgesdb: replace the message to mail support with a link to the
documentation
+---
 Reporter:  emmapeel|  Owner:  phw
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ex-sponsor-19   |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:  Sponsor30-can
+---

Comment (by ggus):

 Hi,

 In the last months we started to receive a lot of blank emails from mobile
 users (with "sent from my iPhone" signatures) in frontdesk queue.

 Intrigued by this phenomenon, I opened bridges.torproject.org on my mobile
 and, my hypothesis is that users are scrolling down all the page and
 instinctively selecting frontdesk email (hey, UX team! _o/ ).

 Also, there's an email icon on the website footer redirecting users to
 frontdesk.

 We should asap:

 - Remove frontdesk contact from the footer;
 - Change text to:

 {{{
 My bridges don't work! I need help!

 If your Tor Bridges don't work, please check our Tor Browser Manual -
 https://tb-manual.torproject.org/circumvention/ and our Support Portal -
 https://support.torproject.org/#censorship . If you need a new bridge,
 send an email to brid...@torproject.org and try again.
 }}}

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 The mingw patches look to 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] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

[Tor Bug Tracker & Wiki]

#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 Looks better, but you still have the patch for 1527534 in the config file
 and not deleted while removing it from the build script. Additionally, I
 am wondering why we need the `libclang.so.6` at all and then just for arm?
 Does Mozilla do the same? Could you add a comment on elaborating why this
 is needed for that architecture?

 I moved forward to apply the patches you have so far to have at least some
 nightly builds before we need to release the alpha. But we should fix up
 as many loose ends before that as we 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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:33 mcs]:
 > r=mcs
 > The patch looks good to me, and most importantly it seems to fix the
 problem. Maybe Richard should take a look at the mingw patches too, but I
 think we are good here.

 Sounds good to me. I'll leave the ticket open to wait for Richard's
 feedback here but merged the fix to `master` (commit
 a479eeb424496b781d7ea9cf7b2d9a6404d7c32f) to have it in our next nightly
 builds (there aren't that many before the first alpha needs to get out).

--
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] #29818 [Applications/Tor Browser]: adapt #13379 patch for 68esr

[Tor Bug Tracker & Wiki]

#29818: adapt #13379 patch for 68esr
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-update,ff68-esr,tbb-9.0-must-|  Actual Points:
  alpha, TorBrowserTeam201908|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:5 mcs]:
 > Testing on Windows 10 with both 64-bit and 32-bit Tor Browser builds
 shows that the updater is working and finding its dependent DLLs (things
 "just work" because the DLLs are in the same directory as updater.exe and
 on Windows the updater is not copied to a secondary location before it is
 launched). On Linux, Mozilla's rpath approach works fine. Finally, for
 macOS we included a fix in our rebased #4234 patch; see the
 AppendToLibPath() call here:
 > https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/xre/nsUpdateDriver.cpp?h=tor-
 browser-68.1.0esr-9.0-1#n731
 >
 > The above is a somewhat long way of saying we can close this ticket.
 Georg, if you agree please resolve this as fixed.

 Looks good to me. Did you know what rstrong meant by saying to add support
 for this ticket on Mozilla's side? Do we need to take some action here
 (see last comment in 1434666)?

--
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] #29818 [Applications/Tor Browser]: adapt #13379 patch for 68esr

[Tor Bug Tracker & Wiki]

#29818: adapt #13379 patch for 68esr
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-update,ff68-esr,tbb-9.0-must-|  Actual Points:
  alpha, TorBrowserTeam201908|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by mcs):

 Testing on Windows 10 with both 64-bit and 32-bit Tor Browser builds shows
 that the updater is working and finding its dependent DLLs (things "just
 work" because the DLLs are in the same directory as updater.exe and on
 Windows the updater is not copied to a secondary location before it is
 launched). On Linux, Mozilla's rpath approach works fine. Finally, for
 macOS we included a fix in our rebased #4234 patch; see the
 AppendToLibPath() call here:
 https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/xre/nsUpdateDriver.cpp?h=tor-
 browser-68.1.0esr-9.0-1#n731

 The above is a somewhat long way of saying we can close this ticket.
 Georg, if you agree please resolve this as 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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=mcs
 The patch looks good to me, and most importantly it seems to fix the
 problem. Maybe Richard should take a look at the mingw patches too, but I
 think we are good here.

--
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] #28822 [Applications/Tor Browser]: re-implement desktop onboarding for ESR 68

[Tor Bug Tracker & Wiki]

#28822: re-implement desktop onboarding for ESR 68
+--
 Reporter:  mcs |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908  |  Actual Points:
Parent ID:  #30429  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--

Comment (by gk):

 Additionally, upon further testing it seems to me that the details part of
 the circuit level and the security settings is not working as expected.
 While clicking on the former opens the DDG .onion, no tour through the
 display shows up trying to make the menu behind the security settings
 button visible by clicking on the option does not do anything either.

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

Re: [tor-bugs] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201908 =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201908R
 * status:  needs_revision => needs_review


Comment:

 Good stuff, bug in my setup then. ;) I have a patch for review up on my
 `bug_31567` branch (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_31567&id=a479eeb424496b781d7ea9cf7b2d9a6404d7c32f).

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:30 gk]:
 > I see. Well, it could be that Martin's patch opened a new hole while
 closing the previous bug. Or it could still be an issue with my setup. Or
 it could be related to me not using a full update setup but rather just
 your script. However, I somehow doubt the latter at least as using the
 updater executable from 9.0a4 + the newly created .mar file works.
 Additionally, it could be that you replacing the format specifiers killed
 that second, different bug as well. And there are probably some more
 explanations I forgot right now. :) Anyway, I've uploaded both my .exe and
 the signed .mar file I used, so folks can look at that independently from
 me and building own bundles.
 >
 > https://people.torproject.org/~gk/testbuilds/31567_3.exe
 > https://people.torproject.org/~gk/testbuilds/31567_3.exe.asc
 >
 > https://people.torproject.org/~gk/testbuilds/tor-browser-win64-tbb-
 nightly_en-US.mar
 > https://people.torproject.org/~gk/testbuilds/tor-browser-win64-tbb-
 nightly_en-US.mar.asc

 Here is what I have learned so far:
 1) Using my own build (with Martin's patch + my own signing certificate +
 my own mar file + my own update server) worked when I did the update
 interactively within Firefox. That's good news.

 2) When I tried again using my `updater-test.cmd` script with my same
 build and mar file I saw the `UPDATE_SETTINGS_FILE_CHANNEL` error. Next I
 added some logging and saw that the path for `update-settings.ini` was
 missing the `/Browser` path component at the end. When I fixed my test
 script by appending `/Browser` to`INSTALLDIR` (and to correctly copy the
 mar file to update.mar) it worked! My script now looks similar to the
 following:
 {{{
 set MARFILE=tor-browser-win64-tbb-nightly_en-US.mar
 set INSTALLDIR=C:\Users\USER\Desktop\tbtest\Browser
 set UPDATEDIR=%INSTALLDIR%\TorBrowser\UpdateInfo\updates\0

 mkdir %UPDATEDIR%
 copy %MARFILE% %UPDATEDIR%\update.mar
 pushd %INSTALLDIR%
 updater %UPDATEDIR% %INSTALLDIR% %INSTALLDIR%
 popd
 }}}

 3) The same script worked using the exe and mar file from comment:30.

 My conclusion is that Martin's patches fix this bug.

 And please accept my apology for wasting people's time by not getting the
 args right the first time for the manual/command line updater test!

--
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] #31587 [Applications/Tor Browser]: Conflicting metadata which could lead to fingerprinting

[Tor Bug Tracker & Wiki]

#31587: Conflicting metadata which could lead to fingerprinting
--+--
 Reporter:  bigsteve1337  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 This is because HTTP headers and JS navigator objects return different
 results (for now): by design: see #28290. Headers are always Windows (why
 give away free entropy), but (for now) JS will return one of four OSes due
 to breakage.

 Since all Mac users, or all Linux users, etc are in the same boat: there's
 no extra FPing here. Detecting your OS via other means is trivial anyway.

 Close as dupe of #28290 ?

--
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] #30862 [Applications/Tor Browser]: 10ms time precision via EXSLT date-time function

[Tor Bug Tracker & Wiki]

#30862: 10ms time precision via EXSLT date-time function
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-time-highres  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by Thorin):

 Am I missing something else? I can already get 1ms timing via other means

--
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] #31587 [Applications/Tor Browser]: Conflicting metadata which could lead to fingerprinting

[Tor Bug Tracker & Wiki]

#31587: Conflicting metadata which could lead to fingerprinting
--+--
 Reporter:  bigsteve1337  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Applications/Tor Browser
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Tor Browser Version: 60.8.0esr
 OS: MacOS Mojave

 When I go to http://whatsmyos.com/ it tells me I am using Windows 7, which
 is good.

 However, if I go to https://brave.com it figures out that I am on MacOS
 and automatically defaults to the MacOS download.

 This is conflicting metadata and is prone to fingerprinting (which is
 exactly what the fake Windows 7 info was trying to avoid).

 After checking on panopticlick, I realized the conflict comes from:

 User Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101
 Firefox/60.0

 Platform:   MacIntel

 Perhaps it's as easy as making the 'Platform' HTTP header just match the
 Windows user agent?

--
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] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

[Tor Bug Tracker & Wiki]

#28942: Evaluate pion WebRTC
+--
 Reporter:  backkem |  Owner:  cohosh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by cohosh):

 Replying to [comment:49 dcf]:
 > Replying to [comment:46 cohosh]:
 > > Update on this: I tried building with pion/webrtc v2.0.23 (using
 pion/sctp v1.6.4 and otherwise sticking to the versions specified in
 `go.mod` for webrtc v2.0.23) and it bootstraps fully.
 >
 > I tried this hint here:
 >  * [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/log/?h
 =pion-webrtc&id=6bfc0beea25295c04cb9a1753ea0a433786500e4 pion-webrtc]
 branch
 >  * https://people.torproject.org/~dcf/pt-bundle/tor-browser-pion-
 webrtc-20190901-6bfc0beea2/
 >
 > However it still doesn't work for me :/ Maybe I misunderstood what you
 suggested. I re-ran the [attachment:gomodtorbm gomodtorbm] script with
 pion-webrtc at v2.0.23 and restored the manual fixups. Then I singularly
 upgraded pion-sctp to v1.6.4. You can see exactly the changes
 [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/commit/?h
 =pion-webrtc&id=6bfc0beea25295c04cb9a1753ea0a433786500e4 here]. Does it
 look right?
 >
 > It's also possible there's something wrong with my local network setup.
 Can someone try one of the bundles in https://people.torproject.org/~dcf
 /pt-bundle/tor-browser-pion-webrtc-20190901-6bfc0beea2/ and see if it
 works?

 Interesting...

 I downloaded `https://people.torproject.org/~dcf/pt-bundle/tor-browser-
 pion-webrtc-20190901-6bfc0beea2/tor-browser-linux64-9.0a4_en-US.tar.xz`
 and extracted the `snowflake-client` executable and ran it in snowbox.

 The client bootstrapped fully to 100%. Logs are:

 {{{
 2019/09/01 13:30:25 Negotiating via BrokerChannel...
 Target URL:
 Front URL:   localhost:8080
 2019/09/01 13:30:27 SOCKS accepted:  {[scrubbed]  map[]}
 2019/09/01 13:30:30 BrokerChannel Response:
 200 OK

 2019/09/01 13:30:30 Received Answer.
 2019/09/01 13:30:30  Handler: snowflake assigned 
 2019/09/01 13:30:30 Buffered 316 bytes --> WebRTC
 2019/09/01 13:30:30 WebRTC: DataChannel.OnOpen
 2019/09/01 13:30:30 Flushed 316 bytes.
 2019/09/01 13:30:30 Traffic Bytes (in|out): 742 | 316 -- (1 OnMessages, 1
 Sends)
 2019/09/01 13:30:35 Traffic Bytes (in|out): 925165 | 348793 -- (123
 OnMessages, 49 Sends)
 2019/09/01 13:30:40 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/09/01 13:30:41 Traffic Bytes (in|out): 1813256 | 54848 -- (179
 OnMessages, 48 Sends)
 2019/09/01 13:30:48 Traffic Bytes (in|out): 5430 | 5430 -- (10 OnMessages,
 10 Sends)
 2019/09/01 13:30:49 WebRTC: closing DataChannel
 2019/09/01 13:30:49 WebRTC: closing PeerConnection
 2019/09/01 13:30:49 ConnectLoop: stopped.
 2019/09/01 13:30:49 WebRTC: DataChannel.OnClose [locally]
 2019/09/01 13:30:49 WebRTC: Closing
 2019/09/01 13:30:49 WebRTC: melted all 1 snowflakes.
 2019/09/01 13:30:49 copy loop ended
 2019/09/01 13:30:49  Handler: closed ---
 2019/09/01 13:30:49 SOCKS listening...
 2019/09/01 13:30:49 snowflake is done.
 }}}

 This was with a standalone proxy also running the pion library and with a
 standalone proxy without pion.

 Then I ran this in snowbox with only a browser-based proxy running and I
 got the same failure where it doesn't bootstrap past 10%. Log:

 {{{
 2019/09/01 13:42:28 Negotiating via BrokerChannel...
 Target URL:
 Front URL:   localhost:8080
 2019/09/01 13:42:28 BrokerChannel Response:
 200 OK

 2019/09/01 13:42:28 Received Answer.
 2019/09/01 13:42:38 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/09/01 13:42:48 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/09/01 13:42:50 SOCKS accepted:  {[scrubbed]  map[]}
 2019/09/01 13:42:50  Handler: snowflake assigned 
 2019/09/01 13:42:50 Buffered 321 bytes --> WebRTC
 2019/09/01 13:42:55 Traffic Bytes (in|out): 0 | 321 -- (0 OnMessages, 1
 Sends)
 2019/09/01 13:42:58 WebRTC: At capacity [1/1]  Retrying in 10 seconds...
 2019/09/01 13:42:58 WebRTC: No messages received for 30 seconds -- closing
 stale connection.
 2019/09/01 13:42:58 WebRTC: closing PeerConnection
 2019/09/01 13:42:58 WebRTC: Closing
 2019/09/01 13:42:58 copy loop ended
 2019/09/01 13:42:58  Handler: closed ---
 2019/09/01 13:42:58 SOCKS listening...
 }}}

 So a pion client must not be working well with the browser based proxie

Re: [tor-bugs] #31582 [Applications/Tor Browser]: Consider disabling AMO search field in add-ons dialog

[Tor Bug Tracker & Wiki]

#31582: Consider disabling AMO search field in add-ons dialog
--+--
 Reporter:  JeremyRand|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I believe this has already been proposed in another ticket, though I can't
 find it 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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:29 mcs]:
 > Replying to [comment:28 gk]:
 > > mcs/brade: Oh, and don't let my above comment stop you from debugging
 if you have the time and energy for that. :) Or let me know about some
 shortcuts I could take to figure out what is going on.
 >
 > OK. The thing that does not make sense to me is that on 2019-08-29 Kathy
 and I were able to successfully run an update with our own Windows build
 after we replaced all of the `%s` format specifiers with `%S`. That test
 was interactive (using our own mar file and update server, and with tor-
 browser just patched for our own signing certificate and to use a
 different `app.update.url`). If there was another mingw-w64 bug we should
 have encountered it during that test.

 I see. Well, it could be that Martin's patch opened a new hole while
 closing the previous bug. Or it could still be an issue with my setup. Or
 it could be related to me not using a full update setup but rather just
 your script. However, I somehow doubt the latter at least as using the
 updater executable from 9.0a4 + the newly created .mar file works.
 Additionally, it could be that you replacing the format specifiers killed
 that second, different bug as well. And there are probably some more
 explanations I forgot right now. :) Anyway, I've uploaded both my .exe and
 the signed .mar file I used, so folks can look at that independently from
 me and building own bundles.

 https://people.torproject.org/~gk/testbuilds/31567_3.exe
 https://people.torproject.org/~gk/testbuilds/31567_3.exe.asc

 https://people.torproject.org/~gk/testbuilds/tor-browser-win64-tbb-
 nightly_en-US.mar
 https://people.torproject.org/~gk/testbuilds/tor-browser-win64-tbb-
 nightly_en-US.mar.asc

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:28 gk]:
 > mcs/brade: Oh, and don't let my above comment stop you from debugging if
 you have the time and energy for that. :) Or let me know about some
 shortcuts I could take to figure out what is going on.

 OK. The thing that does not make sense to me is that on 2019-08-29 Kathy
 and I were able to successfully run an update with our own Windows build
 after we replaced all of the `%s` format specifiers with `%S`. That test
 was interactive (using our own mar file and update server, and with tor-
 browser just patched for our own signing certificate and to use a
 different `app.update.url`). If there was another mingw-w64 bug we should
 have encountered it during that test.

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 mcs/brade: Oh, and don't let my above comment stop you from debugging if
 you have the time and energy for that. :) Or let me know about some
 shortcuts I could take to figure out what is going on.

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 {{{
int result =
   ReadStrings(path, kUpdaterKeys, kNumStrings, updater_strings,
 "Settings");
 }}}
 causes `result` to be `6` which means `READ_ERROR` and I get garbage back
 for the channel ID. Hrm. Let me try finding out where exactly the reading
 fails. I wonder whether that's another instance of mingw-w64 bugs we need
 to get patched. :/

--
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] #31449 [Applications/Tor Browser]: Signing tools for 32bit Linux are 64bit now

[Tor Bug Tracker & Wiki]

#31449: Signing tools for 32bit Linux are 64bit now
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908,   |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:  #30321   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > As another data point: I looked at the mar-tools for Windows and macOS
 we currently get for 9.0a4. And there both mar and msbdiff are 64bit ELF
 binaries. So, that seems to be "normal" for cross-compiling...
 If they should be executed on host only (and not on target), then sure!

--
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] #31448 [Applications/Tor Browser]: gold and lld break linking 32bit Linux bundles we need to resort to bfd

[Tor Bug Tracker & Wiki]

#31448: gold and lld break linking 32bit Linux bundles we need to resort to bfd
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909|
Parent ID:  #30321   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 `gold`: https://patchwork.openembedded.org/patch/155471/
 `lld`: https://www.mail-archive.com/ports-
 chan...@openbsd.org/msg100711.html

--
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] #31449 [Applications/Tor Browser]: Signing tools for 32bit Linux are 64bit now

[Tor Bug Tracker & Wiki]

#31449: Signing tools for 32bit Linux are 64bit now
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908,   |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:  #30321   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 As another data point: I looked at the mar-tools for Windows and macOS we
 currently get for 9.0a4. And there both `mar` and `msbdiff` are 64bit ELF
 binaries. So, that seems to be "normal" for cross-compiling...

--
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] #31448 [Applications/Tor Browser]: gold and lld break linking 32bit Linux bundles we need to resort to bfd

[Tor Bug Tracker & Wiki]

#31448: gold and lld break linking 32bit Linux bundles we need to resort to bfd
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909|
Parent ID:  #30321   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:  tbb-rbm, ff68-esr => tbb-rbm, ff68-esr, tbb-9.0-must-alpha,
 TorBrowserTeam201909
 * cc: boklm (added)
 * parent:   => #30321


--
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] #31586 [HTTPS Everywhere]: Browser problems

[Tor Bug Tracker & Wiki]

#31586: Browser problems
-+--
 Reporter:  fantasy_man59@…  |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  HTTPS Everywhere
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Hi,

 I am using a Windows 7 laptop and have been using your browser but lately
 after your updates the tabs are not loading anymore. I stay in UAE and
 your site is blocked here therefore had to reinstall a lower version to
 get access to your site.

--
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] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

[Tor Bug Tracker & Wiki]

#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908, GeorgKoppen201908|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:13 sisbell]:
 > Looks like Signal created an apkdiff script that ignores resources.arsc
 >
 > https://github.com/signalapp/Signal-
 Android/blob/master/apkdiff/apkdiff.py

 This one doesn't seem to "fix" the problem, but only ignore it.

 >
 > Briar went the route of a deterministic file system
 >
 > https://code.briarproject.org/briar/briar-
 reproducer/commit/22d04ff8bba956ec9647fd583ec655df691e15e5

 This one could maybe work as a temporary workaround. However this requires
 fuse to be installed on the build machine, and I'm not sure if different
 distributions have different fuse versions/setup that could make things
 more complicate.

 >
 > A third route is to build and patch the gradle plugin ourselves but I
 have been unable to find the elusive change-id that google mentions.

 This sounds like the best way to fix it. However I have not even been able
 to find their source code repository so far. Do you know if they have one?

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:24 gk]:
 > Replying to [comment:21 mcs]:
 > > Replying to [comment:20 gk]:
 > > > Okay, I got past the cert error just to hit the
 `UPDATE_SETTINGS_FILE_CHANNEL` one. Might be due to my testing setup, hard
 to say from here. What I did was copying the release certs over so that
 they can be used for nightlies as well and then I just did a `make
 nightly-windows-x86_64`.
 > >
 > > I cannot think of a reason why what you did would lead to a failure.
 The `UPDATE_SETTINGS_FILE_CHANNEL` error is generated when the updater
 cannot read and/or parse the file `Browser\update-settings.ini`. The
 contents of that file should look similar on all platforms and for all
 "flavors" of our builds... something like:
 > > {{{
 > > [Settings]
 > > ACCEPTED_MAR_CHANNEL_IDS=torbrowser-torproject-release
 > > }}}
 >
 > Yes, that's what the file in the nightly build contains.

 I looked at the `mar` executable to check what ID actually gets embedded
 during the build process and it show Default `Channel ID: torbrowser-
 torproject-release`. So, this should be fine. I guess the next step is
 finding out what the updater thinks it got for a channel ID.

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Martin has confirmed that this is a correct C99-conformant behavior of
 mingw-w64, which automatically defaults to `__USE_MINGW_ANSI_STDIO` on
 crosses: https://bugzilla.mozilla.org/show_bug.cgi?id=1577872#c7

--
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] #31567 [Applications/Tor Browser]: NS_tsnprintf() does not handle %s correctly on Windows

[Tor Bug Tracker & Wiki]

#31567: NS_tsnprintf() does not handle %s correctly on Windows
-+-
 Reporter:  mcs  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:21 mcs]:
 > Replying to [comment:20 gk]:
 > > Okay, I got past the cert error just to hit the
 `UPDATE_SETTINGS_FILE_CHANNEL` one. Might be due to my testing setup, hard
 to say from here. What I did was copying the release certs over so that
 they can be used for nightlies as well and then I just did a `make
 nightly-windows-x86_64`.
 >
 > I cannot think of a reason why what you did would lead to a failure. The
 `UPDATE_SETTINGS_FILE_CHANNEL` error is generated when the updater cannot
 read and/or parse the file `Browser\update-settings.ini`. The contents of
 that file should look similar on all platforms and for all "flavors" of
 our builds... something like:
 > {{{
 > [Settings]
 > ACCEPTED_MAR_CHANNEL_IDS=torbrowser-torproject-release
 > }}}

 Yes, that's what the file in the nightly build contains.

--
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] #31549 [Core Tor/Tor]: Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

[Tor Bug Tracker & Wiki]

#31549: Authorities should stop listing relays running pre-0.2.9, or running 
0.3.0
through 0.3.4
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  042-can 041-backport?  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 Could we drop everything before 0.3.5 with the EOL of 0.2.9?

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