Re: [tor-bugs] #32071 [Core Tor/Tor]: Remove perl scripts from development process?

[Tor Bug Tracker & Wiki]

#32071: Remove perl scripts from development process?
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by teor:

Old description:

> There are a few perl5 scripts in our development process:
>
> {{{
> [1099]$ git grep /usr/bin/perl
>  [...]
> contrib/or-tools/checksocks.pl:#!/usr/bin/perl -w
> scripts/coccinelle/test-operator-cleanup:#!/usr/bin/perl -w -p -i
> scripts/codegen/gen_linux_syscalls.pl:#!/usr/bin/perl -w
> scripts/maint/checkLogs.pl:#!/usr/bin/perl -w
> scripts/maint/checkOptionDocs.pl.in:#!/usr/bin/perl -w
> scripts/maint/checkSpace.pl:#!/usr/bin/perl
> scripts/maint/check_config_macros.pl:#!/usr/bin/perl -w
> scripts/maint/findMergedChanges.pl:#!/usr/bin/perl
> scripts/maint/updateCopyright.pl:#!/usr/bin/perl -i -w -p
> scripts/test/cov-exclude:#!/usr/bin/perl -p -i
> }}}
>
> We could do any of the following:
>* Declare that perl5 is lovely and we don't care.
>* Declare that perl5 is ugly but not really a problem.
>* Declare that we will no longer require perl, and migrate all of
> these scripts to python and/or bash+sed+awk+etc
>* Declare that we will only allow perl as a "better sed/awk", and
> migrate all of the more complex scripts to python and/or bash+sed+awk,
> but leaves the others asd perl.
>
> I am excluding these possibilities, but the imp of the perverse demands
> that I mention them:
>* Migrate to perl6 ^W raku

New description:

 There are a few perl5 scripts in our development process:

 {{{
 [1099]$ git grep /usr/bin/perl
  [...]
 contrib/or-tools/checksocks.pl:#!/usr/bin/perl -w
 scripts/coccinelle/test-operator-cleanup:#!/usr/bin/perl -w -p -i
 scripts/codegen/gen_linux_syscalls.pl:#!/usr/bin/perl -w
 scripts/maint/checkLogs.pl:#!/usr/bin/perl -w
 scripts/maint/checkOptionDocs.pl.in:#!/usr/bin/perl -w
 scripts/maint/checkSpace.pl:#!/usr/bin/perl
 scripts/maint/check_config_macros.pl:#!/usr/bin/perl -w
 scripts/maint/findMergedChanges.pl:#!/usr/bin/perl
 scripts/maint/updateCopyright.pl:#!/usr/bin/perl -i -w -p
 scripts/test/cov-exclude:#!/usr/bin/perl -p -i
 }}}

 We could do any of the following:
* Declare that perl5 is lovely and we don't care.
* Declare that perl5 is ugly but not really a problem.
* Declare that we will no longer require perl, and migrate all of these
 scripts to python and/or bash+sed+awk+etc
* Declare that we will only allow perl as a "better sed/awk", and
 migrate all of the more complex scripts to python and/or bash+sed+awk, but
 leaves the others asd perl.

 I am excluding these possibilities, but the imp of the perverse demands
 that I mention them:
* Migrate to perl6 {{{^W}}} raku

--

--
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] #32143 [Core Tor/Tor]: Build some CI jobs with ALL_BUGS_ARE_FATAL

[Tor Bug Tracker & Wiki]

#32143: Build some CI jobs with ALL_BUGS_ARE_FATAL
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  042-should
Actual Points:|  Parent ID:  #32141
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 Follow-up to #32141.

 We should probably build with ALL_BUGS_ARE_FATAL for some of the check,
 stem, and chutney jobs. (But not for coverage or distcheck.)

--
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] #32142 [Metrics/Onionoo]: Release Onionoo 7.0-1.21.0

[Tor Bug Tracker & Wiki]

#32142: Release Onionoo 7.0-1.21.0
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Let's put out a new Onionoo release to ship the missing dependency
 (#32062) and fix the rDNS bug (#31941). I'll work on this 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

[tor-bugs] #32141 [Core Tor/Tor]: single onion v3 IPv6 intro circuit BUG() warnings

[Tor Bug Tracker & Wiki]

#32141: single onion v3 IPv6 intro circuit BUG() warnings
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  042-should, ipv6, tor-hs
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Looks like some of our assertions are wrong in single onion IPv6 mode, but
 chutney still succeeds:

 {{{
 Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal
 assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in
 intro_circ_is_ok at src/feature/hs/hs_client.c:491. Stack trace: (on Tor
 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
 Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal
 assertion !(desc == NULL) failed in setup_intro_circ_auth_key at
 src/feature/hs/hs_client.c:685. Stack trace: (on Tor 0.4.3.0-alpha-dev
 d616214e474084fd) Number: 1
 Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:491:
 intro_circ_is_ok: Non-fatal assertion
 !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (Future instances
 of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev
 d616214e474084fd) Number: 1
 Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:685:
 setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed.
 (Future instances of this warning will be silenced.) (on Tor 0.4.3.0
 -alpha-dev d616214e474084fd) Number: 1
 }}}
 https://travis-ci.org/torproject/tor/jobs/599435523#L3431

--
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] #31992 [Applications/Tor Browser]: Remove apktool workaround in #31564

[Tor Bug Tracker & Wiki]

#31992: Remove apktool workaround in #31564
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:  0.25
 Reviewer:|Sponsor:
--+--

Comment (by eighthave):

 One potential problem with using `apktool` to assemble actual releases:
 it is considered a suspicious mark since these reassembly techniques are
 mostly used by malware:
 
https://rednaga.io/2016/07/31/detecting_pirated_and_malicious_android_apps_with_apkid/

--
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] #32140 [Core Tor/Tor]: single onion: Padding negotiated cell from wrong hop

[Tor Bug Tracker & Wiki]

#32140: single onion: Padding negotiated cell from wrong hop
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  042-should
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 As of master commit d616214e47, I occasionally see these errors in
 chutney:
 {{{
 PASS: single-onion-v23
 Detail: chutney/tools/warnings.sh /home/dev/chutney/net/nodes.1571380287
 Warning: Padding negotiated cell from wrong hop on circuit 11 Number: 1
 Warning: Received circuit padding stop command for unknown machine.
 Number: 1
 }}}

--
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] #32139 [Core Tor/Tor]: Disable dirauth and relay options when those modules are disabled

[Tor Bug Tracker & Wiki]

#32139: Disable dirauth and relay options when those modules are disabled
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-design, network-team-roadmap-
 Severity:  Normal   |  october
Actual Points:   |  Parent ID:  #31851
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor31-can  |
-+-
 Here's what we want to change in this ticket:

 * --disable-module-dirauth (and, by implication, --disable-module-relay)
   * Disables *AuthoritativeDir*, and MinUptimeHidServDirectoryV2 options
 * Maybe these options should move under Directory Authority Server
 Options in the man page
   * Disables all the options under Directory Authority Server Options

 * --disable-module-relay
   * disable DirPort, DirCache, ORPort, and sets ClientOnly to 1
   * Disables all the other options under Directory Server Options
   * Disables all the other options under Server Options
   * Disables the --list-fingerprint, RelayBandwidth*,
 MaxAdvertisedBandwidth, PerConnBW*, and ServerTransportPlugin options
 * Maybe some of these options should move under Server Options in the
 man page

 These changes should be much easier after the config refactor.

--
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] #31497 [Circumvention/Snowflake]: Link Cupcake from snowflake.torproject.org

[Tor Bug Tracker & Wiki]

#31497: Link Cupcake from snowflake.torproject.org
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 Why would this be needed? Isn't it the case that Cupcake has a slower
 response rate from its maintainer (e.g. last time when bamsoftware.com was
 blacklisted and an update had to be 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] #30842 [Applications/Tor Browser]: Unable to start Tor: java.io.IOException: Control port file not created on Android 4.1.2

[Tor Bug Tracker & Wiki]

#30842: Unable to start Tor: java.io.IOException: Control port file not created 
on
Android 4.1.2
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201910  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  tbb-mobile, TorBrowserTeam201910R => tbb-mobile,
 TorBrowserTeam201910


Comment:

 What happens if you use the esr60 branch as the reporter did?

--
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] #32138 [Applications/Tor Browser]: Clicking the 'new Identity' button in full screen causes the top and bottom of the browser to show white bars that do not go away

[Tor Bug Tracker & Wiki]

#32138: Clicking the 'new Identity' button in full screen causes the top and 
bottom
of the browser to show white bars that do not go away
--+--
 Reporter:  Dbryrtfbcbhgf |  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 Dbryrtfbcbhgf):

 Replying to [comment:1 Thorin]:
 > The white bars are letterboxing, that's normal. It's stepping your width
 in `200`'s and height in `100`'s to allow for the maximum real estate used
 in the inner window. In your attachment, your inner window is approx
 `1334` pixels, but your viewport height is only `1200` - so that's a
 little weird: I would have expected it to be `1300`.
 >
 > When you first went to FS, did the inner window not get letterboxed?
 >
 > FWIW: on windows 7, if I enter FS, I get letterboxed. When I mouse up to
 show the chrome and click new Identity, I get a new 1000x1000px window
 >
 When TorBrowser is brought out of full screen the letterboxing should not
 be visible, bringing Torbrowser out of full screen by clicking the green
 minimize button, Does Not show the letterboxing white bars, they only
 appear when clicking the new Identity button in full screen.

--
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] #32138 [Applications/Tor Browser]: Clicking the 'new Identity' button in full screen causes the top and bottom of the browser to show white bars that do not go away

[Tor Bug Tracker & Wiki]

#32138: Clicking the 'new Identity' button in full screen causes the top and 
bottom
of the browser to show white bars that do not go away
--+--
 Reporter:  Dbryrtfbcbhgf |  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):

 The white bars are letterboxing, that's normal. It's stepping your width
 in `200`'s and height in `100`'s to allow for the maximum real estate used
 in the inner window. In your attachment, your inner window is approx
 `1334` pixels, but your viewport height is only `1200` - so that's a
 little weird: I would have expected it to be `1300`.

 When you first went to FS, did the inner window not get letterboxed?

 FWIW: on windows 7, if I enter FS, I get letterboxed. When I mouse up to
 show the chrome and click new Identity, I get a new 1000x1000px window

--
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] #32138 [Applications/Tor Browser]: Clicking the 'new Identity' button in full screen causes the top and bottom of the browser to show white bars that do not go away

[Tor Bug Tracker & Wiki]

#32138: Clicking the 'new Identity' button in full screen causes the top and 
bottom
of the browser to show white bars that do not go away
--+--
 Reporter:  Dbryrtfbcbhgf |  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:
--+--
Changes (by Dbryrtfbcbhgf):

 * Attachment "Screen Shot 2019-10-17 at 9.46.28 PM.png" 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

[tor-bugs] #32138 [Applications/Tor Browser]: Clicking the 'new Identity' button in full screen causes the top and bottom of the browser to show white bars that do not go away

[Tor Bug Tracker & Wiki]

#32138: Clicking the 'new Identity' button in full screen causes the top and 
bottom
of the browser to show white bars that do not go away
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications/Tor Browser
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Full-screening TorBrowser then clicking the 'new Identity' button causes
 tor browser to come out of full screen and the top and bottom of the
 browser have large white bars.
 1. Open TorBrowser 9.0a8 on macOS 10.15 and click the green full screen
 button.
 2. Click the 'new Identity' button and choose to have a new Identity.
 Image attached showing the white bars.

--
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] #32124 [Core Tor/Tor]: Interpret --disable-module-dirauth=no correctly

[Tor Bug Tracker & Wiki]

#32124: Interpret --disable-module-dirauth=no correctly
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-october, tor-   |  Actual Points:
  build, no-backport?|
Parent ID:  #32123   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-can
-+-

Comment (by teor):

 Replying to [comment:5 nickm]:
 > I'd suggest 042 and forward, but master-only is also okay.  The fix
 looks fine.
 >
 > Do we make this mistake anywhere else?

 We made a similar mistake for tcmalloc, all the other uses of
 AC_ARG_{WITH,WITHOUT,ENABLE,DISABLE} are fine.

 > Please feel free to merge once there's a changes file.

 I'll do a similar fix, and merge both to 0.4.2 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

[tor-bugs] #32137 [Core Tor/Tor]: Split feature/include.am out of core/include.am

[Tor Bug Tracker & Wiki]

#32137: Split feature/include.am out of core/include.am
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-design
Actual Points: |  Parent ID:  #31851
   Points:  0.5|   Reviewer:
  Sponsor:  Sponsor31-can  |
---+--
 It seems a bit weird that we're missing feature/include.am, maybe it's
 time to fix 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] #32136 [- Select a component]: Cancel my subscription

[Tor Bug Tracker & Wiki]

#32136: Cancel my subscription
--+-
 Reporter:  Sherrylouisehodges|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

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


Comment:

 Hi, I'm sorry, that's not our app, it's probably a scam.

 You'll have to ask Apple, or the developer.

--
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] #31705 [Core Tor/Tor]: Add sufficient coccinelle tooling to run coccinelle without stress

[Tor Bug Tracker & Wiki]

#31705: Add sufficient coccinelle tooling to run coccinelle without stress
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  042-should|  Actual Points:  1.5
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:  Sponsor31-can
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Seems fine, but there are some typos and minor commit message/content
 issues.

 How do you want to make progress on the remaining files?
 Do you want to set up CI, so we preserve cocci compatibility over time?

--
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] #32136 [- Select a component]: Cancel my subscription

[Tor Bug Tracker & Wiki]

#32136: Cancel my subscription
+--
 Reporter:  Sherrylouisehodges  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  - Select a component
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I bought the Tor App from Apple ITunes, with a free trial.  Cancel it,  I
 don’t want to pay for this app.  It has a recurring charge of $9.99.  I
 don’t want it.  Thank you

--
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] #31999 [Core Tor/Tor]: Default log file is handled inconsistently

[Tor Bug Tracker & Wiki]

#31999: Default log file is handled inconsistently
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #31241| Points:
 Reviewer:  teor  |Sponsor:  Sponsor31-can
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Seems fine to me.

 I was wondering how we should test this as I was reading it:
 * can we test the individual functions like we used to test
 options_validate()?
 * should we try to test using our command-line harness?

 It would also be nice to remove unused variables in this ticket:
 {{{
 /* 29211 TODO: Remove this from the API. */
 }}}

--
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] #32037 [Circumvention/meek]: Tor Browser 8.5.5 Encounters Javascript problem when attempting to use Meek-Azure bridges

[Tor Bug Tracker & Wiki]

#32037: Tor Browser 8.5.5 Encounters Javascript problem when attempting to use
Meek-Azure bridges
-+-
 Reporter:  bakertaylor28|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Circumvention/meek   |Version:  Tor:
 |  0.4.1.5
 Severity:  Major| Resolution:  wontfix
 Keywords:  meek, meek-azure, bridge,|  Actual Points:
  javascript, jar|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bakertaylor28):

 Interesting thing is that the problem has seemed to have spontaneously
 fixed itself without intervention.

--
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] #32063 [Core Tor/Tor]: CID 1454769: Resource leaks in build_establish_intro_dos_extension()

[Tor Bug Tracker & Wiki]

#32063: CID 1454769:  Resource leaks in build_establish_intro_dos_extension()
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, memleak,  |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:  teor  |Sponsor:  Sponsor27-must
--+
Changes (by teor):

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


Comment:

 Looks good, merged to 0.4.2 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] #32097 [Applications/Tor Browser]: Fix conflicts in mobile onbarding while rebasing to esr68.2.0

[Tor Bug Tracker & Wiki]

#32097: Fix conflicts in mobile onbarding while rebasing to esr68.2.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  TorBrowserTeam201910R, tbb-9.0-must  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:4 sysrqb]:
 > I used `22182890f20069201b37a0e8d9a849d2e54fcc25` as the new base. I
 reverted (in order):

 Sorry, it's based on `8b37b0197138897a766056fe3d4e6c53b891cdcb`, branch
 `bug32097_02`.

--
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] #32097 [Applications/Tor Browser]: Fix conflicts in mobile onbarding while rebasing to esr68.2.0

[Tor Bug Tracker & Wiki]

#32097: Fix conflicts in mobile onbarding while rebasing to esr68.2.0
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  TorBrowserTeam201910R, tbb-9.0-must  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  new => needs_review
 * keywords:  TorBrowserTeam201910, tbb-9.0-must => TorBrowserTeam201910R,
 tbb-9.0-must


Comment:

 I used `22182890f20069201b37a0e8d9a849d2e54fcc25` as the new base. I
 reverted (in order): `484ec9407da4234000a73d2426f09de62de0274e`
 `ab8797462cefdaf99d10e1981f2a168750cc697a`
 `303c1ef548d23dfd0d8aa1e9e61481c1baea02a8`
 `896fa0df588de10b22e827b8fc69daa9e05d`
 `1c54037a5bb7ded841b5a795041772a4571944f9`
 `a7cc5967877636728e29ea865dc46a2889b7de58`
 `a3f466a3ac73f0d11f3f3ba054173087e66a0ab5` and then rebased `origin/tor-
 browser-68.1.0esr-9.0-3` onto the result.

 I fear we may have more problems with this in the future if/when Mozilla
 modify the onboarding panels again. I felt resolving the merge conflict
 wasn't easy to review, but we can reconsider this if needed.

 I pushed branch `bug32097_02` based on 68.2.0esr.

--
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] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

[Tor Bug Tracker & Wiki]

#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910R, tbb-9.0   |  Actual Points:
  -must-alpha, tbb-proxy-bypass  |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:23 sysrqb]:
 > >> CustomTabsActivity.java - Several methods emit potentially external
 Intents
 > > My only concern here is onLoadRequest() when the scheme isn't handled
 by the browser. That's the only place where the user wasn't prompted. I
 don't know how the customtabs UI should handle this situation. We can
 break this functionality for now, until we find how this should be done
 correctly.
 >
 > This is included in the patch for #26529, but in this case we don't
 prompt. #26529 seemed like the better commit, but I can move this into its
 own commit.

 I pushed `bug31144_05` with only this patch on top of `68.1.0esr-9.0-3`.

--
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] #31497 [Circumvention/Snowflake]: Link Cupcake from snowflake.torproject.org

[Tor Bug Tracker & Wiki]

#31497: Link Cupcake from snowflake.torproject.org
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arlolra):

 I like it!

 Note that the patch is missing the translation string in
 `proxy/static/_locales/en_US/messages.json` (alas, the redundancy there is
 unfortunate).

--
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] #31109 [Circumvention/Snowflake]: Better gamify the UX for snowflake extension

[Tor Bug Tracker & Wiki]

#31109: Better gamify the UX for snowflake extension
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension, ux-team, |  Actual Points:
  anti-censorship-roadmap-october|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by arlolra):

 From https://addons.mozilla.org/en-US/firefox/addon/torproject-
 snowflake/reviews/1432746/

   how to test this work or not?

 which is a similar question to what bridge operators ask,

   17:20:03  we certainly don't need to but "does my bridge work?" is
 a very common question among new operators and we should have a useful
 response to it

 From today's discussion http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-10-17-16.59.log.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

[tor-bugs] #32135 [Circumvention/BridgeDB]: Write BridgeDB metrics parser and analyse existing data

[Tor Bug Tracker & Wiki]

#32135: Write BridgeDB metrics parser and analyse existing data
+---
 Reporter:  phw |  Owner:  phw
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  |   Keywords:  s30-o21a1
Actual Points:  |  Parent ID:  #31274
   Points:  2   |   Reviewer:
  Sponsor:  |
+---
 We've been collecting BridgeDB usage metrics (#9316) for a while now. It's
 time to write a parser for our metrics format, run it over our data, and
 extract insight from it. Questions that come to mind are:
 * How stable are our request patterns?
 * What's the ranking of PT popularity?
 * How many (un)successful requests are there broken down by distributor?

--
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] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

[Tor Bug Tracker & Wiki]

#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910R, tbb-9.0   |  Actual Points:
  -must-alpha, tbb-proxy-bypass  |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 >> CustomTabsActivity.java - Several methods emit potentially external
 Intents
 > My only concern here is onLoadRequest() when the scheme isn't handled by
 the browser. That's the only place where the user wasn't prompted. I don't
 know how the customtabs UI should handle this situation. We can break this
 functionality for now, until we find how this should be done correctly.

 This is included in the patch for #26529, but in this case we don't
 prompt. #26529 seemed like the better commit, but I can move this into its
 own commit.

 {{{
 diff --git
 a/mobile/android/base/java/org/mozilla/gecko/customtabs/CustomTabsActivity.java
 b/mobile/android/base/java/org/mozilla/gecko/customtabs/CustomTabsActivity.java
 index c75962da35a7..438f462755f6 100644
 ---
 a/mobile/android/base/java/org/mozilla/gecko/customtabs/CustomTabsActivity.java
 +++
 b/mobile/android/base/java/org/mozilla/gecko/customtabs/CustomTabsActivity.java
 @@ -618,7 +618,8 @@ public class CustomTabsActivity extends
 AppCompatActivity
  final Intent intent = new Intent(Intent.ACTION_VIEW);
  intent.setData(uri);
  try {
 -startActivity(intent);
 +// Bug 31144 - Don't know how to handle this case.
 +//startActivity(intent);
  } catch (ActivityNotFoundException e) {
  Log.w(LOGTAG, "No activity handler found for: " +
 request.uri);
  }
 }}}

--
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] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
-+-
 Reporter:  ggus |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-circuit-display, |  Actual Points:  0.25
  TorBrowserTeam201910R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * status:  needs_information => needs_review
 * cc: tbb-team (added)
 * keywords:  tbb-circuit-display => tbb-circuit-display,
 TorBrowserTeam201910R
 * actualpoints:   => 0.25


Comment:

 Here's a patch that fixes this issue:

 tor-button:
 
https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_32125&id=56a68b45decbbbf5e6e064f5bd23a21d622e81d0

 With this patch, bridges which have no provided fingerprint will display
 simply as "Bridge" rather than "Bridge: obfs4 127.0.0.1" (for example).
 Without a fingerprint, neither type nor ip are determinable from tor-
 button.

 


 I've dug into this issue a bit and here's a summary of the problem.

 Tor Browser builds the circuit display by requesting the circuit (as a
 list of ids/fingerprints) for the current first-party domain. Then, Tor
 Browser checks to see if each of nodes are a Bridge by requesting the
 bridge strings via {{{getconf bridge}}}. Next, we look for the current id
 in each of the bridge objects and execute some UI logic that displays each
 node's info (whether bridge or vanilla relay).

 When the user provides a bridge without a fingerprint we run into a few
 problems resulting in the broken behavior in the bug. First of all,
 requesting the bridge list via getconf bridge (basically) just returns the
 bridge strings stored in torrc. These strings are either provided by the
 user, brigedb, or our builtin bridge preferences. The bridge string format
 is something like {{{$type $ip:$port $optionalfingerprint
 $otherstuff...}}}.

 As the fingerprint is optional, the bridge parser in tor-control-port.js
 ends up storing the $otherstuff data as the id/fingerprint.

 Then, getBridge() in tor-circuit-display.js fails to find a bridge by
 id/fingerprint (because our bridge has $otherstuff in the id field) and
 returns null.

 Next, nodeDataForId() in tor-circuit-display.js skips over the 'bridge'
 section (as the result of getBridge() is null) and it assumes we are
 dealing with a relay. The failing {{{GETINFO ns/id/$fingerprint}}} call
 ends up throwing exception because we're passing in a bridge
 id/fingerprint which is not part of the consensus (according to arma). As
 a result, the IP of the relay is never set.

 Since the IP of the relay is not stored, updateCircuitDisplay() in tor-
 circuit-display() (which is responsible for creating the visuals including
 the New Circuit button) throws after trying to dereference a null
 reference, resulting in the behavior described in the description.

--
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] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention/Snowflake|Version:
 Severity:  Normal | Resolution:
 Keywords:  anti-censorship-roadmap-september  |  Actual Points:
Parent ID: | Points:  6
 Reviewer:  dcf|Sponsor:
   |  Sponsor28-must
---+---

Comment (by dcf):

 Replying to [comment:27 cohosh]:
 > - We don't currently have unit tests that check the client and server
 integration and we should have them

 I ported my recent
 [https://github.com/net4people/bbs/issues/14#issuecomment-542898991 Turbo
 Tunnel prototype program] to `SnowflakeConn`. You'll have to check it; I
 may have gotten the API wrong. But perhaps it can help test in a
 controlled environment.

 attachment:reconnecting-snowflakeconn.zip

 I managed to get a few panics, trying different things.

 

 {{{
 server$ ./server 127.0.0.1:4000
 2019/10/17 21:14:11 error in handleConn: EOF
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4f8d24]

 goroutine 5 [running]:
 github.com/cohosh/snowflake/common/snowflake-
 proto.(*SnowflakeConn).Write(0xcba000, 0xc307a8, 0xc, 0x20, 0xc,
 0x20, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:337 +0x424
 main.handleConn.func1(0xcba000)
 reconnecting-snowflakeconn/server/main.go:62 +0x87
 created by main.handleConn
 reconnecting-snowflakeconn/server/main.go:58 +0x207
 }}}

 {{{
 client$ ./client 127.0.0.1:4000
 2019/10/17 21:14:08 begin SnowflakeConn c0bd93336fcab1ef
 2019/10/17 21:14:08 begin TCP connection 127.0.0.1:52386 -> 127.0.0.1:4000
 abcd
 ABCD
 ^C
 client$ ./client 127.0.0.1:4000
 2019/10/17 21:14:15 begin SnowflakeConn e446789c28f69bbc
 2019/10/17 21:14:15 begin TCP connection 127.0.0.1:52388 -> 127.0.0.1:4000
 xyz
 XYZ
 2019/10/17 21:14:19 stdout <- conn finished: EOF
 }}}

 This looks like it's the `err`/`err2` confusion from comment:28.

 

 {{{
 lilbastard$ lilbastard -w 10 127.0.0.1:3000 127.0.0.1:4000
 }}}

 {{{
 $ ./server 127.0.0.1:4000
 2019/10/17 21:18:41 error in handleConn: EOF
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4f8d24]

 goroutine 5 [running]:
 github.com/cohosh/snowflake/common/snowflake-
 proto.(*SnowflakeConn).Write(0xcbe000, 0xc2ffa8, 0xc, 0x20, 0xc,
 0x20, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:337 +0x424
 main.handleConn.func1(0xcbe000)
 reconnecting-snowflakeconn/server/main.go:62 +0x87
 created by main.handleConn
 reconnecting-snowflakeconn/server/main.go:58 +0x207
 }}}

 {{{
 $ ./client 127.0.0.1:3000
 2019/10/17 21:18:31 begin SnowflakeConn f2a5d31f6afa8727
 2019/10/17 21:18:31 begin TCP connection 127.0.0.1:39108 -> 127.0.0.1:3000
 abcd
 ABCD
 efgh
 EFGH
 ijkl2019/10/17 21:18:41 stdout <- conn finished: EOF

 2019/10/17 21:18:51 Closing WebRTC connection, timed out waiting for ACK
 }}}

 This looks similar, except the server and client report an EOF first.

 

 {{{
 server$ ./server 127.0.0.1:4000
 }}}

 {{{
 client$ yes | ./client 127.0.0.1:4000
 2019/10/17 21:16:01 begin SnowflakeConn eb27f73167a77490
 2019/10/17 21:16:01 begin TCP connection 127.0.0.1:52392 -> 127.0.0.1:4000
 2019/10/17 21:16:11 Closing WebRTC connection, timed out waiting for ACK
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x4f52c4]

 goroutine 6 [running]:
 github.com/cohosh/snowflake/common/snowflake-
 proto.(*SnowflakeConn).Write(0xca4000, 0xcb8000, 0x8000, 0x8000,
 0x8000, 0x0, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:337 +0x424
 github.com/cohosh/snowflake/common/snowflake-proto.Proxy(0x55edc0,
 0xca4000, 0x55ef80, 0xc0e010, 0x0, 0x0, 0x0)
 
$GOPATH/pkg/mod/github.com/cohosh/snowflake@v0.0.0-20191002223810-1707fcc12518/common
 /snowflake-proto/proto.go:406 +0xf0
 main.run.func1(0xc12380, 0xca4000)
 reconnecting-snowflakeconn/client/main.go:37 +0x7d
 created by main.run
 reconnecting-snowflakeconn/client/main.go:35 +0x3e8
 }}}

 This panic is in the client rather than t

Re: [tor-bugs] #32134 [Circumvention/BridgeDB]: Request new translation and update i18n instructions

[Tor Bug Tracker & Wiki]

#32134: Request new translation and update i18n instructions
+---
 Reporter:  phw |  Owner:  phw
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  s30-o22a3   |  Actual Points:
Parent ID:  #31279  | Points:  0.2
 Reviewer:  cohosh  |Sponsor:  Sponsor30-can
+---
Changes (by phw):

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


Comment:

 I have a patch in my
 [https://github.com/NullHypothesis/bridgedb/compare/task/32134?expand=1
 task/32134 branch].

--
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] #32133 [Internal Services/Service - git]: gitweb.tpo performance problems

[Tor Bug Tracker & Wiki]

#32133: gitweb.tpo performance problems
-+--
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  assigned
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by anarcat):

 new trick did not work, reverting to maxclients

--
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] #30842 [Applications/Tor Browser]: Unable to start Tor: java.io.IOException: Control port file not created on Android 4.1.2

[Tor Bug Tracker & Wiki]

#30842: Unable to start Tor: java.io.IOException: Control port file not created 
on
Android 4.1.2
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201910R  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by sisbell):

 For reference, since the android arm emulators are so slow, trying to view
 the android apps screen may cause a lockup, so best to start the tor
 browser from command line.

 {{{
 adb shell am start -n
 org.torproject.torbrowser/org.mozilla.gecko.LauncherActivity
 }}}

--
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] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

[Tor Bug Tracker & Wiki]

#29206: New design for client -- server protocol for Snowflake
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention/Snowflake|Version:
 Severity:  Normal | Resolution:
 Keywords:  anti-censorship-roadmap-september  |  Actual Points:
Parent ID: | Points:  6
 Reviewer:  dcf|Sponsor:
   |  Sponsor28-must
---+---
Changes (by dcf):

 * Attachment "reconnecting-snowflakeconn.zip" 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] #30842 [Applications/Tor Browser]: Unable to start Tor: java.io.IOException: Control port file not created on Android 4.1.2

[Tor Bug Tracker & Wiki]

#30842: Unable to start Tor: java.io.IOException: Control port file not created 
on
Android 4.1.2
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201910R  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam201910R


--
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] #30842 [Applications/Tor Browser]: Unable to start Tor: java.io.IOException: Control port file not created on Android 4.1.2

[Tor Bug Tracker & Wiki]

#30842: Unable to start Tor: java.io.IOException: Control port file not created 
on
Android 4.1.2
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---

Comment (by sisbell):

 On Android Armv7a Jelly Bean Emulator Instance I get a crash (so not even
 as far as the person who reported the tor startup issue). This is off of
 esr68 branch of the bug. This could just be an emulator issue since the
 older arm emulators are not well maintained.

 So do we have any reports in the wild of crashes on Jelly Bean? I don't
 have access to google play crash logs but there could be something in
 there.


 {{{
 D/dalvikvm( 4359): Trying to load lib
 /data/data/org.torproject.torbrowser/lib/libmozglue.so 0xa7450800
 F/libc( 4359): Fatal signal 4 (SIGILL) at 0x9a5c0bac (code=1), thread
 4359 (ject.torbrowser)
 I/DEBUG   (  649): *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 *** ***
 I/DEBUG   (  649): Build fingerprint:
 'generic/google_sdk/generic:4.1.2/MASTER/4875369:eng/test-keys'
 I/DEBUG   (  649): pid: 4359, tid: 4359, name: ject.torbrowser  >>>
 org.torproject.torbrowser <<<
 I/DEBUG   (  649): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr
 9a5c0bac
 I/DEBUG   (  649): r0   r1 c22d40d0  r2   r3 
 I/DEBUG   (  649): r4 9a642154  r5 0004  r6 0004  r7 b7c189e0
 I/DEBUG   (  649): r8   r9 b68361a8  sl a05ceb1c  fp 0001
 I/DEBUG   (  649): ip 9a641e5c  sp be9b57c8  lr 9a5be891  pc 9a5c0bac
 cpsr 6170
 I/DEBUG   (  649): d0  00013fc0  d1  3f50624d3fc0
 I/DEBUG   (  649): d2  bfd3441350baf6de  d3  3f00
 I/DEBUG   (  649): d4    d5  3f405bb804a5
 I/DEBUG   (  649): d6  7e37e43c8800759c  d7  0048
 I/DEBUG   (  649): d8    d9  
 I/DEBUG   (  649): d10   d11 
 I/DEBUG   (  649): d12   d13 
 I/DEBUG   (  649): d14   d15 
 I/DEBUG   (  649): scr 2010
 I/DEBUG   (  649):
 I/DEBUG   (  649): backtrace:
 I/DEBUG   (  649): #00  pc 00010bac
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649): #01  pc e88d
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):
 I/DEBUG   (  649): stack:
 I/DEBUG   (  649):  be9b5788  9a5c1709
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):  be9b578c  
 I/DEBUG   (  649):  be9b5790  4004
 I/DEBUG   (  649):  be9b5794  
 I/DEBUG   (  649):  be9b5798  b6f0ec6d  /system/bin/linker
 I/DEBUG   (  649):  be9b579c  
 I/DEBUG   (  649):  be9b57a0  1004
 I/DEBUG   (  649):  be9b57a4  
 I/DEBUG   (  649):  be9b57a8  c22d40d0
 I/DEBUG   (  649):  be9b57ac  9a642154
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):  be9b57b0  0004
 I/DEBUG   (  649):  be9b57b4  0004
 I/DEBUG   (  649):  be9b57b8  b7c189e0  [heap]
 I/DEBUG   (  649):  be9b57bc  
 I/DEBUG   (  649):  be9b57c0  df0027ad
 I/DEBUG   (  649):  be9b57c4  
 I/DEBUG   (  649): #00  be9b57c8  9a642154
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):    
 I/DEBUG   (  649): #01  be9b57c8  9a642154
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):  be9b57cc  9a5b155f
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):  be9b57d0  9a63f600
 /data/data/org.torproject.torbrowser/lib/libmozglue.so
 I/DEBUG   (  649):  be9b57d4  b6f0c755  /system/bin/linker
 I/DEBUG   (  649):  be9b57d8  b6f2280c
 I/DEBUG   (  649):  be9b57dc  0001
 I/DEBUG   (  649):  be9b57e0  a7450800  /dev/ashmem/dalvik-heap
 (deleted)
 I/DEBUG   (  649):  be9b57e4  b6f0ec4f  /system/bin/linker
 I/DEBUG   (  649):  be9b57e8  b7c3f648  [heap]
 I/DEBUG   (  649):  be9b57ec  b67db343  /system/lib/libdvm.so
 (dvmLoadNativeCode(char const*, Object*, char**)+190)
 I/DEBUG   (  649):  be9b57f0  
 I/DEBUG   (  649):  be9b57f4  a7523ae0  /dev/ashmem/dalvik-heap
 (deleted)
 I/DEBUG   (  649):  be9b57f8  006e
 I/DEBUG   (  

Re: [tor-bugs] #31730 [Applications/Tor Browser]: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9

[Tor Bug Tracker & Wiki]

#31730: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-parity,  |  Actual Points:  0.5
  TorBrowserTeam201910R tbb-9.0-must |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 This looks good to me, too. Applied to `master` (commit
 9d744c6adc5ee3608e519c5db49528cd6ee6fe54).

--
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] #32133 [Internal Services/Service - git]: gitweb.tpo performance problems

[Tor Bug Tracker & Wiki]

#32133: gitweb.tpo performance problems
-+--
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  assigned
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by anarcat):

 i tried another, simpler tack, and set RLimitNPROC to 75 150, which should
 limits the number of CGI processes fired. so i reset the MaxRequestWorkers
 back to 1500, we'll see how this goes.

 thanks to sangy on irc for the suggestion!

--
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] #32134 [Circumvention/BridgeDB]: Request new translation and update i18n instructions

[Tor Bug Tracker & Wiki]

#32134: Request new translation and update i18n instructions
+---
 Reporter:  phw |  Owner:  phw
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  |   Keywords:  s30-o22a3
Actual Points:  |  Parent ID:  #31279
   Points:  0.2 |   Reviewer:
  Sponsor:  Sponsor30-can   |
+---
 While implementing our language switcher (#26543), we added a new string,
 "Language", that requires translations. We should also update our
 instructions on how to request new translations.

--
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] #29336 [Internal Services/Tor Sysadmin Team]: split git from gitweb.tpo

[Tor Bug Tracker & Wiki]

#29336: split git from gitweb.tpo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 git (ro) is push-synced from git-rw.

 There's no reason why git-rw couldn't push to both if we wanted.

--
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] #31730 [Applications/Tor Browser]: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9

[Tor Bug Tracker & Wiki]

#31730: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-parity,  |  Actual Points:  0.5
  TorBrowserTeam201910R tbb-9.0-must |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  needs_review => merge_ready


Comment:

 Okay, I think this'll work. Let's use it.

--
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] #29336 [Internal Services/Tor Sysadmin Team]: split git from gitweb.tpo

[Tor Bug Tracker & Wiki]

#29336: split git from gitweb.tpo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i opened #32133 about the gitweb performance problems on vineale. even if
 we split git.tpo out of gitweb, we would still need to fix the performance
 problem so i figured it was worth treating it separately.

 now, that said, how would we go around splitting those two? we'd still
 need a shared filesystem of some sort, no? NFS? read-only DRBD?

--
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] #32133 [Internal Services/Service - git]: gitweb.tpo performance problems

[Tor Bug Tracker & Wiki]

#32133: gitweb.tpo performance problems
-+--
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  assigned
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by anarcat):

 today we have seen the limits of the cache configuration as a crawler
 trashed through the cache by hitting the random cgit pages it was coming
 from tor so it was not useful to block it by IP either.

 instead I pushed down the MaxRequestWorkers setting from 1500 to 75. that
 seems to have calmed things down. the upstream default is 150, but that's
 still too much for cgit, as 155 cgit processes blows through 8GB of memory
 quite easily.

 in my notes, I had:

 > other possible fix: fcgiwrap or rate-limiting, wait for cache to fill up
 first

 i'm thinking fcgiwrap would be an interesting approach as it would limit
 the number of cgit processes separately from apache.

 right now puppet is on hold on the server to respect the MaxRequestWorkers
 change. it's a puppet-wide setting so i'm hesitant in changing it there.

--
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] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

[Tor Bug Tracker & Wiki]

#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910R, tbb-9.0   |  Actual Points:
  -must-alpha, tbb-proxy-bypass  |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 I pushed `bug31144_04` which contains fixups for the missed:

 >> GeckAppShell has many wrappers to create inputstreams from
 URLConnections (but these may need to be opened first?)
 > This seems like it's only local connections (but it has the potential of
 bypassing the proxy). Specifically, this is used as a protocol handler for
 android: URIs. We can reject connections for now, and come back to this.

 and

 >> GeckoActionProvider.downloadImageForIntent uses
 java.net.URL.openStream()
 > Same here.

 and


  CustomTabsActivity.performPendingIntent - again, hard to tell what is
 happening here
 >>> These seem like they could be arbitrary actions.
 >> Hrmm.. should we patch that somehow, or assume it is handled when the
 Intent is finally delivered?
 > I'd rather break this functionality at this point. Someone can change
 the default browser on their device to Tor Browser under the assumption
 that CustomTabs are proxy-safe and other apps will happily use it. I'd
 rather be safe than sorry here. We can come back later and fix it
 correctly.

 and



 >> android.app.DownloadManager
 >>  DownloadsIntegration.java uses it, but has a check for
 useSystemDownloadManager() to avoid using it
 >>  BrowserApp.java uses it to download items without any checks
 > This is controlled by
 browser.download.forward_oma_android_download_manager which is false.
 (​https://bugzilla.mozilla.org/show_bug.cgi?id=1253684 which is
 restricted?). I'll add this into the override file, just so we aren't
 surprised by a change 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

[tor-bugs] #32133 [Internal Services/Service - git]: gitweb.tpo performance problems

[Tor Bug Tracker & Wiki]

#32133: gitweb.tpo performance problems
-+--
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  assigned
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 as mentioned in #29336, gitweb often falls over and dies because it runs
 out of memory under the load of cgit.cgi processes. it easily goes through
 its 8GB of memory and explodes.

 i first addressed this problem in early march by enabling the cgit cache,
 but the problem still occurs when a crawler (or attacker?) trashes through
 he cache.

--
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] #30324 [Applications/Tor Browser]: Adapt Android toolchain for Firefox 68 ESR

[Tor Bug Tracker & Wiki]

#30324: Adapt Android toolchain for Firefox 68 ESR
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910|
Parent ID:  #30320   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

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


Comment:

 We are done here, finally.

--
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] #30320 [Applications/Tor Browser]: Adapt Tor Browser toolchains for Firefox 68 ESR

[Tor Bug Tracker & Wiki]

#30320: Adapt Tor Browser toolchains for Firefox 68 ESR
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr,   |  Actual Points:
  GeorgKoppen201908, tbb-9.0-must-alpha, |
  TorBrowserTeam201910   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

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


Comment:

 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] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)

[Tor Bug Tracker & Wiki]

#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910R   |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

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


Comment:

 Looks good, thanks. Cherry-picked to `master` (commit
 11672b3b3a615e7493add5d3b3dae0a7ed960551).

--
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] #32132 [Applications/Tor Browser]: Re-enable jemalloc for Windows users (was: Re-enabled jemalloc for Windows users)

[Tor Bug Tracker & Wiki]

#32132: Re-enable jemalloc for Windows users
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910,|  Actual Points:
  GeorgKoppen201910, tbb-rbm |
Parent ID:   | Points:  0.1
 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

[tor-bugs] #32132 [Applications/Tor Browser]: Re-enabled jemalloc for Windows users

[Tor Bug Tracker & Wiki]

#32132: Re-enabled jemalloc for Windows users
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201910,
 Severity:  Normal   |  GeorgKoppen201910, tbb-rbm
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+-
 Now that https://bugzilla.mozilla.org/show_bug.cgi?id=1547519 got
 backported to esr68.2.0 we can think about re-enabling jemalloc again
 (finally!) for Windows users.

--
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] #28709 [Applications/Tor Browser]: Enable Fuzzyfox

[Tor Bug Tracker & Wiki]

#28709: Enable Fuzzyfox
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911  |  Actual Points:
Parent ID:  #28707| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 That seems to be a pref flip away (`privacy.fuzzyfox.enabled`). We should
 pick that for 9.5a1.

--
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] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)

[Tor Bug Tracker & Wiki]

#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910R   |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by sisbell):

 * keywords:  tbb-rbm, ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201910 =>
 tbb-rbm, ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201910R


--
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] #22665 [Applications/GetTor]: Use internet archive's wayback machine.

[Tor Bug Tracker & Wiki]

#22665: Use internet archive's wayback machine.
-+-
 Reporter:  ilv  |  Owner:  hiro
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:  #28231   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

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


Comment:

 This is already 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] #30477 [Core Tor/Tor]: Tor should self-test reachability of TCP listeners exposed by PT's

[Tor Bug Tracker & Wiki]

#30477: Tor should self-test reachability of TCP listeners exposed by PT's
-+-
 Reporter:  ahf  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, network-team-roadmap-|  Actual Points:
  november, s30-o23a3|
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by phw):

 Replying to [comment:12 teor]:
 > Replying to [comment:10 nickm]:
 > > > If a transport exposes a TCP port, connect to that TCP port via a
 Tor Exit.
 > >
 > > Question: what if the attacker runs an exit in order find out where PT
 ports are?
 >
 > Bridges already do reachability checks via a random relay's ORPort: so
 we have accepted a similar risk in the past.
 [[br]]
 It may be a good time to re-consider this risk now. Over at #31874, we're
 brainstorming a service that takes as input a bridge line and then tests
 the given bridge. We may want such a service instead of, or in addition to
 Tor self-testing its PT bridge. The downside of this service (which we
 could couple with BridgeDB) doing the testing is that it takes a while
 until the bridge operator learns if their bridge works.

--
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: #17212, #18750, #19951, #19952, ...

[Tor Bug Tracker & Wiki]

Batch modification to #17212, #18750, #19951, #19952, #20659, #21382, #22011, 
#23072, #23225, #23226, #25887, #26175, #27148, #27972, #28092 by gaba:


Action: new

--
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: #17212, #18750, #19951, #19952, ...

[Tor Bug Tracker & Wiki]

Batch modification to #17212, #18750, #19951, #19952, #20659, #21382, #22011, 
#23072, #23225, #23226, #25887, #26175, #27148, #27972, #28092 by gaba:


Action: reassign

Comment:
Removing ilv as onwer of many of the tickets. He can take back the ticket he 
will work on if he comes back into gettor. 

--
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] #31874 [Circumvention]: Automatically test the PTs of bridges

[Tor Bug Tracker & Wiki]

#31874: Automatically test the PTs of bridges
---+
 Reporter:  phw|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  s30-o23a3  |  Actual Points:
Parent ID:  #31280 | Points:  10
 Reviewer: |Sponsor:  Sponsor30-must
---+

Comment (by phw):

 Some additional feedback from dcf and cohosh after
 [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-10-17-16.59.html today's anti-censorship meeting]:
 * There's potential for abuse. Exposing this service to the public means
 allowing anybody to use our machine to establish TLS connections (for
 vanilla Tor) and send garbage data (for obfs4) to arbitrary machines on
 the Internet. To prevent this, the service could first verify if the
 provided bridge is in BridgeDB, and only then proceed to test it.

 * If BridgeDB uses this service to test a bridge, and somehow propagates
 this information to CollecTor (so it can be listed on the bridge's status
 page), there may not be a need to expose it to the public.

 * BridgeDB should not hand out bridges that this service deems non-
 functional.

--
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] #32131 [Circumvention/Snowflake]: `SetDeadline not implemented` errors in proxy-go output

[Tor Bug Tracker & Wiki]

#32131: `SetDeadline not implemented` errors in proxy-go output
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 At da8b98d09089e32d53573a1cabcb450aa290b4c8, running proxy-go and getting
 assigned a client (as in comment:13:ticket:29258) causes a lot of output
 of this nature:
 {{{
 2019/10/17 19:47:02 connected to relay
 2019/10/17 19:47:02 calling SetDeadline in Read returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:02 calling SetDeadline in Read returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:02 calling SetDeadline in Write returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:02 Write 751 bytes --> WebRTC
 2019/10/17 19:47:02 OnMessage <--- 126 bytes
 2019/10/17 19:47:02 calling SetDeadline in Read returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:02 calling SetDeadline in Write returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:02 Write 51 bytes --> WebRTC
 2019/10/17 19:47:02 OnMessage <--- 40 bytes
 2019/10/17 19:47:02 calling SetDeadline in Read returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:03 calling SetDeadline in Write returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:03 Write 1508 bytes --> WebRTC
 2019/10/17 19:47:03 OnMessage <--- 1057 bytes
 2019/10/17 19:47:03 calling SetDeadline in Read returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:03 calling SetDeadline in Write returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:03 Write 543 bytes --> WebRTC
 2019/10/17 19:47:03 OnMessage <--- 1057 bytes
 2019/10/17 19:47:03 calling SetDeadline in Read returned the following
 error: SetDeadline not implemented
 2019/10/17 19:47:03 calling SetDeadline in Write returned the following
 error: SetDeadline not implemented
 }}}

 I suppose the immediate cause is the changes from #31794.

--
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] #22919 [Applications/Tor Browser]: Form tracking and OS fingerprinting (only Windows, but without Javascript)

[Tor Bug Tracker & Wiki]

#22919: Form tracking and OS fingerprinting (only Windows, but without 
Javascript)
-+-
 Reporter:  basvd|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201910   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Replying to [comment:6 tom]:
 > I don't believe GenerateRandomSeed is available outside of the js
 engine.  But you're right about the bits
 Right, and it uses `PRMJ_Now()` which is also only in `js`.

 We could maybe have a local version of `js::GenerateRandomSeed()`?
 Changing `PRMJ_Now()` -> `PR_Now()` and maybe using the same `srand/rand`
 fallback as in the patch? I think the resulting code is simpler than the
 one using `@mozilla.org/security/random-generator;1` (assuming both have
 similar security, speed and availability).

--
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] #30920 [Core Tor/Tor]: Detect uint64 overflow in config_parse_units()

[Tor Bug Tracker & Wiki]

#30920: Detect uint64 overflow in config_parse_units()
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Low|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  easy overflow  |  Actual Points:  0.2
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+

Comment (by nickm):

 (See the comments on the PR for more information)

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

Re: [tor-bugs] #30920 [Core Tor/Tor]: Detect uint64 overflow in config_parse_units()

[Tor Bug Tracker & Wiki]

#30920: Detect uint64 overflow in config_parse_units()
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Low|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  easy overflow  |  Actual Points:  0.2
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+

Comment (by nickm):

 Err, sorry -- I mentioned the sign check and the documentation on the pull
 request, but I forgot to say so 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] #29258 [Circumvention/Snowflake]: Provide an IPv6 address for the Snowflake broker

[Tor Bug Tracker & Wiki]

#29258: Provide an IPv6 address for the Snowflake broker
+--
 Reporter:  ahf |  Owner:  dcf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by dcf):

 Replying to [comment:12 dcf]:
 > Today we decided to start by pointing the snowflake-
 broker.torproject.net DNS, which is currently unused, at the new broker,
 so we can test it ourselves.
 >
 > #32128 is for that.

 snowflake-broker.torproject.net is now set up for us. Using the following
 proxy-go command and torrc I was able (using an IPv6 connection to the
 broker) to connect to myself and bootstrap to 100%.

 {{{
 ./proxy-go -broker https://snowflake-broker.torproject.net
 }}}

 {{{
 UseBridges 1
 DataDirectory datadir

 ClientTransportPlugin snowflake exec ./client \
 -url https://snowflake-broker.torproject.net/ \
 -ice stun:stun.l.google.com:19302 \
 -log snowflake.log \
 -max 3

 Bridge snowflake 0.0.3.0:1
 }}}

 I did have to first upgrade the version of
 golang.org/x/crypto/acme/autocert compiled into the broker, for a protocol
 change:
 {{{
 go get -u golang.org/x/crypto/acme/autocert
 }}}
 Before doing this, I was getting these errors in the broker logs, linking
 to https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
 {{{
 2019/10/17 19:37:32 http: TLS handshake error from [scrubbed]: 403
 urn:acme:error:unauthorized: Account creation on ACMEv1 is disabled.
 Please upgrade your ACME client to a version that supports ACMEv2 / RFC
 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-
 acmev1/88430 for details.
 2019/10/17 19:37:37 http: TLS handshake error from [scrubbed]:
 acme/autocert: missing certificate
 2019/10/17 19:37:41 http: TLS handshake error from [scrubbed]:
 acme/autocert: missing certificate
 }}}

--
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] #31999 [Core Tor/Tor]: Default log file is handled inconsistently

[Tor Bug Tracker & Wiki]

#31999: Default log file is handled inconsistently
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #31241| Points:
 Reviewer:  teor  |Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * status:  new => needs_review
 * reviewer:   => teor


Comment:

 This branch isn't done yet, but I'd like your feedback on the general
 approach and on testing.

--
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] #32130 [- Select a component]: Links don't open on android

[Tor Bug Tracker & Wiki]

#32130: Links don't open on android
--+--
 Reporter:  doctorer  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Thanks for the efforts to create this browser

 Bug I am facing is - when browser isn't open on android and I click on a
 link in some app Tor opens and I click connect but the link doesn't open,
 I have to open my app and click the link again to open it.

--
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] #30382 [Core Tor/Tor]: prop304: Implement SOCKS new HS error code

[Tor Bug Tracker & Wiki]

#30382: prop304: Implement SOCKS new HS error code
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, hs-auth,  |  Actual Points:
  network-team-roadmap-september, tor-spec,  |
  042-deferred-20190918  |
Parent ID:  #14389   | Points:  6
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by dgoulet):

 New branch is here: `ticket30382_043_01`.

 So far is implements there extended error codes:

 {{{
 X'F0' Onion Service Descriptor Can Not be Found
 X'F1' Onion Service Descriptor Is Invalid
 X'F4' Onion Service Missing Client Authorization
 X'F5' Onion Service Wrong Client Authorization
 }}}

 The two missing ones are the intro failure and RP failure which are _very_
 _very_ tricky to be honest.

 For now, the SOCKS reply is not send back before the rendezvous has opened
 the stream so basically like if there is no optimistic data.

--
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] #30461 [Applications/Tor Browser]: Update tor-android-service Project to Use Android Toolchain (Firefox 68)

[Tor Bug Tracker & Wiki]

#30461: Update tor-android-service Project to Use Android Toolchain (Firefox 68)
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910|
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 Removes two patches we no longer need.

 https://github.com/sisbell/tor-browser-
 build/commit/6480a29f094ebd87833fff6bae56c375b287c08d

--
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] #30920 [Core Tor/Tor]: Detect uint64 overflow in config_parse_units()

[Tor Bug Tracker & Wiki]

#30920: Detect uint64 overflow in config_parse_units()
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Low|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  easy overflow  |  Actual Points:  0.2
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+

Comment (by guigom):

 Replying to [comment:24 nickm]:
 > Looks good to me too.  It just needs some documentation updates and (I
 think) a sign check.

 Which documentation specifically? torrc options in the man page?

 About the sign check (if I understand correctly, checking if possitive),
 is this because {{{tor_parse_double}}} does not indeed use the {{{min}}}
 parameter?
 Wouldn't the bit sign for negative numbers end up giving a uint
 representation greater than INT64_MAX thus failing the uint check?



 {{{
 double
 tor_parse_double(const char *s, double min, double max, int *ok, char
 **next)
 {
   char *endptr;
   double r;

   errno = 0;
   r = strtod(s, &endptr);
   CHECK_STRTOX_RESULT();
 }
 }}}

--
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] #31810 [Core Tor]: Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting.

[Tor Bug Tracker & Wiki]

#31810: Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion
line should be unreached failed; aborting.
--+
 Reporter:  Parckwart |  Owner:  ahf
 Type:  defect| Status:  needs_revision
 Priority:  Very High |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-must, 041-regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by dcf):

 #32033 was closed as a duplicate.

--
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] #32033 [Core Tor/Tor]: process_unix_exec assertion failure when ServerTransportPlugin refers to nonexistent file

[Tor Bug Tracker & Wiki]

#32033: process_unix_exec assertion failure when ServerTransportPlugin refers to
nonexistent file
+
 Reporter:  dcf |  Owner:  ahf
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.4.2.2-alpha
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  tor-pt 042-should?  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dcf):

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


Comment:

 Replying to [comment:4 ahf]:
 > This is a duplicate of #31810 I believe.

 Yes, I think you're right.

--
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] #32128 [Internal Services/Tor Sysadmin Team]: Point DNS for snowflake-broker.torproject.net at the new broker set up in #29258

[Tor Bug Tracker & Wiki]

#32128: Point DNS for snowflake-broker.torproject.net at the new broker set up 
in
#29258
-+-
 Reporter:  dcf  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 done in dns/domains repo in commit 57dc8c0

--
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] #32128 [Internal Services/Tor Sysadmin Team]: Point DNS for snowflake-broker.torproject.net at the new broker set up in #29258

[Tor Bug Tracker & Wiki]

#32128: Point DNS for snowflake-broker.torproject.net at the new broker set up 
in
#29258
-+-
 Reporter:  dcf  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tpa => anarcat
 * status:  new => assigned


Comment:

 checked sig, checks 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] #32129 [Circumvention/Snowflake]: Increase Snowflake proxy poll interval to 300 s

[Tor Bug Tracker & Wiki]

#32129: Increase Snowflake proxy poll interval to 300 s
-+--
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Looks good, but we could take this opportunity to increase user experience
 a bit more and only change the poll interval for web-based proxies. There
 are only about 10 standalone proxies, so having these poll more often
 shouldn't overload the broker.

 This might help alleviate things until #29206 is merged.

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

Re: [tor-bugs] #31250 [Circumvention/Snowflake]: Purchase new snowflake domain to fix "safe browsing" issue

[Tor Bug Tracker & Wiki]

#31250: Purchase new snowflake domain to fix "safe browsing" issue
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 I'll close this now because we have the *.freehaven.net and
 *.torproject.net domain names, and the issue is moot anyway because
 bamsoftware.com is no longer on the safe browsing blacklist.

--
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] #31810 [Core Tor]: Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion line should be unreached failed; aborting.

[Tor Bug Tracker & Wiki]

#31810: Bug: ../src/lib/process/process_unix.c:265: process_unix_exec: Assertion
line should be unreached failed; aborting.
--+
 Reporter:  Parckwart |  Owner:  ahf
 Type:  defect| Status:  needs_revision
 Priority:  Very High |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-must, 041-regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by ahf):

 1) I have added a test case to test for how we handle process termination
 in general. During this I discovered that we had an API difference where
 on Windows the exit callback of a given process_t would NOT be called when
 CreateProcessA() failed (with for example the  no such file or directory
 error).

 2) I have based the patches on maint-0.4.0 now, but also created a PR for
 0.4.2 and master with an added practracker exception.

 0.4.0, 0.4.1 PR: https://github.com/torproject/tor/pull/1424
 0.4.2, master PR: https://github.com/torproject/tor/pull/1426

 Let's see what CI says to both 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] #31497 [Circumvention/Snowflake]: Link Cupcake from snowflake.torproject.org

[Tor Bug Tracker & Wiki]

#31497: Link Cupcake from snowflake.torproject.org
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Here is a draft patch:
 https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=link-
 cupcake&id=1e4d7f49180f199fbb794275423f4837f5354c07

 It looks like this:
 [[Image(screenshot.png,40%)]]

--
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] #31497 [Circumvention/Snowflake]: Link Cupcake from snowflake.torproject.org

[Tor Bug Tracker & Wiki]

#31497: Link Cupcake from snowflake.torproject.org
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "screenshot.png" added.

 Screenshot of
 https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=link-
 cupcake&id=1e4d7f49180f199fbb794275423f4837f5354c07

--
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] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 Ok, here is I think the issue:

 In all the bridge lines that work, there is an identity key fingerprint in
 the bridge line (the 40 hexes after the IP:port).

 In the one that doesn't work, that fingerprint is missing.

 I believe the fingerprint is technically optional, but I believe bridgedb
 gives it out always, so probably the tor browser folks figured it would
 always be there.

--
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] #32129 [Circumvention/Snowflake]: Increase Snowflake proxy poll interval to 300 s

[Tor Bug Tracker & Wiki]

#32129: Increase Snowflake proxy poll interval to 300 s
-+--
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * 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] #32129 [Circumvention/Snowflake]: Increase Snowflake proxy poll interval to 300 s

[Tor Bug Tracker & Wiki]

#32129: Increase Snowflake proxy poll interval to 300 s
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

 * Attachment "0001-Increase-proxy-poll-interval-to-300-s.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

[tor-bugs] #32129 [Circumvention/Snowflake]: Increase Snowflake proxy poll interval to 300 s

[Tor Bug Tracker & Wiki]

#32129: Increase Snowflake proxy poll interval to 300 s
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 The Snowflake proxies are polling the broker more frequently than
 necessary for the number of clients we have. The broker reports about 500
 proxies currently, which at the current poll interval of 20 s, is 25
 polls/s.

 At the [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-10-17-16.59.log.html anti-censorship meeting today] we talked
 about increasing the interval to 300 s, which would still give us an
 expected time-to-proxy-assignment of less than 1 s.

 {{{
 17:41:02  A few weeks ago I tailed the log of the broker, and
 requests were coming in furiously.
 17:41:23  Lately those particular log lines have been removed, so
 it's not as apparent, but according to https://snowflake-
 broker.bamsoftware.com/debug there's 500 proxies,
 17:41:39  and with a poll interval of 20 s, that's 25 incoming proxy
 requests per second.
 17:41:42  i liked the idea of having the broker tell each snowflake
 when to come back
 17:41:59  Something on the order of 1 or 2 per second is probably
 adequate.
 17:42:07  arma2: serna has started on that ticket
 17:42:14  i agree
 17:42:23  arma2: yeah that's #25598, serna ran into some trouble
 with that.
 17:42:42  we have metrics of how many idle proxies we have:
 https://metrics.torproject.org/collector/archive/snowflakes/
 17:42:57  and it is orders of magnitude more than the the number
 of client matches
 17:43:31  Anyway, I think an interval of around 300 seconds would be
 workable.
 17:43:37  sounds 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] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 I chose the default (built in) obfs4 bridges, and it shows me a circuit
 display.

 Then I went to bridges.tpo and got an obfs4 bridge from there, and that
 one shows a circuit display too.

 Huh.

--
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] #28531 [Community/Outreach]: Publish a snapshot of what PTs are needed for successful Tor use in each country

[Tor Bug Tracker & Wiki]

#28531: Publish a snapshot of what PTs are needed for successful Tor use in each
country
-+-
 Reporter:  arma |  Owner:  phw
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Community/Outreach   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship, anti-censorship- |  Actual Points:
  roadmap-october, s30-o22a2, s30-o23a2, ux- |
  team   |
Parent ID:  #31279   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by antonela):

 * keywords:  censorship, anti-censorship-roadmap-october, s30-o22a2,
 s30-o23a2 =>
 censorship, anti-censorship-roadmap-october, s30-o22a2, s30-o23a2, ux-
 team


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

Re: [tor-bugs] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 I see a similar picture using tor browser stable.

 Though yes, I only see the above picture if I move to another tab and come
 back.

 If I simply load a page in a tab, then the circuit display is entirely
 absent: that whole middle third is just not there.

--
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] #29258 [Circumvention/Snowflake]: Provide an IPv6 address for the Snowflake broker

[Tor Bug Tracker & Wiki]

#29258: Provide an IPv6 address for the Snowflake broker
+--
 Reporter:  ahf |  Owner:  dcf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by dcf):

 Replying to [comment:11 dcf]:
 > Now the question is what to do about handling the migration. We can talk
 about this at the next meeting on Thursday.

 Today we decided to start by pointing the snowflake-broker.torproject.net
 DNS, which is currently unused, at the new broker, so we can test it
 ourselves.

 #32128 is for that.

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

Re: [tor-bugs] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by phw):

 Here's what it looks like for me, running Tor Browser 9.0a8:
 [[Image(tor-browser-alpha.png)]]

 At some point I didn't see any circuit information at all, and then I saw
 the one above, where it only says "This browser." Note that the page I was
 browsing to reproduce this bug loaded fully, and it happens on other pages
 as well.

--
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] #32128 [Internal Services/Tor Sysadmin Team]: Point DNS for snowflake-broker.torproject.net at the new broker set up in #29258

[Tor Bug Tracker & Wiki]

#32128: Point DNS for snowflake-broker.torproject.net at the new broker set up 
in
#29258
-+-
 Reporter:  dcf  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin   |Version:
  Team   |
 Severity:  Normal   |   Keywords:  snowflake
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Please point the DNS name snowflake-broker.torproject.net at the two IP
 addresses:
 {{{
 37.218.245.111
 2a00:c6c0:0:154:4:d8aa:b4e6:c89f
 }}}
 There is a PGP-signed statement of those addresses at
 https://lists.torproject.org/pipermail/anti-censorship-
 team/2019-October/40.html.

 In comment:11:ticket:29258, we set up a new Snowflake broker that has an
 IPv6 address. At [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-10-17-16.59.log.html today's anti-censorship meeting] we
 decided to test it by first pointing the (currently unused) snowflake-
 broker.torproject.net DNS at it.
 {{{
 17:07:37  I've set up a new broker and documented the installation
 instructions.
 17:07:54 
 https://trac.torproject.org/projects/tor/ticket/29258#comment:11
 17:08:20  Figners crossed, I think all that's needed to start using
 it is to update some DNS records.
 17:08:36  But perhpas we should do a smaller-scale test first.
 17:09:41  One option is we give the new broker a hostname different
 than the snowflake-broker ones already in use; that way we can test it
 ourselves.
 17:09:59  we have 3 different broker domains already
 17:10:02  Another option is to only set up  records now, so that
 IPv4 traffic goes to the old broker and IPv6 traffic goes to the new.
 17:10:05  bamsoftware, freehaven, and tp.net
 17:10:25  Yeah and freehaven is a CNAME to bamsoftware, so really we
 only need to update bamsoftware and torproject.
 17:10:39  we could switch tp.net first and test with that
 17:10:54  since freehaven/bamsoftware is the deployed one
 17:11:04  we haven't deployed tp.net in the client or proxies yet
 17:11:24  Yeah I guess you're right.
 17:11:24  due to concerns that some places (like the UK) are good
 places for proxies but may block tor project domains
 17:11:54  And I guess that snowflake-broker.azureedge.net still
 points to the bamsoftware one, though I would have to check to be sure.
 17:12:19  Okay, that's a good idea cohosh. We need to ask someone to
 update the torproject.net names to the IP addresses mentioned in the
 ticket.
 17:13:14  Then we ourselves can test using the client with `-url
 https://snowflake-broker.torproject.net/' and proxy-go with `-broker https
 ://snowflake-broker.torproject.net/`
 }}}

 anarcat originally set up the snowflake-broker.torproject.net domain at
 comment:13:ticket:31232.

--
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] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by phw):

 * Attachment "tor-browser-alpha.png" added.

 Tor Browser alpha circuit display

--
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] #32125 [Applications/Tor Browser]: Using private obfs4 bridge does not show circuit display

[Tor Bug Tracker & Wiki]

#32125: Using private obfs4 bridge does not show circuit display
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by phw):

 I could reproduce this issue with one of the bridges that ggus is talking
 about. Here is its relay status page:
 
https://metrics.torproject.org/rs.html#details/7234CB14A260A862BA904ED1807E6B6B70D6

--
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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-9.0-must-alpha, ff68-esr, ux-|  Actual Points:  45
  team, TorBrowserTeam201910R|
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by pospeselr):

 * status:  reopened => 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] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha, ff68-esr, ux-|  Actual Points:  45
  team, TorBrowserTeam201910R|
Parent ID:   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by pospeselr):

 * status:  closed => reopened
 * resolution:  fixed =>
 * parent:  #10760 =>
 * actualpoints:   => 45


Comment:

 Should note the original points estimate was remaining work from the start
 of September, while the total points takes into account my work starting
 July 31. The Actual Points starting from September 2nd is '27'.

--
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] #32097 [Applications/Tor Browser]: Fix conflicts in mobile onbarding while rebasing to esr68.2.0

[Tor Bug Tracker & Wiki]

#32097: Fix conflicts in mobile onbarding while rebasing to esr68.2.0
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Major   | Resolution:
 Keywords:  TorBrowserTeam201910, tbb-9.0-must  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 Okay, I clobbered and rebuilt, and now it is happy. Unfortunately, now we
 have a "Sign Up" button on the botton of all onboarding panels and the
 Activity Stream (#31983) screen has a very large "Sign Up" button at the
 top, too. I'll fix 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] #22919 [Applications/Tor Browser]: Form tracking and OS fingerprinting (only Windows, but without Javascript)

[Tor Bug Tracker & Wiki]

#22919: Form tracking and OS fingerprinting (only Windows, but without 
Javascript)
-+-
 Reporter:  basvd|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201910   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 I don't believe GenerateRandomSeed is available outside of the js engine.
 But you're right about the bits

--
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] #31999 [Core Tor/Tor]: Default log file is handled inconsistently

[Tor Bug Tracker & Wiki]

#31999: Default log file is handled inconsistently
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #31241| Points:
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 I have a better approach here in a branch called `from_setconf_removal`
 with a PR in https://github.com/torproject/tor/pull/1425 .  I'm going to
 see what coveralls says, then write some tests and a better explanation of
 the change.

--
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: #27330, #30247, #3781, #3980, ...

[Tor Bug Tracker & Wiki]

Batch modification to #27330, #30247, #3781, #3980, #13878, #17214, #17425, 
#19693, #20770, #22664, #22665, #28231, #28232, #28233, #28284, #28340, #31339, 
#31982, #9036, #31313, #9071, #17212, #19951, #19952, #20116, #21382, #23072, 
#23225, #23226, #25887, #27148, #27972, #28092, #28339, #31377, #31459, #31533, 
#3862, #18750, #20659, #22011, #26175, #10692 by cohosh:


Comment:
cc'ing cohosh on open GetTor tickets.

--
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: #27330, #30247, #3781, #3980, ...

[Tor Bug Tracker & Wiki]

Batch modification to #27330, #30247, #3781, #3980, #13878, #17214, #17425, 
#19693, #20770, #22664, #22665, #28231, #28232, #28233, #28284, #28340, #31339, 
#31982, #9036, #31313, #9071, #17212, #19951, #19952, #20116, #21382, #23072, 
#23225, #23226, #25887, #27148, #27972, #28092, #28339, #31377, #31459, #31533, 
#3862, #18750, #20659, #22011, #26175, #10692 by cohosh:


--
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] #29397 [Internal Services/Tor Sysadmin Team]: Make use of some donated hardware

[Tor Bug Tracker & Wiki]

#29397: Make use of some donated hardware
-+-
 Reporter:  ln5  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  isabela => anarcat


Comment:

 the hardware is, basically:

  * 13 servers (mostly Dell R610 or R620 2xXeon with 386GB RAM and 2x500GB
 disk)
  * 8 storage arrays (Dell MD1220 or MD3200 21TB)
  * 8 network switches (Cisco 3740 or 4900M)
  * 5 routeurs (Cisco 2811, ASR9001, ASR1002 or ASR1004)

 this hardware was worth about 40 to 50k$ during the last evaluation, about
 6 months ago.

 the plan was to the ship the hardware to riseup and get them to set it up
 in exchange for hosting it in the long term. the setup cost is between 10
 to 15k$ and the shipping costs are between 3 to 5k$. this means a net
 20-30k$ benefit.

 we don't seem to have the funds to do the move right now, unfortunately,
 and we need to check if we could just host that stuff in place at cymru or
 if it absolutely needs to move out.

 so next step is to followup with cymru/sina. i also need to catchup with
 emails that arma sent me, but my email is down right now due to a major
 power outage in this area (!).

--
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] #31391 [Circumvention/Snowflake]: Do a reachability check before polling for clients

[Tor Bug Tracker & Wiki]

#31391: Do a reachability check before polling for clients
-+-
 Reporter:  cypherpunks  |  Owner:  arlolra
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-

Comment (by cohosh):

 I just did another health check using the modification to bridgetest
 [https://github.com/cohosh/bridgetest/tree/snowflake_health here]. I'm not
 getting failures from only ~1/3 of snowflake proxies which seems like a
 small improvement.

--
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] #32097 [Applications/Tor Browser]: Fix conflicts in mobile onbarding while rebasing to esr68.2.0

[Tor Bug Tracker & Wiki]

#32097: Fix conflicts in mobile onbarding while rebasing to esr68.2.0
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Major   | Resolution:
 Keywords:  TorBrowserTeam201910, tbb-9.0-must  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+--

Comment (by sysrqb):

 hrm. The build fails with that branch - proguard symbols.

--
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] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

[Tor Bug Tracker & Wiki]

#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910R, tbb-9.0   |  Actual Points:
  -must-alpha, tbb-proxy-bypass  |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * keywords:  TorBrowserTeam201910R, tbb-9.0-must-alpha =>
 TorBrowserTeam201910R, tbb-9.0-must-alpha, tbb-proxy-bypass


--
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] #32115 [Core Tor/Tor]: Hidden Service in TestingTorNetwork connected to non-Exit Nodes

[Tor Bug Tracker & Wiki]

#32115: Hidden Service in TestingTorNetwork connected to non-Exit Nodes
--+---
 Reporter:  lewis85   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by lewis85):

 Thank you very much for this clarification. I was errouneously referring
 to exit nodes as the nodes responsible to be the first hop for the hidden
 service in the circuit from the hidden service to the rendezvous point. As
 you mentioned, I should expect that the hidden service connects to the
 nodes flagged as "Guard" and this is what is happening in my testing
 environment.
 I am sorry for the confusion, it was my mistake. Thank you very much for
 providing this clarification. It was very helpful.

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