Re: [tor-bugs] #33782 [Core Tor/Tor]: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions

2020-04-02 Thread Tor Bug Tracker & Wiki
#33782: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions
--+
 Reporter:  ultimaweapon  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  0.4.2.6
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ultimaweapon):

 Updated to 65,536.

 Backport does not matter for me so it is up to you guys.

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

Re: [tor-bugs] #33782 [Core Tor/Tor]: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions

2020-04-02 Thread Tor Bug Tracker & Wiki
#33782: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions
--+
 Reporter:  ultimaweapon  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  0.4.2.6
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ultimaweapon):

 * Attachment "increase-test-fd.patch" added.


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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:5 cohosh]:
 > 1. log debug information and encourage the owner through the UI to file
 a Tor ticket with the log messages so we can figure out what's going on,
 > 2. keep track of how many times this happens, and if it always happens
 (the proxy sees no successful connections) disable the proxy and print out
 some debug messages,
 > 3. do a probe test only when the datachannel fails to open to check
 whether the proxy can open a datachannel with the probe point.

 My opinion on this is that (2) is a reasonable idea. (I said (3) in the
 meeting today but I meant (2).)

 It does open a new DoS vector: a malicious client can fail all its
 DataChannels and cause proxies to think they are unreliable.

 comment:8 shows that failure rate may be as much a function of the client
 as of the proxy. Maybe this is a mutally incompatible NAT situation? The
 symptoms you mention in comment:2 match that. It's possible that both
 peers are sending binding requests to each other, but neither are making
 it all the way to the other side.

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

Re: [tor-bugs] #29399 [Internal Services/Tor Sysadmin Team]: Retire host and services for tordnsel and check (chiwui)

2020-04-02 Thread Tor Bug Tracker & Wiki
#29399: Retire host and services for tordnsel and check (chiwui)
-+-
 Reporter:  ln5  |  Owner:  irl
 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:
-+-

Comment (by anarcat):

 should we do this now? is chiwui finally ready for decomissionning?

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

Re: [tor-bugs] #33082 [Internal Services/Tor Sysadmin Team]: decomission kvm3 AKA macrum, 7 VMs to migrate

2020-04-02 Thread Tor Bug Tracker & Wiki
#33082: decomission kvm3 AKA macrum, 7 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> * [ ] crm-ext-01.torproject.org (part of #32198) test server ready (but
> shutdown) at `116.202.120.186`
>  * [ ] crm-int-01.torproject.org (also part of #32198) test server ready
> (but shutdown) `116.202.120.190`
>  * [ ] forrestii.torproject.org (fpcentral, #33729) test server ready at
> `116.202.120.185`
>  * [ ] nevii.torproject.org (DNS master) - not migrated, ran out of IP,
> opened Ticket#2020032503025825 with hetzner to followup
>  * [x] rude.torproject.org (RT) - migrated to `116.202.120.187`
>  * [ ] troodi.torproject.org (Trac, #33731) - test server ready at
> `116.202.120.188`
>  * [x] vineale.torproject.org (gitweb, #33730) - done, new IP is
> `116.202.120.189`
>
> The CRM machines might have already been migrated by the time we start
> this, see #32198.
>
> Will require a new Ganeti node (#33083).

New description:

 * [ ] crm-ext-01.torproject.org (part of #32198) test server ready (but
 shutdown) at `116.202.120.186`
  * [ ] crm-int-01.torproject.org (also part of #32198) test server ready
 (but shutdown) `116.202.120.190`
  * [ ] forrestii.torproject.org (fpcentral, #33729) test server ready at
 `116.202.120.185`
  * [ ] nevii.torproject.org (DNS master) - not migrated, ran out of IP,
 opened Ticket#2020032503025825 with hetzner to followup
  * [x] rude.torproject.org (RT) - migrated to `116.202.120.187`
  * [x] troodi.torproject.org (Trac, #33731) - migrated to
 `116.202.120.188`
  * [x] vineale.torproject.org (gitweb, #33730) - done, new IP is
 `116.202.120.189`

 The CRM machines might have already been migrated by the time we start
 this, see #32198.

 Will require a new Ganeti node (#33083).

--

Comment (by anarcat):

 troodi/trac 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] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 I attached some results of testing proxy failures at home and on a Linode
 VPS. Only 24.79% of ICE answers turned into a working proxy at home,
 versus 83.62% on the VPS.

 Starting at commit 237fed11, apply attachment:snowflake-client-
 proxytest.patch. Run `./client -url https://snowflake-
 broker.azureedge.net/ -front ajax.aspnetcdn.com -ice
 stun:stun.l.google.com:19302 -max 1` (no tor needed). Run `Rscript
 proxytest.R proxytest.csv`. The outputs are in attachment:proxytest-
 home.csv.gz and attachment:proxytest-vps.csv.gz and attachment:proxytest.R
 does some basic analysis. The data are in "long" CSV format with one row
 per feature, but the script reshapes them into "wide" format with one row
 per proxy attempt and one column per feature. The `id` and `attempt`
 columns together define one broker interaction and proxy connection
 attempt. Attempts where the broker returned an answer have
 `is.na(broker_err)`. Attempts that succeeded in opening a DataChannel have
 `!is.na(ts_open)`. Locally I have the full offer/answer SDP strings but I
 didn't get a pcap.

 The test falsifies a few hypotheses I had.
  * Hypothesis: I can only use proxies that have an IPv6 address. No, 9/29
 successful attempts did not have an IPv6 address.
  * Hypothesis: I can only use proxies that send a nonzero address in the
 `c=` line. No, 16/29 successful attempts had `0.0.0.0` in the `c=` line.

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "proxytest.R" added.

 Script to do some analysis on proxytest.csv.

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "proxytest-vps.csv.gz" added.

 proxytest.csv output from running on a VPS.

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "proxytest-home.csv.gz" added.

 proxytest.csv output from running at home.

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

Re: [tor-bugs] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

2020-04-02 Thread Tor Bug Tracker & Wiki
#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202004R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

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


Comment:

 Replying to [comment:139 emmapeel]:
 > Replying to [comment:138 mcs]:
 > > Replying to [comment:136 acat]:
 > > > Replying to [comment:133 steph]:
 > > >
 > > > Thanks, revised the torbutton patch in
 https://github.com/acatarineu/torbutton/commit/21952+2.
 >
 > > r=brade,r=mcs
 > > These two patches look good to us.
 >
 > The strings on this patch look good to me.

 W! Thanks for your hard work on this! Very exciting!

 The tor-browser patch had a small merge conflict with #28005 in
 `browser/components/onionservices/moz.build`. The conflict seemed simple
 enough, so I resolved it.

 {{{
 ++<<< HEAD
  +'ExtensionMessaging.jsm',
  +'HttpsEverywhereControl.jsm',
  +'OnionAliasStore.jsm',
 ++===
 + 'OnionLocationChild.jsm',
 + 'OnionLocationParent.jsm',
 ++>>> da5513527e50e7f13e3b1c3206ed75ff8fbd76db
 }}}

 Merged with commit `2d2c850302274bdf1a506949856c91c5b138983c`.

 The torbutton patch merged with commit
 `dd027529aecd4f6632c41b2f07bd6519b0e4cbf5`.

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

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

2020-04-02 Thread Tor Bug Tracker & Wiki
#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 Replying to [comment:39 mcs]:
 > Replying to [comment:37 acat]:
 > > Thanks again for the review. Revised branches:
 https://github.com/acatarineu/tor-browser/commit/28005+4,
 https://github.com/acatarineu/torbutton/commit/28005+2.
 >
 > The torbutton patch looks good.

 Almost missed this. torbutton patch merge with commit
 `b2d4c6348cb7cc604ef705b04837baf5db59041f`.

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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "snowflake-client-proxytest.patch" added.

 Patch to have snowflake-client emit a proxytest.csv with details about
 every connection attempt.

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

Re: [tor-bugs] #19251 [Applications/Tor Browser]: TorBrowser might want to have an error page specific to when .onion links fail

2020-04-02 Thread Tor Bug Tracker & Wiki
#19251: TorBrowser might want to have an error page specific to when .onion 
links
fail
-+-
 Reporter:  cypherpunks  |  Owner:  brade
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, TorBrowserTeam202004R,  |  Actual Points:  7.1
  tbb-9.5a10 |
Parent ID:  #30025   | Points:  6
 Reviewer:  acat,pospeselr   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

 * status:  needs_review => closed
 * keywords:  ux-team, TorBrowserTeam202004R => ux-team,
 TorBrowserTeam202004R, tbb-9.5a10
 * resolution:   => fixed


Comment:

 Replying to [comment:56 emmapeel]:
 > @sysrqb, this looks good for l10n!

 Thanks!


 Replying to [comment:50 acat]:
 > The patches look good to me too.
 >
 > Replying to [comment:46 mcs]:
 > > Replying to [comment:45 pospeselr]:
 [snip]
 > > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug30237-04=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc
 > >

 Merged with commit `31200493ae908e01ecbeeb44e0546a354ea8736d`

 > > The Torbutton patch is unchanged:
 > >
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b

 Merged with commit `751a8d02b6ca5e7c8e2a05972c83f2776996f3d8`.

 Thanks for all your work on this!

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

Re: [tor-bugs] #33726 [Applications/Tor Browser]: Fix patch for #23247: Communicating security expectations for .onion

2020-04-02 Thread Tor Bug Tracker & Wiki
#33726: Fix patch for #23247: Communicating security expectations for .onion
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:| Points:
 Reviewer:  pospeselr |Sponsor:
--+--
Changes (by sysrqb):

 * reviewer:   => pospeselr


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

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

2020-04-02 Thread Tor Bug Tracker & Wiki
#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

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


Comment:

 Awesome, let's see how this looks in nightlies. Thanks for all of you hard
 work on this!

 Cherry-picked as commit `7306a08365be9212f621b396513352d19549c487`.

 (Remember #33694 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] #33707 [Applications/Tor Browser]: Swap out onion icon in circuit display with new one

2020-04-02 Thread Tor Bug Tracker & Wiki
#33707: Swap out onion icon in circuit display with new one
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202004R |  Actual Points:  0.25
Parent ID:  #28005| Points:  0.25
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by sysrqb):

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


Comment:

 Thanks! Merged with commit `d2ca013e59444c04c9e0589a80bf6f611b3aebec`.

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

Re: [tor-bugs] #33694 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Allow setting up a locked update channel programatically

2020-04-02 Thread Tor Bug Tracker & Wiki
#33694: Allow setting up a locked update channel programatically
-+-
 Reporter:  acat |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * parent:  #28005 =>


Comment:

 Unblock parent.

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

Re: [tor-bugs] #33723 [Applications/Tor Browser]: Bump openssl version to 1.1.1f for Tor Browser

2020-04-02 Thread Tor Bug Tracker & Wiki
#33723: Bump openssl version to 1.1.1f for Tor Browser
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-9.0.8, tbb-9.5a10,   |  Actual Points:
  TorBrowserTeam202004   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

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


Comment:

 I messed up the commits, but let's say this was bumped on maint-9.0 as
 commit `794680cb71becc710cb2fa180a1d48450abf` and master as commit
 `829dfa4c161af489e065c354a6fbb6e8c90ff445`.

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

Re: [tor-bugs] #33761 [Applications/Tor Browser]: Remove unnecessary dependencies of Snowflake from Tor Browser

2020-04-02 Thread Tor Bug Tracker & Wiki
#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
---+
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam202004R, tbb-9.5a10  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by sysrqb):

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


Comment:

 Looks okay to me. Cherry-picked as commit
 `499d7c746833b90621a82a74bb52c2e780e3837e` on master.

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

Re: [tor-bugs] #33693 [Applications/Tor Browser]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

2020-04-02 Thread Tor Bug Tracker & Wiki
#33693: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW
controller events show no bandwidth used
--+
 Reporter:  arma  |  Owner:  cohosh
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-9.5a10|  Actual Points:
Parent ID:  #19001| Points:
 Reviewer:|Sponsor:
--+
Changes (by sysrqb):

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


Comment:

 This is commit `dfdf0e22bf9989952cae8c076e512bd898dac90a` on tor-browser-
 build master.

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

Re: [tor-bugs] #10831 [Circumvention/BridgeDB]: Captchas are not accessible for blind users

2020-04-02 Thread Tor Bug Tracker & Wiki
#10831: Captchas are not accessible for blind users
-+-
 Reporter:  PZajda   |  Owner:  juggy
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-reportbug, bridgedb-ui, |  Actual Points:
  anti-censorship-roadmap-2020Q1 , s30-o22a2 |
Parent ID:  #31279   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by phw):

 * status:  needs_review => new


Comment:

 Replying to [comment:24 juggy]:
 > I wrote a sample web server [https://github.com/jugheadjones10/bridgedb-
 audio-captcha] that serves the original BridgeDB captcha page with audio
 captchas (using suggestions from the comments here). Could I receive some
 feedback about any naive code or problems that might arise if this is
 integrated into BridgeDB? Thank you!
 [[br]]
 Thanks for working on this! I gave it a shot and it worked for me. Here
 are some thoughts:

 * The size of a single audio CAPTCHA seems to be approximately 85 KB. It
 should be straightforward to add the audio CAPTCHA to
 bridges.torproject.org but if possible, we should also make it available
 over moat. We could encode it in Base64 and send it in the HTTP response
 to a moat request. However, > 85 extra KB per request sounds expensive for
 a CAPTCHA that only a small fraction of users would use but we may be able
 to reduce the size.

 * The library's default voice is English, which is a potential usability
 problem. It would be neat if we had multiple languages but this doesn't
 strike me as a critical issue. Most people will recognise English numbers.

 * Your GitHub repository contains the following question:
 > A concern : Given the simple input-output nature of the Python audio
 captcha library, it seems like it wouldn't take long to train a simple
 model to accurately crack the audio captcha.
   That's true but I wouldn't expect the audio CAPTCHA to be easier to
 break than the visual CAPTCHA, or am I missing something? As long as it
 doesn't make our distributor easier to attack, I see no problem in
 deploying it.

 * Out of curiosity, did you take a look at other libraries too? If so, why
 did you end up using https://github.com/lepture/captcha ?

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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

2020-04-02 Thread Tor Bug Tracker & Wiki
#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 It's also worth noting that Zoom has had serious security issues in the
 past:
 https://www.zdnet.com/article/zoom-defends-use-of-local-web-server-on-
 macs-after-security-report/

 And its install still acts like malware on some systems:
 https://appleinsider.com/articles/20/03/31/zoom-macos-install-shady-plus-
 video-chats-arent-end-to-end-encrypted

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

Re: [tor-bugs] #33406 [Internal Services/Tor Sysadmin Team]: automate reboots

2020-04-02 Thread Tor Bug Tracker & Wiki
#33406: automate reboots
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i did more work on the reboot procedures today, and rebooted the ganeti
 cluster using the reboot command. there were some issues with the initrd
 interfering with the `wait_for_boot` (now called `wait_for_ping`) checks
 so I did some refactoring, but i'm still confused about the exception
 that's raised by Fabric in this case.

 the exception I got here is:

 {{{
 All instances migrated successfully.
 Shutdown scheduled for Thu 2020-04-02 18:30:55 UTC, use 'shutdown -c'
 to cancel.
 waiting 0 minutes for reboot to happen
 waiting up to 30 seconds for host to go down
 waiting 300 seconds for host to go up
 host fsn-node-01.torproject.org should be back online, checking uptime
 Traceback (most recent call last):
   File "./reboot", line 132, in 
 logging.getLogger(mod).setLevel('WARNING')
   File "./reboot", line 116, in main
 delay_up=args.delay_up,
   File "/usr/lib/python3/dist-packages/invoke/tasks.py", line 127, in
 __call__
 result = self.body(*args, **kwargs)
   File "/home/anarcat/src/tor/tsa-misc/fabric_tpa/reboot.py", line
 197, in shutdown_and_wait
 res = con.run('uptime', watchers=[responder], pty=True, warn=True)
   File "", line 2, in run
   File "/usr/lib/python3/dist-packages/fabric/connection.py", line 29,
 in opens
 self.open()
   File "/home/anarcat/src/tor/tsa-misc/fabric_tpa/__init__.py", line
 106, in safe_open
 Connection.open_orig(self)
   File "/usr/lib/python3/dist-packages/fabric/connection.py", line
 634, in open
 self.client.connect(**kwargs)
   File "/usr/lib/python3/dist-packages/paramiko/client.py", line 349,
 in connect
 retry_on_signal(lambda: sock.connect(addr))
   File "/usr/lib/python3/dist-packages/paramiko/util.py", line 280, in
 retry_on_signal
 return function()
   File "/usr/lib/python3/dist-packages/paramiko/client.py", line 349,
 in 
 retry_on_signal(lambda: sock.connect(addr))
 TimeoutError: [Errno 110] Connection timed out
 }}}

 maybe the exception gets generated *above* our code, in the fabric task
 handler itself, in which case it might mean we shouldn't use a @task for
 this at all, at least in our code.

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

Re: [tor-bugs] #33796 [Core Tor/Tor]: socks: Prefer IPv6 by default on SOCKS port broke torsocks

2020-04-02 Thread Tor Bug Tracker & Wiki
#33796: socks: Prefer IPv6 by default on SOCKS port broke torsocks
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dns torsocks ipv6 043-must  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * keywords:  tor-dns torsocks ipv6 => tor-dns torsocks ipv6 043-must


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

Re: [tor-bugs] #30638 [Core Tor/Tor]: Test banning ed25519 keys in the approved-routers file on moria1

2020-04-02 Thread Tor Bug Tracker & Wiki
#30638: Test banning ed25519 keys in the approved-routers file on moria1
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-dirauth, 042-deferred-20190918   |  Actual Points:
  043-should, network-health |
Parent ID:   | Points:  1
 Reviewer:  arma |Sponsor:
-+-
Changes (by teor):

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


Comment:

 We merged this code in 0.4.3, and there are unit tests for it.
 Maybe we should have asked for a tor "make check" integration test as
 well.

 Let's just close this ticket?

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

Re: [tor-bugs] #33686 [Core Tor/Tor]: Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled

2020-04-02 Thread Tor Bug Tracker & Wiki
#33686: Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-sandbox, 035-backport,   |  Actual Points:
  041-backport, 042-backport, 043-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-sandbox => tor-sandbox, 035-backport, 041-backport,
 042-backport, 043-backport


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

Re: [tor-bugs] #33686 [Core Tor/Tor]: Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled

2020-04-02 Thread Tor Bug Tracker & Wiki
#33686: Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.7
 Severity:  Normal| Resolution:
 Keywords:  tor-sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => tor-sandbox


Comment:

 Your 0.4.2.6 was not built with sandboxing enabled.
 What about building 0.4.2.6 with sandboxing enabled?

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

Re: [tor-bugs] #33782 [Core Tor/Tor]: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions

2020-04-02 Thread Tor Bug Tracker & Wiki
#33782: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions
--+
 Reporter:  ultimaweapon  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  0.4.2.6
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: unspecified => 0.4.2.6


Comment:

 I would use 1000 as the minimum fake FD.
 Or something ridiculously large, like 30,000.

 Most systems default to 512 or 1024 file descriptors as a minimum.
 So most processes tor is embedded in shouldn't ever use that many.

 Also, do we want to backport this patch?
 It seems like a good candidate for 0.4.3 at least.

 It also seems like we might run into this issue more often, because more
 people are embedding tor. (It's unusual to embed the unit tests, but not
 entirely unreasonable. For example, we like to know if the unit tests pass
 on a real iOS device.)

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

Re: [tor-bugs] #33795 [Applications/Tor Browser]: Connection Failed

2020-04-02 Thread Tor Bug Tracker & Wiki
#33795: Connection Failed
--+--
 Reporter:  Hezmana   |  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 teor):

 * owner:  (none) => tbb-team
 * component:  Core Tor => Applications/Tor Browser


Comment:

 Hi, this looks like a Tor Browser error, passing it to that 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

[tor-bugs] #33801 [Applications/Tor Browser]: Upgrade Go Project to use new Android Toolchain

2020-04-02 Thread Tor Bug Tracker & Wiki
#33801: Upgrade Go Project to use new Android Toolchain
--+
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile,
  |  Android
Actual Points:|  Parent ID:  #33184
   Points:|   Reviewer:
  Sponsor:|
--+
 Go needs to use new NDK path

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

Re: [tor-bugs] #33796 [Core Tor/Tor]: socks: Prefer IPv6 by default on SOCKS port broke torsocks

2020-04-02 Thread Tor Bug Tracker & Wiki
#33796: socks: Prefer IPv6 by default on SOCKS port broke torsocks
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-dns torsocks ipv6  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Tor Browser has set PreferIPv6 for some time.
 But I guess that isn't a common config for torsocks?

 And there aren't any unit tests or integration tests that make sure that
 torsocks keeps working?
 That's a shame, we would have caught this issue much earlier.

 We thought that allowing users to configure NoPreferIPv6 in tor was
 enough. But that only works if people control their system tor instance.

 Here's what I suggest we do:
 * undo the default PreferIPv6 flag change in 0.4.3
 * re-do the default PreferIPv6 flag change in 0.4.4
 * add new socks commands for IPv4-only and IPv6-only in 0.4.4
 * update torsocks to use those commands (when available)
 * write unit tests or integration tests that cover the Torsocks use cases

 How much of that work are you able to do, dgoulet?

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

Re: [tor-bugs] #33800 [Circumvention/Snowflake]: Remove uniuri dependency

2020-04-02 Thread Tor Bug Tracker & Wiki
#33800: Remove uniuri dependency
-+--
 Reporter:  dcf  |  Owner:  dcf
 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:  assigned => needs_review


Comment:

 This patch replaces `uniuri.New()` with a manual call to
 `crypto/rand.Read`. Panicking on read error is the same thing uniuri does.
 8 hex-encoded bytes are the same length as `uniuri.New()`, but only 64
 bits compared to `uniuri.New()`'s ~95 bits (16 characters of base-62).

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

Re: [tor-bugs] #33800 [Circumvention/Snowflake]: Remove uniuri dependency

2020-04-02 Thread Tor Bug Tracker & Wiki
#33800: Remove uniuri dependency
-+--
 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 "0001-Remove-uniuri-dependency.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] #33800 [Circumvention/Snowflake]: Remove uniuri dependency

2020-04-02 Thread Tor Bug Tracker & Wiki
#33800: Remove uniuri dependency
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 uniuri is only used in a minor way, to generate a random string for local
 identification of a snowflake client.

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

Re: [tor-bugs] #5304 [Circumvention/Obfs4]: Obfsproxy should respect OutboundBindAddress in torrc

2020-04-02 Thread Tor Bug Tracker & Wiki
#5304: Obfsproxy should respect OutboundBindAddress in torrc
-+-
 Reporter:  korobkov |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-spec-change needs-tor-change,  |  Actual Points:  1.25
  network-team-roadmap-2020Q1, 043-should|
Parent ID:  #30471   | Points:  1
 Reviewer:  phw  |Sponsor:
 |  Sponsor28-must
-+-

Comment (by phw):

 Replying to [comment:45 catalyst]:
 > phw, do these cover all of your previous feedback?
 [[br]]
 Yes it does, thanks!

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

Re: [tor-bugs] #33731 [Internal Services/Service - trac]: troodi IP address change planned for Ganeti migration

2020-04-02 Thread Tor Bug Tracker & Wiki
#33731: troodi IP address change planned for Ganeti migration
--+
 Reporter:  anarcat   |  Owner:  qbi
 Type:  project   | Status:  closed
 Priority:  High  |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  tpa-roadmap-march |  Actual Points:
Parent ID:  #33082| Points:
 Reviewer:|Sponsor:
--+
Changes (by anarcat):

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


Comment:

 {{{
 --- /mnt/etc/network/interfaces.bak 2020-04-02 19:56:57.727733279
 +
 +++ /mnt/etc/network/interfaces 2020-04-02 19:56:58.819724484 +
 @@ -1,11 +1,16 @@
 +# This file describes the network interfaces available on your system
 +# and how to activate them. For more information, see interfaces(5).
 +
 +# The loopback network interface
  auto lo
  iface lo inet loopback

 -allow-hotplug eth0
 +# The primary network interface
 +auto eth0
  iface eth0 inet static
 -address 138.201.212.227/28
 -gateway 138.201.212.225
 +address 116.202.120.188/27
 +gateway 116.202.120.161
  iface eth0 inet6 static
  accept_ra 0
 -address 2a01:4f8:172:39ca:0:dad3:3:1/96
 -gateway 2a01:4f8:172:39ca:0:dad3:0:1
 +address 2a01:4f8:fff0:4f:266:37ff:fea7:aa94/64
 +gateway 2a01:4f8:fff0:4f::1
 --- /mnt/etc/hosts.bak  2020-04-02 19:57:01.663701577 +
 +++ /mnt/etc/hosts  2020-04-02 19:57:03.603685953 +
 @@ -3,7 +3,7 @@
  ##

  127.0.0.1   localhost
 -138.201.212.227troodi.torproject.org troodi
 +116.202.120.188 troodi.torproject.org troodi

  # The following lines are desirable for IPv6 capable hosts
  ::1 localhost ip6-localhost ip6-loopback
 @@ -12,3 +12,4 @@
  ff02::1 ip6-allnodes
  ff02::2 ip6-allrouters
  ff02::3 ip6-allhosts
 +2a01:4f8:fff0:4f:266:37ff:fea7:aa94 troodi.torproject.org troodi
 }}}

 switched in nagios, switched in LDAP, ran puppet on pauli and the node...
 it seems the node was only present in nagios in our git, so this 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] #33156 [Core Tor/Tor]: DoS subsystem should compare IPv6 /64

2020-04-02 Thread Tor Bug Tracker & Wiki
#33156: DoS subsystem should compare IPv6 /64
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security-?, tor-relay, tor-dirauth,  |  Actual Points:
  dos|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 One question: may I please know which functions in the code corresponds to
 the filter list?

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

Re: [tor-bugs] #33790 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Does https-everywhere still use tor trac for bugtracker?

2020-04-02 Thread Tor Bug Tracker & Wiki
#33790: Does https-everywhere still use tor trac for bugtracker?
-+-
 Reporter:  arma |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by legind):

 Hey arma.

 I've removed the Tor trac from the list of ways to file bugs, since Github
 is the preferred way, and we check that regularly.

 It is likely many of the old tickets no longer apply, either because they
 have been fixed separately or they apply to the old XPCOM extension.
 Would it be possible to mass-close HTTPS Everywhere tickets older than,
 say, 18 months, with a notice to the issuer to re-open the ticket if it is
 still valid?

 Then with the remaining tickets we should triage them into github.

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

Re: [tor-bugs] #33731 [Internal Services/Service - trac]: troodi IP address change planned for Ganeti migration

2020-04-02 Thread Tor Bug Tracker & Wiki
#33731: troodi IP address change planned for Ganeti migration
--+
 Reporter:  anarcat   |  Owner:  qbi
 Type:  project   | Status:
  |  needs_review
 Priority:  High  |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Major | Resolution:
 Keywords:  tpa-roadmap-march |  Actual Points:
Parent ID:  #33082| Points:
 Reviewer:|Sponsor:
--+

Comment (by anarcat):

 DNS lowered to 5m on troodi, starting last sync

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

Re: [tor-bugs] #33799 [- Select a component]: test

2020-04-02 Thread Tor Bug Tracker & Wiki
#33799: test
--+-
 Reporter:  anarcat   |  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 anarcat):

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


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

[tor-bugs] #33799 [- Select a component]: test

2020-04-02 Thread Tor Bug Tracker & Wiki
#33799: test
--+
 Reporter:  anarcat   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 this is a test ticket, maybe it will even work

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

Re: [tor-bugs] #10831 [Circumvention/BridgeDB]: Captchas are not accessible for blind users

2020-04-02 Thread Tor Bug Tracker & Wiki
#10831: Captchas are not accessible for blind users
-+-
 Reporter:  PZajda   |  Owner:  juggy
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-reportbug, bridgedb-ui, |  Actual Points:
  anti-censorship-roadmap-2020Q1 , s30-o22a2 |
Parent ID:  #31279   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by juggy):

 * status:  needs_revision => 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] #10831 [Circumvention/BridgeDB]: Captchas are not accessible for blind users

2020-04-02 Thread Tor Bug Tracker & Wiki
#10831: Captchas are not accessible for blind users
-+-
 Reporter:  PZajda   |  Owner:  juggy
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-reportbug, bridgedb-ui, |  Actual Points:
  anti-censorship-roadmap-2020Q1 , s30-o22a2 |
Parent ID:  #31279   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by juggy):

 * status:  assigned => needs_revision


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

Re: [tor-bugs] #33798 [Internal Services/Tor Sysadmin Team]: Please destroy static site atlas.torproject.org

2020-04-02 Thread Tor Bug Tracker & Wiki
#33798: Please destroy static site atlas.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 If there is some way of easily replacing the static site with a permanent
 redirect to https://metrics.torproject.org/rs.html then that's fine too.
 Right now we have a temporary redirect there, but still, this shouldn't be
 around forever.

 If it's important enough to have an easy URL to communicate verbally, then
 I should prioritize adding that search box to the metrics homepage in the
 roadmap tasks.

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

Re: [tor-bugs] #33798 [Internal Services/Tor Sysadmin Team]: Please destroy static site atlas.torproject.org

2020-04-02 Thread Tor Bug Tracker & Wiki
#33798: Please destroy static site atlas.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 Replying to [comment:2 irl]:
 > Having an easy to communicate URL would be good, but atlas is a bit
 confusing now. We don't use that name anywhere else. As soon as we've
 dealt with more urgent things, I'm hopeful I will one day return to adding
 a search box directly on the metrics.tpo homepage.

 a redirect then maybe?

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

Re: [tor-bugs] #33798 [Internal Services/Tor Sysadmin Team]: Please destroy static site atlas.torproject.org

2020-04-02 Thread Tor Bug Tracker & Wiki
#33798: Please destroy static site atlas.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 Having an easy to communicate URL would be good, but atlas is a bit
 confusing now. We don't use that name anywhere else. As soon as we've
 dealt with more urgent things, I'm hopeful I will one day return to adding
 a search box directly on the metrics.tpo homepage.

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

Re: [tor-bugs] #33798 [Internal Services/Tor Sysadmin Team]: Please destroy static site atlas.torproject.org

2020-04-02 Thread Tor Bug Tracker & Wiki
#33798: Please destroy static site atlas.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 All good things come to an end I guess.

 I'll put up a minor point in favor of keeping it going: it's an easy url
 to tell people (using voice, in talks and at conferences).

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

Re: [tor-bugs] #33700 [Internal Services/Services Admin Team]: audio- and video-conferencing considerations

2020-04-02 Thread Tor Bug Tracker & Wiki
#33700: audio- and video-conferencing considerations
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> With the rise of the coronavirus, even Tor, which generally works
> remotely, is affected because we were still having physical meetings from
> time to time, and we'll have to find other ways to deal with this.
>
> This ticket aims at establishing the problem space ("what we're trying to
> solve") and evaluate possible solutions ("what could fix it"). we could
> follow the sysadmin documentation template:
>
> https://help.torproject.org/tsa/howto/template/#Discussion
>
> which establishes the following criterion:
>
> = Goals
> == Must have
>
>  * video/audio communication for a group of people of approx 2-10 people
>  * specifically, work session for teams internal to TPI
>  * chat fallback
>  * have a mobile app
>  * allow people to call in by regular phone
>  * a way for one person to mute themselves
>  * long term maintenance costs covered
>
> == Nice to have
>
>  * Reliable video support. Video chat is nice, but most video chat
> systems usually require all participants to have video off otherwise the
> communication is sensibly lagged.
>  * usable to host a Tor meeting, which means more load (because possibly
> > 20 people) and more tools (like slide sharing or whiteboarding)
>  * respecting our privacy, peer to peer encryption or at least encrypted
> with keys we control
>  * free and open source software
>  * tor support
>
> == Non-goals
>

> = Approvals required
>
> = Proposed solution
>
> = Cost
>
> = Alternatives considered
>
> == mumble
>
> === features
>
>  * audio-only
>  * moderation
>  * multiple rooms
>  * native client for Linux, Windows, Mac, iOS, Android
>  * web interface https://github.com/Johni0702/mumble-web
>  * chat
>
> === installation
>
> there are two different puppet modules to setup mumble:
>
> ​https://github.com/voxpupuli/puppet-mumble
> ​https://0xacab.org/riseup-puppet-recipes/mumble
>
> still need to be evaluated, but i'd be tempted to use the voxpupuli
> module because they tend to be better tested and it's more recent
>
> == jitsi
>
> === installation
>
> ansible roles: ​https://code.immerda.ch/o/ansible-jitsi-meet/
> ​https://github.com/UdelaRInterior/ansible-role-jitsi-meet
>
> there's also a docker container and (messy) debian packages
>
> prometheus exporter: ​https://github.com/systemli/prometheus-jitsi-meet-
> exporter
>
> == Nextcloud
>
> systemli is using this ansible role to install coturn:
> ​https://github.com/systemli/ansible-role-coturn
>
> == BBB
>
> features:
>
>  * audio, video conferencing support
>  * [http://docs.bigbluebutton.org/support/faq.html#accessibility
> accesssible] with live closed captionning and support for screen readers
>  * whiteboarding and "slideshow" mode (to show PDF presentations)
>  * moderation tools
>  * chat box
>  * embedded etherpad
>  * dial-in support with Freeswitch
>  * should scale better than jitsi and NC, at least
> [http://docs.bigbluebutton.org/support/faq.html#how-many-simultaneous-
> users-can-bigbluebutton-support according to their FAQ]: "As a rule of
> thumb, if your BigBlueButton server meets the minimum requirements, the
> server should be able to support 150 simultaneous users, such as 3
> simultaneous sessions of 50 users, 6 x 25, etc. We recommend no single
> sessions exceed one hundred (100) users."
>
> i tested an instance setup by a fellow sysadmin and we had trouble after
> a while, even with two people, doing a screenshare. it's unclear what the
> cause of the problem was: maybe the server was overloaded. more testing
> required.
>
> === installation
>
> [https://docs.bigbluebutton.org/2.2/install.html based on unofficial
> Debian packages], requires Freeswitch for dialin, which doesn't behave
> well under virtualization (so would need a bare metal server).

New description:

 With the rise of the coronavirus, even Tor, which generally works
 remotely, is affected because we were still having physical meetings from
 time to time, and we'll have to find other ways to deal with this.

 This ticket aims at establishing the problem space ("what we're trying to
 solve") and evaluate possible solutions ("what could fix it"). we 

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:3 cohosh]:
 > After restarting the snowflake network health tests from #32545, I'm
 noticing that ~50 out of 400 snowflakes are failing. 12.5% is pretty high.

 I'll run an experiment locally to try to characterize the nature of
 failures that I see. I'm pretty sure that for me, the proportion of
 failing proxies is more than 50%.

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

Re: [tor-bugs] #25283 [Metrics/Relay Search]: Decide when we can turn off atlas.torproject.org

2020-04-02 Thread Tor Bug Tracker & Wiki
#25283: Decide when we can turn off atlas.torproject.org
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  metrics-2018  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


Comment:

 Request filed for the static site to be destroyed #33798.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33798 [Internal Services/Tor Sysadmin Team]: Please destroy static site atlas.torproject.org

2020-04-02 Thread Tor Bug Tracker & Wiki
#33798: Please destroy static site atlas.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 To give you a chance to exercise the procedure at:
 https://help.torproject.org/tsa/howto/static-component/

 In #25283 we have done an analysis to show that most things are no longer
 hitting this site, and we don't want to keep things around forever.

 This is not urgent, no need to rush.

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

Re: [tor-bugs] #33508 [Metrics/Exit Scanner]: Write Ops Doc for check service

2020-04-02 Thread Tor Bug Tracker & Wiki
#33508: Write Ops Doc for check service
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:  0.5
Parent ID:  #33507   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * actualpoints:   => 0.5


Comment:

 This will end up at https://help.torproject.org/metrics/ops/exit-ops/ and
 is still a work in progress.

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

Re: [tor-bugs] #33717 [Metrics/Cloud]: Define metrics-common group vars to replace exit-scanner-sys role

2020-04-02 Thread Tor Bug Tracker & Wiki
#33717: Define metrics-common group vars to replace exit-scanner-sys role
---+--
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:  0.1
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * actualpoints:   => 0.1


Comment:

 This might be done, but is untested as yet.

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

Re: [tor-bugs] #33715 [Metrics/Cloud]: Create a metrics-common role and ops doc (was: Create a metrics-common role)

2020-04-02 Thread Tor Bug Tracker & Wiki
#33715: Create a metrics-common role and ops doc
---+--
 Reporter:  irl|  Owner:  irl
 Type:  project| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:  1.2
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * actualpoints:   => 1.2


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

Re: [tor-bugs] #33716 [Metrics/Cloud]: Create user accounts for Metrics Team and add SSH keys

2020-04-02 Thread Tor Bug Tracker & Wiki
#33716: Create user accounts for Metrics Team and add SSH keys
---+
 Reporter:  irl|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:  0.2
Parent ID:  #33715 | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

 * actualpoints:   => 0.2


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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+--
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  new => needs_review


Comment:

 Here's a patch that implements a variation of option (2) above. If the
 proxy fails to open a datachannel more than a threshold number of times
 since the last success, it is disabled with a new missingFeatures message.

 https://github.com/cohosh/snowflake/pull/25

 Let's get some feedback on this idea before moving further.

 I tested this by applying the following patch to the client:
 {{{
 diff --git a/client/lib/rendezvous.go b/client/lib/rendezvous.go
 index 1f98e26..330c90a 100644
 --- a/client/lib/rendezvous.go
 +++ b/client/lib/rendezvous.go
 @@ -11,6 +11,7 @@ package lib
  import (
 "bytes"
 "errors"
 +   "fmt"
 "io"
 "io/ioutil"
 "log"
 @@ -119,8 +120,8 @@ func (bc *BrokerChannel) Negotiate(offer
 *webrtc.SessionDescription) (
 if nil != err {
 return nil, err
 }
 -   answer := util.DeserializeSessionDescription(string(body))
 -   return answer, nil
 +   util.DeserializeSessionDescription(string(body))
 +   return nil, fmt.Errorf("Dummy error")
 case http.StatusServiceUnavailable:
 return nil, errors.New(BrokerError503)
 case http.StatusBadRequest:
 }}}

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

Re: [tor-bugs] #12802 [Circumvention/BridgeDB]: BridgeDB needs Nagios checks for the Email Distributor

2020-04-02 Thread Tor Bug Tracker & Wiki
#12802: BridgeDB needs Nagios checks for the Email Distributor
-+-
 Reporter:  isis |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-email, nagios, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #30152   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

 * owner:  (none) => phw
 * status:  needs_information => assigned


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

Re: [tor-bugs] #32740 [Circumvention/BridgeDB]: Implement a feedback loop between BridgeDB and OONI

2020-04-02 Thread Tor Bug Tracker & Wiki
#32740: Implement a feedback loop between BridgeDB and OONI
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s30-o23a2, anti-censorship-roadmap-  |  Actual Points:
  2020Q1 |
Parent ID:  #31280   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

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


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

Re: [tor-bugs] #31422 [Circumvention/BridgeDB]: Make BridgeDB report internal metrics

2020-04-02 Thread Tor Bug Tracker & Wiki
#31422: Make BridgeDB report internal metrics
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics, s30-o21a1, anti-|  Actual Points:
  censorship-roadmap-2020Q1  |
Parent ID:  #31274   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by phw):

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


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

Re: [tor-bugs] #13727 [Circumvention/BridgeDB]: BridgeDB should not distribute Tor Browser's default bridges

2020-04-02 Thread Tor Bug Tracker & Wiki
#13727: BridgeDB should not distribute Tor Browser's default bridges
-+-
 Reporter:  isis |  Owner:  phw
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb-dist, tbb-bridges, anti-|  Actual Points:
  censorship-roadmap-2020Q1 , s30-o23a1  |
Parent ID:  #31280   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

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


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

Re: [tor-bugs] #33666 [Circumvention/Snowflake]: Investigate Snowflake proxy failures

2020-04-02 Thread Tor Bug Tracker & Wiki
#33666: Investigate Snowflake proxy failures
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 My first thought here was to use a slight variation of #32938 to do a
 simpler probe that just tests the ability to open a datachannel. This
 could function similar to the probe test of the bridge added in #31391.

 My hesitancy for relying on this in the same way that we rely on the
 bridge is that it adds another single point of failure. If for some reason
 this probe test stops working, we will lose all of our proxies. I suppose
 the same is true for the broker or the bridge: if any of these stop
 working, snowflake essentially stops. But this increases the attack
 surface a bit.

 Obviously it's preferable to actually find out what is causing such a high
 failure rate in proxies and use that to inform what we do. Another thought
 I has was that if STUN is never successfully completing, the proxies will
 end up timing out ([https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/proxy/snowflake.js?id=ea01bf41c3011590938b079ed96c7b35cb40588b#n76
 here] and [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy-
 go/snowflake.go?id=ea01bf41c3011590938b079ed96c7b35cb40588b#n406 here])
 because the datachannel was never opened. We could do one of several
 things if a proxy reaches this state:
 1. log debug information and encourage the owner through the UI to file a
 Tor ticket with the log messages so we can figure out what's going on,
 2. keep track of how many times this happens, and if it always happens
 (the proxy sees no successful connections) disable the proxy and print out
 some debug messages,
 3. do a probe test only when the datachannel fails to open to check
 whether the proxy can open a datachannel with the probe point.

 These aren't necessarily mutually exclusive. Option (2) provides a vector
 for attack where an adversarial client can make a bunch of connections
 through proxies and simply never open a datachannel. Hopefully as long as
 honest client traffic is significantly higher than adversarial traffic,
 the proxy will see some successes and not trigger the disable condition.
 In any case, I think encouraging proxy owners to file a ticket if it
 happens too much is a good way to go here.

 Again, these techniques will only help against honest proxies that are
 trying their best but aren't helping users. I think that's the case for at
 least most of the proxies here because of the geographic distribution of
 failed snowflakes.

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

Re: [tor-bugs] #33716 [Metrics/Cloud]: Create user accounts for Metrics Team and add SSH keys

2020-04-02 Thread Tor Bug Tracker & Wiki
#33716: Create user accounts for Metrics Team and add SSH keys
---+
 Reporter:  irl|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #33715 | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Still waiting for karsten's SSH key, but this is done.

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

Re: [tor-bugs] #33717 [Metrics/Cloud]: Define metrics-common group vars to replace exit-scanner-sys role (was: Restore exit-scanner-sys role)

2020-04-02 Thread Tor Bug Tracker & Wiki
#33717: Define metrics-common group vars to replace exit-scanner-sys role
---+--
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * owner:  metrics-team => irl
 * status:  new => accepted


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

Re: [tor-bugs] #33785 [Internal Services/Tor Sysadmin Team]: cannot create new machines in ganeti cluster

2020-04-02 Thread Tor Bug Tracker & Wiki
#33785: cannot create new machines in ganeti cluster
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 some feedback from a ganeti maintainer:

 {{{
 03:40:48  failure reasons: FailMem: 1, FailN1: 4
 03:41:18  part indicates that there's no N+1 redundancy, probably
 due to not enough memory being available on the cluster to accommodate it
 03:42:05  You can try a manual allocation, or passing flags like
 --ignore-soft-errors and --no-capacity-checks to hail
 [...]
 10:36:12  I doubt rebalancing will fix it
 10:36:31  The thing is, the whole htools logic was built around
 Xen which does hard commit on memory
 [...]
 10:37:08  That's the -14GB of RAm you're seeing
 10:37:11  so what you're saying is that i *am* effectively using
 too much memory
 10:37:13  oh weird
 10:37:24  like the memory use from /proc doesn't match what
 ganeti expects?
 10:37:28  no, I'm saying you're using less memory than Ganeti
 thinks
 10:37:34  exactly
 10:37:41  because KVMs VSZ != RSS
 [...]
 10:38:17  Let's say it computes the worst-case scenario
 10:38:46  And in the worst-case scenario, where each instance
 will indeed use all of its configured memory and KSM won't save you, you
 don't have N+1
 10:39:08  As for the 162GB of disk, these are probably your root
 LVs, if they live on the same LVM VG as the Ganeti instance disks
 10:39:39  well there's also a secondary VG (vg_ganeti_hdd) for
 spinning rust that we don't see in gnt-node-list
 10:39:48  i wonder if that's related
 10:39:52  nope
 10:40:08  If your primary VG has anything else than Ganeti VMs on
 it, you'll see that message
 10:40:20  darn
 10:40:27  so i'd need to rebuild my nodes to fix this
 10:40:34  the good news is, you can tell ganeti to ignore
 specific LVs using gnt-cluster modify --reserved-lvs
 10:40:41  oh cool
 10:41:19  so i'd ignore what... vg_ganeti/root and
 vg_ganeti/swap i guess
 10:41:29  I guess
 10:41:50  The option --reserved-lvs specifies a list (comma-
 separated) of logical volume group names (regular expressions) that will
 be ignored by the
cluster verify operation
 10:41:53  i alreayd have   lvm reserved volumes: vg_ganeti/root,
 vg_ganeti/swap
 10:42:19  oh but maybe i have extra LVs on those nodes, that's
 true
 10:43:47  on fsn-node-03 and fsn-node-05, but not fsn-node-04
 }}}

 they also noted [https://github.com/ganeti/ganeti/issues/1399 upstream
 issue 1399] which is that the Sinst field is incorrect in `gnt-node list`.

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

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

2020-04-02 Thread Tor Bug Tracker & Wiki
#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  asn
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => 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] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

2020-04-02 Thread Tor Bug Tracker & Wiki
#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  asn
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-
Changes (by dgoulet):

 * owner:  (none) => asn
 * status:  needs_review => assigned


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

Re: [tor-bugs] #33761 [Applications/Tor Browser]: Remove unnecessary dependencies of Snowflake from Tor Browser

2020-04-02 Thread Tor Bug Tracker & Wiki
#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
---+---
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam202004R, tbb-9.5a10  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by sysrqb):

 * keywords:  TorBrowserTeam202004R => TorBrowserTeam202004R, tbb-9.5a10


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

Re: [tor-bugs] #30638 [Core Tor/Tor]: Test banning ed25519 keys in the approved-routers file on moria1

2020-04-02 Thread Tor Bug Tracker & Wiki
#30638: Test banning ed25519 keys in the approved-routers file on moria1
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, 042-deferred-20190918   |  Actual Points:
  043-should, network-health |
Parent ID:   | Points:  1
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 This depends on moria1 operator, arma, and arma's schedule is quantum so
 we shouldn't block 043 on this.

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

Re: [tor-bugs] #33545 [Core Tor/Tor]: assertion failure when "all zero" client auth key provided

2020-04-02 Thread Tor Bug Tracker & Wiki
#33545: assertion failure when "all zero" client auth key provided
-+-
 Reporter:  mcs  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.4.0-alpha-
 |  dev
 Severity:  Normal   | Resolution:
 Keywords:  043-must security|  Actual Points:  0.2
  extra-review   |
Parent ID:   | Points:
 Reviewer:  dgoulet, nickm   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  reopened => 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] #33686 [Core Tor/Tor]: Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled

2020-04-02 Thread Tor Bug Tracker & Wiki
#33686: Tor 0.4.2.7 wont get past bootstrap phase with Sandbox 1 enabled
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * milestone:   => Tor: 0.4.4.x-final


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

Re: [tor-bugs] #33742 [Core Tor/Tor]: Add information about design paper and anonbib inside README.1st

2020-04-02 Thread Tor Bug Tracker & Wiki
#33742: Add information about design paper and anonbib inside README.1st
--+
 Reporter:  bduszel   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * milestone:   => Tor: 0.4.4.x-final


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

Re: [tor-bugs] #33741 [Core Tor/Tor]: Format code blocks inside markdown files (documentation)

2020-04-02 Thread Tor Bug Tracker & Wiki
#33741: Format code blocks inside markdown files (documentation)
--+
 Reporter:  bduszel   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * milestone:   => Tor: 0.4.4.x-final


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

Re: [tor-bugs] #33782 [Core Tor/Tor]: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions

2020-04-02 Thread Tor Bug Tracker & Wiki
#33782: Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions
--+
 Reporter:  ultimaweapon  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:   => tor-test
 * milestone:   => Tor: 0.4.4.x-final


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

Re: [tor-bugs] #33794 [Core Tor/Tor]: hs-v3: OnionBalance backend instances all fail after more introductions by hitting descriptor upload time limits

2020-04-02 Thread Tor Bug Tracker & Wiki
#33794: hs-v3: OnionBalance backend instances all fail after more introductions 
by
hitting descriptor upload time limits
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, onionbalance  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information
 * milestone:   => Tor: 0.4.4.x-final


Comment:

 I don't think your instances had the #33762 fix because the stacktrace
 would have been:

 {{{
 BUG(!service->state.ob_subcreds)
 }}}

 Notice the `state.` there. Where yours is: `!service->ob_subcreds`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33797 [Core Tor/sbws]: Provide better logging for unit test runs in sbws

2020-04-02 Thread Tor Bug Tracker & Wiki
#33797: Provide better logging for unit test runs in sbws
---+
 Reporter:  gk |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 When I tried to figure out why my patch for #33009 did suddenly stall some
 unit test I got confused as I assumed all the log statements in the code
 would be shown during the test run. That is I thought I could be sure that
 logging output not shown meant the code paths were not touched. I was
 wrong.

 Even though some DEBUG logs are shown during the test run this does not
 hold for every DEBUG log (the former are available thanks to `caplog`
 fixture in some tests).

 I think it is worth getting this confusion fixed e.g. by providing an easy
 knob to tune the debug output for tests to the needs of the dev. One thing
 juga pointed out to me is creating a `pytest.ini` file in the root of the
 project containing something like
 {{{
 [pytest]
 log_cli=true
 log_cli_level=DEBUG
 }}}
 which would show debug output for all tests.

 Additionally, we should write some documentation explaining these things.

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

Re: [tor-bugs] #33761 [Applications/Tor Browser]: Remove unnecessary dependencies of Snowflake from Tor Browser

2020-04-02 Thread Tor Bug Tracker & Wiki
#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
--+--
 Reporter:  cohosh|  Owner:  (none)
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202004R |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => TorBrowserTeam202004R


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

Re: [tor-bugs] #33761 [Applications/Tor Browser]: Remove unnecessary dependencies of Snowflake from Tor Browser

2020-04-02 Thread Tor Bug Tracker & Wiki
#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
--+-
 Reporter:  cohosh|  Owner:  (none)
 Type:  task  | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+-
Changes (by cohosh):

 * cc: sysrqb (added)
 * component:  Circumvention/Snowflake => Applications/Tor Browser


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

Re: [tor-bugs] #33761 [Applications/Tor Browser]: Remove unnecessary dependencies of Snowflake from Tor Browser

2020-04-02 Thread Tor Bug Tracker & Wiki
#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
--+--
 Reporter:  cohosh|  Owner:  (none)
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by cohosh):

 * status:  merge_ready => 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] #33504 [Webpages/Support]: Metrics Q

2020-04-02 Thread Tor Bug Tracker & Wiki
#33504: Metrics Q
--+
 Reporter:  ggus  |  Owner:  hiro
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  docshackathon, documentation  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ggus):

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


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

[tor-bugs] #33796 [Core Tor/Tor]: socks: Prefer IPv6 by default on SOCKS port broke torsocks

2020-04-02 Thread Tor Bug Tracker & Wiki
#33796: socks: Prefer IPv6 by default on SOCKS port broke torsocks
--+---
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-dns torsocks ipv6
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 In commit `bf2a399fc0d90df76e091fa3259f7c1b8fb87781` we made all SocksPort
 to prefer IPv6 which means that any DNS resolution answer will pick IPv6,
 if exists, over IPv4.

 For torsocks, this is a problem because by default it tries to resolve an
 IPv4. This can be fixed _except_ when the libc call (ex: `getaddrinfo()`)
 is specifically requesting an IPv4 (`hints.ai_family = AF_INET`).

 There is currently no way for torsocks to ask tor, via the SocksPort, a
 specific INET family and thus torsocks receives back the IPv6 and can't
 handle it because the application was expecting an IPv4.

 So this example fails often as we have more and more Exits are able to
 resolve IPv6:

 {{{
 wget -4 some.url
 }}}

 And still many applications by default will request an IPv4 because they
 don't handle IPv6.

 Bottom line is that torsocks use case is broken for when an application is
 specifically requesting an INET family...

 As a reminder, torsocks can _not_ pass the hostname directly in the SOCKS
 connection because it hijacks libc calls and thus flow can only be 1) DNS
 resolution, 2) `connect()` with an IP address.

 I'm not sure what to do here... I think the ideal scenario would be to
 have a way for our "resolve" SOCKS extension to specify an address family
 value.

 For instance, the `F0` (`RESOLVE` command) would be "return whatever" and
 then we could extend to have `RESOLVE4` and `RESOLVE6`. HACK-ish but
 those extensions are already a hack so...

 (That prefer IPv6 change went in 043)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33795 [Core Tor]: Connection Failed

2020-04-02 Thread Tor Bug Tracker & Wiki
#33795: Connection Failed
-+--
 Reporter:  Hezmana  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 4/2/20, 12:20:23.367 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 4/2/20, 12:20:23.367 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 4/2/20, 12:20:23.367 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 4/2/20, 12:20:23.367 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 4/2/20, 12:20:23.367 [NOTICE] Opened Socks listener on 127.0.0.1:9150
 4/2/20, 12:20:24.301 [NOTICE] Bootstrapped 5% (conn): Connecting to a
 relay
 4/2/20, 12:20:24.306 [NOTICE] Bootstrapped 10% (conn_done): Connected to a
 relay
 4/2/20, 12:20:44.382 [WARN] Problem bootstrapping. Stuck at 10%
 (conn_done): Connected to a relay. (DONE; DONE; count 10; recommendation
 warn; host 3D98A374E963683B4E8D99C985FB9DCFD6EA7AA0 at 94.16.114.153:9001)
 4/2/20, 12:20:44.382 [WARN] 10 connections have failed:
 4/2/20, 12:20:44.382 [WARN] 10 connections died in state handshaking (TLS)
 with SSL state SSLv3/TLS write client hello in HANDSHAKE
 4/2/20, 12:20:44.386 [NOTICE] Closing no-longer-configured Socks listener
 on 127.0.0.1:9150
 4/2/20, 12:20:44.386 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 4/2/20, 12:20:45.330 [NOTICE] Delaying directory fetches: DisableNetwork
 is set.

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

Re: [tor-bugs] #33010 [Metrics/Ideas]: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a cloudflare-hosted static site

2020-04-02 Thread Tor Bug Tracker & Wiki
#33010: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a
cloudflare-hosted static site
---+--
 Reporter:  arma   |  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health gsoc-ideas  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:18 cypherpunks]:
 > Replying to [comment:17 woswos]:

 > But did you notice cloudflare seems to have changed captcha provider
 from recaptcha to ?

 Yes, to hcaptcha.com.

 Here you can see a cloudflared website, that does deliver all of the time
 a captcha to user and of course this have changed from recaptcha to
 hcaptcha too so you can see the difference directly as example site look
 at:

 [https://captcha.website/]


 This means, you should even expect more captchas delivered to users.
 Because now it is a busyness model, (get webmaster to use "free"
 cloudflare service and present users money rewarded captchas) with every
 captcha presented :



 {{{
 runs on the Ethereum blockchain. Websites earn Human Tokens (HMT)
 whenever users use the hCaptcha widget on their site,
 and machine learning companies pay Human Tokens to get their data labeled.

 The Value in Data Labeling
 When you use hCaptcha, companies bid on the work your users do as they
 prove their humanity.
 You get the rewards.
 }}}
 source: hcaptcha.com

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

Re: [tor-bugs] #24941 [Metrics/Website]: Add first and last months to CollecTor's Available Descriptors table

2020-04-02 Thread Tor Bug Tracker & Wiki
#24941: Add first and last months to CollecTor's Available Descriptors table
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:  0.3
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => closed
 * resolution:   => implemented
 * actualpoints:   => 0.3


Comment:

 Not a Friday afternoon, but a Thursday morning. Implemented and deployed.
 No need to block for a review, it's just processing more fields from
 CollecTor's `index.json` and displaying them. Closing.

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

Re: [tor-bugs] #33794 [Core Tor/Tor]: hs-v3: OnionBalance backend instances all fail after more introductions by hitting descriptor upload time limits

2020-04-02 Thread Tor Bug Tracker & Wiki
#33794: hs-v3: OnionBalance backend instances all fail after more introductions 
by
hitting descriptor upload time limits
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, onionbalance  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by s7r):

 Because of the size of the log files I am uploading them somewhere and
 sending to asn by email the link to download.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33794 [Core Tor/Tor]: hs-v3: OnionBalance backend instances all fail after more introductions by hitting descriptor upload time limits

2020-04-02 Thread Tor Bug Tracker & Wiki
#33794: hs-v3: OnionBalance backend instances all fail after more introductions 
by
hitting descriptor upload time limits
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.4.0-alpha-dev
 Severity:  Normal|   Keywords:  tor-hs, onionbalance
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We fixed #33762 and thought that was the problem (which it also was) but
 after fixing that I have discovered that all onionbalance backend
 instances continue to die after testing and testing (establishing
 successful RP circuits with the frontend) and never heal unless Tor
 processes of the backends are restarted.

 I was instructed by asn on IRC to look between the time of SIGHUP
 (logrotate log file change) and time of:

 {{{
 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_circuit.c:987:
 get_subcredential_for_handling_intro2_cell: Non-fatal assertion
 !(!service->ob_subcreds) failed. (on Tor 0.4.4.0-alpha-dev )
 }}}

 for the message
 {{{
 log_info(LD_REND, "Hidden service %s next descriptor successfully "
   "built. Now scheduled for upload.",
 }}}

 Which meant that it eventually recovered by itself. I can see two of those
 messages in ~24 hours, but the backend instances continue to be
 unavailable. Frontend does not work, and even if you try to connect to the
 backend address directly instead of the frontend one it does not work.

 It looks like it is never able to upload further descriptors at some
 point, flooding the log file with:

 {{{
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its current
 descriptor: Next upload time is 1585751537, it is now 1585748071. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its next
 descriptor: Next upload time is 1585751987, it is now 1585748071. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its current
 descriptor: Next upload time is 1585751537, it is now 1585748671. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its next
 descriptor: Next upload time is 1585751987, it is now 1585748671. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its current
 descriptor: Next upload time is 1585751537, it is now 1585749271. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its next
 descriptor: Next upload time is 1585751987, it is now 1585749271. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its current
 descriptor: Next upload time is 1585751537, it is now 1585749871. [598
 similar message(s) suppressed in last 600 seconds]
 [info] log_cant_upload_desc(): Service [scrubbed] can't upload its next
 descriptor: Next upload time is 1585751987, it is now 1585749871. [598
 similar message(s) suppressed in last 600 seconds]
 }}}

 I have info log level files from 2 backend instances of like ~47 MB each.

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

Re: [tor-bugs] #33793 [Core Tor/Chutney]: Avoid some race conditions when running chutney networks in series

2020-04-02 Thread Tor Bug Tracker & Wiki
#33793: Avoid some race conditions when running chutney networks in series
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop311   |  Actual Points:  0.3
Parent ID:  #33050| Points:  0.3
 Reviewer:  ahf   |Sponsor:  Sponsor55-must
--+
Changes (by teor):

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


Comment:

 See my PR:
 * chutney: https://github.com/torproject/chutney/pull/63

 I'm going to run it for a while before merging, the timings might need a
 bit of tuning.

 This review isn't urgent or important.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33793 [Core Tor/Chutney]: Avoid some race conditions when running chutney networks in series

2020-04-02 Thread Tor Bug Tracker & Wiki
#33793: Avoid some race conditions when running chutney networks in series
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  prop311
Actual Points:  0.3   |  Parent ID:  #33050
   Points:  0.3   |   Reviewer:
  Sponsor:  Sponsor55-must|
--+--
 When chutney runs multiple networks, one after the others, sometimes older
 tor instances are left running.

 To avoid these issues, chutney can:
 * wait longer after terminating tor processes
 * cleanup pid files, so we don't accidentally terminate unrelated
 processes

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

Re: [tor-bugs] #28005 [Applications/Tor Browser]: Officially support onions in HTTPS-Everywhere

2020-04-02 Thread Tor Bug Tracker & Wiki
#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, https-everywhere, network-   |  Actual Points:  18.5
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, ux-team, TorBrowserTeam202004R |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 > In any case, the current patch correctly adds .tor.onion as a new eTLD,
 however maybe it should go further and add securedrop.tor.onion as an eTLD
 because all sub-domains of securedrop.tor.onion are distinct origins. To
 make this explicit, currently www.abc.net.au.securedrop.tor.onion has
 (potentially) the same "origin" as www.2600.com.securedrop.tor.onion
 because they share the same eTLD (.tor.onion).
 I forgot addressing this. However, note the eTLD+1 is highlighted in the
 urlbar, so adding `securedrop.tor.onion` does make a UX change in the
 urlbar. For example, with that change for
 `www.nytimes.com.securedrop.tor.onion` we will highlight
 `com.securedrop.tor.onion` (instead of `securedrop.tor.onion` with the
 current patch). But perhaps it's still the right thing to do, and this
 issue is just a consequence of how the SecureDrop rules were defined.

 In any case, this patch adds the securedrop.tor.onion eTLD:
 https://github.com/acatarineu/tor-browser/commit/28005+8

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

Re: [tor-bugs] #33615 [Core Tor/Chutney]: Wait for at least 60 seconds for 0.3.5 and earlier to bootstrap

2020-04-02 Thread Tor Bug Tracker & Wiki
#33615: Wait for at least 60 seconds for 0.3.5 and earlier to bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, prop311, tor-ci-fail-  |  Actual Points:  0.5
  sometimes, network-team-roadmap-2020Q1 |
Parent ID:  #33050   | Points:  0.2
 Reviewer:  ahf  |Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

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


Comment:

 This ticket has been working in master for 2 weeks.
 It's still pending review, but that's not a high priority, so I'm just
 going to close 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] #33787 [Community]: T-shirts for volunteers should be substituted, or supplemented, with socks

2020-04-02 Thread Tor Bug Tracker & Wiki
#33787: T-shirts for volunteers should be substituted, or supplemented, with 
socks
-+--
 Reporter:  um   |  Owner:  ggus
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:
Component:  Community|Version:  Tor: unspecified
 Severity:  Trivial  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Old description:

> The community team should consider awarding volunteers with socks instead
> of t-shirts. Socks are much better for at least 3 reasons:
> 1. They are a symbolic reference to SOCKS (obviously)
> 2. They can be worn in a much more clandestine fashion, which corresponds
> to the way Tor users browse the internet
> 3. They are smaller, so easier to transport (and cheaper)
>
> They could be provided in various colour, like t-shirts are now - classic
> black, Tor green and Tor purple, all with Tor onion logo, would be solid
> choices.
>
> I suggest providing them in sets of two pairs (4 individual sock pieces)
> to represent SOCKS4a. Better yet, they could be provided as 5 individual
> sock pieces in order to represent SOCKS5 and as a workaround to the
> common and dreaded missing sock problem. It could also be considered to
> provide them as three pairs (6 individual sock pieces, possibly each pair
> in different colour) in anticipation of a breakthrough in SOCKS
> technology and the introduction of SOCKS6.

New description:

 Note: this ticket was created on April 1, it's probably a joke

 The community team should consider awarding volunteers with socks instead
 of t-shirts. Socks are much better for at least 3 reasons:
 1. They are a symbolic reference to SOCKS (obviously)
 2. They can be worn in a much more clandestine fashion, which corresponds
 to the way Tor users browse the internet
 3. They are smaller, so easier to transport (and cheaper)

 They could be provided in various colour, like t-shirts are now - classic
 black, Tor green and Tor purple, all with Tor onion logo, would be solid
 choices.

 I suggest providing them in sets of two pairs (4 individual sock pieces)
 to represent SOCKS4a. Better yet, they could be provided as 5 individual
 sock pieces in order to represent SOCKS5 and as a workaround to the common
 and dreaded missing sock problem. It could also be considered to provide
 them as three pairs (6 individual sock pieces, possibly each pair in
 different colour) in anticipation of a breakthrough in SOCKS technology
 and the introduction of SOCKS6.

--

Comment (by teor):

 Note: this ticket was created on April 1, it's probably a joke

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

Re: [tor-bugs] #33009 [Core Tor/sbws]: sbws bandwidth scans should require a minimum exit bandwidth

2020-04-02 Thread Tor Bug Tracker & Wiki
#33009: sbws bandwidth scans should require a minimum exit bandwidth
-+-
 Reporter:  teor |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, easy, intro,  |  Actual Points:  2.5
  sbws-roadmap   |
Parent ID:  #33121   | Points:  1
 Reviewer:  juga |Sponsor:
-+-
Changes (by gk):

 * owner:  (none) => gk
 * status:  needs_review => assigned


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

Re: [tor-bugs] #33009 [Core Tor/sbws]: sbws bandwidth scans should require a minimum exit bandwidth

2020-04-02 Thread Tor Bug Tracker & Wiki
#33009: sbws bandwidth scans should require a minimum exit bandwidth
-+-
 Reporter:  teor |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, easy, intro,  |  Actual Points:  2.5
  sbws-roadmap   |
Parent ID:  #33121   | Points:  1
 Reviewer:  juga |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => 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] #33009 [Core Tor/sbws]: sbws bandwidth scans should require a minimum exit bandwidth

2020-04-02 Thread Tor Bug Tracker & Wiki
#33009: sbws bandwidth scans should require a minimum exit bandwidth
-+-
 Reporter:  teor |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, easy, intro,  |  Actual Points:  2.5
  sbws-roadmap, GeorgKoppen202004|
Parent ID:  #33121   | Points:  1
 Reviewer:  juga |Sponsor:
-+-
Changes (by gk):

 * keywords:  sbws-majority-blocker, easy, intro, sbws-roadmap => sbws-
 majority-blocker, easy, intro, sbws-roadmap, GeorgKoppen202004


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

Re: [tor-bugs] #33009 [Core Tor/sbws]: sbws bandwidth scans should require a minimum exit bandwidth

2020-04-02 Thread Tor Bug Tracker & Wiki
#33009: sbws bandwidth scans should require a minimum exit bandwidth
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Normal   | Resolution:
 Keywords:  sbws-majority-blocker, easy, intro,  |  Actual Points:  2.5
  sbws-roadmap   |
Parent ID:  #33121   | Points:  1
 Reviewer:  juga |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * reviewer:   => juga
 * actualpoints:   => 2.5


Comment:

 `bug_33009_v5` in my public sbws repo has two patches for review (I've
 tried to create a merge request for `torproject/network-health/sbws
 maint-1.1` but failed so far; additionally the two patches are based on
 the branch for #30905 which needs revision, so maybe having a merge
 request does not make so much sense).

 That said, while having this up for review I am still thinking about some
 meaningful integration test but thought a lack of that is not a blocker
 for initial review at least. In particular, given that our current bw
 authorities situation might make this bug fix more urgent to get deployed.

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

Re: [tor-bugs] #33756 [Circumvention/Snowflake]: Hello, currently, in China, Tor Browser 9.5a8 still can't connect to Tor network through snowflake bridge.

2020-04-02 Thread Tor Bug Tracker & Wiki
#33756: Hello, currently, in China, Tor Browser 9.5a8 still can't connect to Tor
network through snowflake bridge.
-+---
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by amiableclarity2011):

 * Attachment "snowflake-client.2.log" 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] #33756 [Circumvention/Snowflake]: Hello, currently, in China, Tor Browser 9.5a8 still can't connect to Tor network through snowflake bridge.

2020-04-02 Thread Tor Bug Tracker & Wiki
#33756: Hello, currently, in China, Tor Browser 9.5a8 still can't connect to Tor
network through snowflake bridge.
-+---
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by amiableclarity2011):

 I upload my Tor-browser-snowflake-turbotunnel-quic-9.5a8-20200319
 snowflake client log file

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

Re: [tor-bugs] #25759 [Metrics/Website]: Create Ant task for fallback JSON

2020-04-02 Thread Tor Bug Tracker & Wiki
#25759: Create Ant task for fallback JSON
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Looks like we already did this in #33467. Closing as 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] #33784 [Core Tor/sbws]: Think about using `self._relays` in `_relays_with_flag()` and friends

2020-04-02 Thread Tor Bug Tracker & Wiki
#33784: Think about using `self._relays` in `_relays_with_flag()` and friends
---+
 Reporter:  gk |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Description changed by gk:

Old description:

> When we currently call `_relays_with_flag()` and friends the
> `self.relays` property might cause a refresh of relays. This works fine
> in general but is a) expensive and b) it causes hangs in unit tests in
> case one uses the property in without `freeze_time()` or even just
> instantiates a `RelayList`.
>
> We should think whether we can use `self._relays` instead. If not in
> every use case maybe it's possible to use it in some of those cases.

New description:

 When we currently call `_relays_with_flag()` and friends the `self.relays`
 property might cause a refresh of relays. This works fine in general but
 is a) expensive and b) it causes hangs in unit tests in case one uses the
 property without `freeze_time()` or even just instantiates a `RelayList`.

 We should think whether we can use `self._relays` instead. If not in every
 use case maybe it's possible to use it in some of those cases, though.

--

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

Re: [tor-bugs] #31866 [Metrics/CollecTor]: Generate tarballs in Java

2020-04-02 Thread Tor Bug Tracker & Wiki
#31866: Generate tarballs in Java
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

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


Comment:

 Closing as duplicate of #20350.

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

Re: [tor-bugs] #20350 [Metrics/CollecTor]: Replace create-tarball.sh shell script with Java module

2020-04-02 Thread Tor Bug Tracker & Wiki
#20350: Replace create-tarball.sh shell script with Java module
---+-
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  CollecTor 2.0.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Looks like we had two tickets for this issue. Here's what I wrote in
 #31866 which I'm now closing as duplicate:

 We're currently generating tarballs using the `tar` and `xz` command-line
 tools triggered by a cronjob. While this is very fast, it doesn't
 integrate that well with the rest of our code. For example, it would be
 much easier to extract descriptor types, publication times, and file
 digests for #31204 if tarball generation happened in Java.

 One possible issue might be that generated tarballs are larger or that
 compression takes longer. This is something I wanted to figure out early,
 which is why I ran some tests today:

 ||= Compression preset level == `xz` == XZ for Java 1.6 =||
 ||  1  || 269M || 1m27.522s || 269M || 1m22.905s ||
 ||  3  || 77M || 1m6.590s || 77M || 1m15.03s ||
 ||  6  || 30M || 3m8.426s || 30M || 4m54.837s ||
 ||  9  || 18M || 2m56.801s || 18M || 5m6.998s ||
 ||  9e  || 16M || 7m2.364s  NA ||

 We're currently using `xz -9e`, but I can't find this option in XZ for
 Java. The closest is compression preset level 9. That means that our
 tarballs would be 18M/16M = 12.5% larger and be created in
 306.998s/422.364s = 73% of the current time.

 Is it a blocker that our tarballs would be 12.5% larger? If so, we might
 try harder to configure XZ for Java in the same way as `xz -9e` operates,
 even though that would very likely increase tarball generation time.

 Not working on this at the moment, just leaving my thoughts here for
 discussion and for picking this up as time permits.

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

  1   2   >