Re: [tor-bugs] #33778 [Core Tor/Tor]: TestingTorNetwork options in the man page are out of date

[Tor Bug Tracker & Wiki]

#33778: TestingTorNetwork options in the man page are out of date
--+
 Reporter:  opara |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by opara):

 https://github.com/torproject/tor/pull/1850

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33778 [Core Tor/Tor]: TestingTorNetwork options in the man page are out of date

[Tor Bug Tracker & Wiki]

#33778: TestingTorNetwork options in the man page are out of date
+--
 Reporter:  opara   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 A few of the values under {{{TestingTorNetwork}}} in {{{doc/tor.1.txt}}}
 are out of date compared to the options in
 {{{src/app/config/testnet.inc}}}. Also, some of the units listed for
 options only state 'minutes|hours' when they actually support 'seconds' as
 well. I only fixed the ones that were relevant to {{{TestingTorNetwork}}},
 but there are probably others as well. Will add a PR shortly.

 In addition, many of the options that are of type {{{INTERVAL}}} use
 different units in the man page. For example:
 {{{
 ShutdownWaitLength NUM
 V3AuthVotingInterval N minutes|hours
 TestingV3AuthVotingStartOffset N seconds|minutes|hours
 DormantClientTimeout N minutes|hours|days|weeks
 }}}

 Since these are all of type {{{INTERVAL}}}, is there a reason why these
 units are different when all of them support any unit in {{{unitparse.c}}}
 (seconds, minutes, hours, days, weeks)? One reason could be that some
 options have lower bounds (for example {{{V3AuthVotingInterval}}} must be
 greater than 300 seconds which is of the order of minutes), but the user
 can just specify 300 seconds rather than 5 minutes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33777 [- Select a component]: Bogus Tor Version ?

[Tor Bug Tracker & Wiki]

#33777: Bogus Tor Version ?
+--
 Reporter:  cjggreen@…  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  - Select a component
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Hi - does the following log mean that my version of TOR is bogus and a
 third party is actually in control?  With thanks,

 4/1/20, 00:09:39.870 [NOTICE] Bootstrapped 10% (conn_done): Connected to a
 relay
 4/1/20, 00:09:39.606 [NOTICE] Bootstrapped 14% (handshake): Handshaking
 with a relay
 4/1/20, 00:09:40.835 [NOTICE] Bootstrapped 15% (handshake_done): Handshake
 with a relay done
 4/1/20, 00:09:40.835 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded
 enough directory info to build circuits
 4/1/20, 00:09:40.835 [NOTICE] Bootstrapped 90% (ap_handshake_done):
 Handshake finished with a relay to build circuits
 4/1/20, 00:09:40.836 [NOTICE] Bootstrapped 95% (circuit_create):
 Establishing a Tor circuit
 4/1/20, 00:09:42.494 [NOTICE] Bootstrapped 100% (done): Done
 4/1/20, 00:09:43.137 [NOTICE] New control connection opened from
 127.0.0.1.
 4/1/20, 00:09:43.419 [NOTICE] New control connection opened from
 127.0.0.1.
 4/1/20, 02:29:22.607 [NOTICE] Have tried resolving or connecting to
 address '[scrubbed]' at 3 different places. Giving up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 `browser/actors/ClickHandlerChild.jsm`

 Can you initialize `json.allowOnionUrlbarRewrites`:
 {{{
 json.allowOnionUrlbarRewrites = false;
 }}}

 so it follows the same pattern?

 `browser/base/content/browser.js`
 {{{
   if (gBrowser.selectedBrowser.allowOnionUrlbarRewrites) {
 gBrowser.selectedBrowser.currentOnionAliasURI =
 OnionAliasStore.getShortURI(
   gBrowser.selectedBrowser.currentURI
 );
 }}}
 Is `aLocationURI` equal to `gBrowser.selectedBrowser.currentURI` at this
 point?

 `docshell/base/nsDocShell.cpp`

 Should we have a pref that prevents `mAllowOnionUrlbarRewrites` being
 `true`?

 {{{
 if (NS_SUCCEEDED(oldURI->GetHost(oldHost)) &&
 StringEndsWith(oldHost, NS_LITERAL_CSTRING(".tor.onion")) &&
 NS_SUCCEEDED(newURI->GetHost(newHost)) &&
 StringEndsWith(newHost, NS_LITERAL_CSTRING(".onion")) &&
 !StringEndsWith(newHost, NS_LITERAL_CSTRING(".tor.onion"))) {
 }}}

 Is the "newHost ends with .onion" helpful here?

 (I'll finish reviewing this tomorrow, but so far it looks really good!
 Thanks!)

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

[tor-bugs] #33776 [Internal Services/Tor Sysadmin Team]: Please change email forwarding for jon@

[Tor Bug Tracker & Wiki]

#33776: Please change email forwarding for jon@
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Please forward jon@ to ewy...@torproject.org, effective April 1st. Jon is
 aware of this change. Thanks.
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAl6D9gAACgkQugyUAPgP
 kc71oxAAnCjtM6ppw1jhgcOoQS0LJqKSEMtKJpYGMYZQtQMLi6CDfiWI7sbjaYbB
 ws3TMOQL3j5DU3+/a6IIx7tTkQvCgkNV987la5SYJdPiFGxuKi+UTkdjaqBOv0Rp
 R2fUzD65BiWoETSnHhCvAgnOedu8vZkevh5FW3GHyRCxRuB0Nhh6SYcWyE3ggzE7
 CN/Gb8sze6byCpkTf+gj/FEH7Bn1UWpXvxGIEB4fGPZT0yBCabsmuEXNAJID8wrL
 JZeDCxngrQVNnlPyV1suYPxM42ItRNVeOTELJvG++IHrCOHI+EwEQK+RBZO64GQ+
 cgN8hPKdlCpJZO61oPEkvIosmYFQ44UUwFCETW+agGFkvENtgEhsLUD/7va8Pe/J
 LWzgH/I1GQOOofMBoD0d5bWF0zauI57n0gJn2coWee5BkC1VeK42c4DlcSpuorun
 u0abh1ozFIzMtfVgwK4gnby4mw4vCYkI0XxC7f/hwKPWzVdt88o9P+vbFX1k+01c
 Mc+7PoT9IjPZtDwxZkQAmNC6+GQD077Fnlb1oGcyiRchQ5XD4uQqAfmFMA3Cq/bP
 Pz8HiRwJDIYaWBxZmdsj5fB70uxRtu/7smOCS/OjqrN+bHbkFMeog1hj+SO1Njgo
 uWaZoK5ThDaT12x5UtwvoXUWgU1nuCM5cZdBQEuS/IA1ZjD2Z7Q=
 =1Iwk
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Circumvention/Snowflake]: Remove unnecessary dependencies of Snowflake from Tor Browser

[Tor Bug Tracker & Wiki]

#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 By the way thanks for tracking this down.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Circumvention/Snowflake]: Remove unnecessary dependencies of Snowflake from Tor Browser

[Tor Bug Tracker & Wiki]

#33761: Remove unnecessary dependencies of Snowflake from Tor Browser
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 Is it necessary to patch the source? Or could we just remove the
 dependencies from projects/pion-webrtc/config and delete the projects? It
 seems to me that the quic parts of pion-webrtc are not built by default;
 all the involved files have a `+build quic`
 [https://golang.org/pkg/go/build/#hdr-Build_Constraints build constraint].
 In the [https://github.com/pion/webrtc/blob/v2.2.0/.travis.yml#L53
 upstream CI] they have to specifically pass `-tags quic` to `go build`.

 On the other hand, if in #28325 the Tor Browser team starts using go.mod
 files directly for dependency tracking (as we are kind of currently doing
 with the gomodtorbm script), then it makes sense to patch the source and
 get a new go.mod, as you've done.

 What tor-browser-build projects does it allow to be removed? My reckoning
 from a quick grep is pion-quic, quic-go, genny, ginkgo, gomega, gomock,
 qtls.

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

Re: [tor-bugs] #33534 [Applications/Tor Browser]: Review FF release notes from FF69 to latest (FF73)

[Tor Bug Tracker & Wiki]

#33534: Review FF release notes from FF69 to latest (FF73)
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  12
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+

Comment (by Thorin):

 Replying to [comment:8 pospeselr]:
 > dom.push.enabled
 > - set to false to disable push notifications

 Default false in ESR68. I also think it's not enabled/doesn't do anything
 in PB mode, since it requires service workers which are also disabled (see
 next comment)

 However, disabling SWs (pref below) and push (pref above) is not enough to
 stop Firefox polling the Mozilla Push Server - which assigns a persistent
 ID
 - see `dom.push.userAgentID` (without testing, I am not sure if this still
 gets sets when started in PB mode)
 - you could blank 'dom.push.serverURL' for good measure

 > dom.serviceWorkers.enabled
 > - set to false to disable service workers

 This isn't new. It's default false in ESR60-68 and service workers are not
 available in PB mode

 > security.insecure_connection_icon.enabled
 > - when true shows crossed out padlock on HTTP sites ->
 https://www.askvg.com/firefox-tip-show-hide-insecure-connection-icon-in-
 address-bar/

 Just FYI: if this is true, then both normal and PB modes display the
 padlock, but if false, then the pref
 `security.insecure_connection_icon.pbmode.enabled` is used in PB mode.
 They are currently both default false in ESR68, true in non ESR

 > security.tls.version.enable-deprecated
 > - we probably want this to be false to disable old TLS

 Setting to false still allows downgrading, but makes that downgrading
 **session only**. To force TLS 1.0 and 1.1 permanently disabled, just set
  - `security.tls.version.min` = 3
  -  ^^ 3 was the default in FF74 but got reversed due to govt websites
 using TLS <1.2
  - no idea what it will be in ESR78 stable

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

Re: [tor-bugs] #33633 [Core Tor/Tor]: Move extend and reachability code to the relay module

[Tor Bug Tracker & Wiki]

#33633: Move extend and reachability code to the relay module
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, prop311, technical-debt,   |  Actual Points:  1.0
  network-team-roadmap-2020Q1|
Parent ID:  #33220   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-must
-+-

Comment (by teor):

 (I fixed a linking issue in my PR, when relay mode was disabled.)

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

Re: [tor-bugs] #33618 [Core Tor/Tor]: Add IPv6 Support to is_local_addr()

[Tor Bug Tracker & Wiki]

#33618: Add IPv6 Support to is_local_addr()
--+
 Reporter:  kimimaro  |  Owner:  kimimaro
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  outreachy-ipv6 ipv6  prop312  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:  teor  |Sponsor:  Sponsor55-can
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 There were some bugs in the new code, that were a bit tricky to fix.

 So I made a new pull request, and added some changes:
 https://github.com/torproject/tor/pull/1849#issuecomment-606973738

 I also fixed some bugs in our old tests, that were making it harder to
 write this code.

 Can you try writing unit tests now?

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

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

[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
>  * [ ] rude.torproject.org (RT) - test server ready at `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`
  * [ ] 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).

--

Comment (by anarcat):

 rude migration in progress.

 TTLs lowered at 22:51UTC.

 renumbering:

 {{{
 --- /mnt/etc/network/interfaces.bak 2016-09-01 18:17:33.302001995
 +
 +++ /mnt/etc/network/interfaces 2020-03-31 23:59:06.952570913 +
 @@ -1,14 +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.230/28
 -gateway 138.201.212.225
 +address 116.202.120.187/27
 +gateway 116.202.120.161
  iface eth0 inet6 static
  accept_ra 0
 -address 2a01:4f8:172:39ca:0:dad3:6:1/96
 -gateway 2a01:4f8:172:39ca:0:dad3:0:1
 +address 2a01:4f8:fff0:4f:266:37ff:fee0:8604/64
 +gateway 2a01:4f8:fff0:4f::1
 }}}

 LDAP, nagios, and /etc on rude IP changes done.

 it should be done.

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

Re: [tor-bugs] #33768 [Core Tor/Tor]: Make tor_inet_pton() handle bad addresses consistently on Windows

[Tor Bug Tracker & Wiki]

#33768: Make tor_inet_pton() handle bad addresses consistently on Windows
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  044-should, security-low,|  Actual Points:
  035-backport, 041-backport, 042-backport,  |
  043-backport, outreachy-ipv6, ipv6, windows|
Parent ID:  #33049   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * sponsor:  Sponsor55-can => Sponsor55-must
 * parent:   => #33049


Comment:

 This might be a security issue on Windows relays, if they are getting IPv6
 addresses from untrusted sources.

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

Re: [tor-bugs] #33679 [Core Tor/Tor]: Make sure every address function that takes for_listening supports IPv6

[Tor Bug Tracker & Wiki]

#33679: Make sure every address function that takes for_listening supports IPv6
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  extra-review, prop312, ipv6, |  Actual Points:  0.3
  outreachy-ipv6, network-team-roadmap-2020Q1|
Parent ID:  #33049   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor55-must
-+-
Changes (by teor):

 * keywords:  prop312, ipv6, outreachy-ipv6, network-team-roadmap-2020Q1 =>
 extra-review, prop312, ipv6, outreachy-ipv6, network-team-roadmap-
 2020Q1
 * reviewer:  teor =>
 * actualpoints:   => 0.3


Comment:

 Now that we have unit tests, it is easier to simplify the function a bit
 more:
 https://github.com/torproject/tor/pull/1848

 I think the check for the 0.0.0.0 IPv4 address was redundant.

 I added this commit, what do you think?
 
https://github.com/torproject/tor/pull/1848/commits/ba68603d648d28d22e89acf1be8ea3c590836daf

 Now that the pull request is finished, someone else will review it, then
 it will be merged. That should take about a week or so.

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

Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

[Tor Bug Tracker & Wiki]

#33617: Add a BandwidthStatistics option and consensus parameter
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop313, ipv6, outreachy-ipv6,   |  Actual Points:
  network-team-roadmap-2020Q1|
Parent ID:  #33052   | Points:  1
 Reviewer:  teor |Sponsor:
 |  Sponsor55-can
-+-

Comment (by teor):

 Replying to [comment:18 teor]:
 > Replying to [comment:16 MrSquanchee]:
 > > I think, I can use this
 [https://github.com/torproject/tor/blob/master/src/test/test_bwmgt.c file]
 to test the added changes.
 > > What do you say ??
 >
 > Sounds like a great idea!
 >
 > > Also I added the changes requested.
 > > And I think when BandwidthStatistics is explicitly set to 1, it should
 not check the consensus as cited
 [https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-
 ipv6-stats.txt#n305. here] (indirectly).
 >
 > Thanks! We need to answer those questions in the comments and manual
 page.
 >
 > Writing comments and manuals can be hard.
 > Can you try one more time?
 > Try to use similar options as a template.
 >
 > If you're still having trouble, I can help rewrite them. But I might not
 have time this week.

 Hi MrSquanchee, just wondering how you are going with these tests and
 documentation?

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

Re: [tor-bugs] #32588 [Core Tor/Tor]: Setting ORPort [ipv6]:auto mistakenly advertises port 94

[Tor Bug Tracker & Wiki]

#32588: Setting ORPort [ipv6]:auto mistakenly advertises port 94
-+-
 Reporter:  arma |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.9-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-0435,|  Actual Points:  1.1
  043-should, ipv6, 035-backport, 041-backport,  |
  042-backport, 043-backport, network-team-  |
  roadmap-2020Q1 |
Parent ID:  #33048   | Points:  1
 Reviewer:  nickm, teor  |Sponsor:
 |  Sponsor55-must
-+-

Comment (by teor):

 Replying to [comment:44 teor]:
 > 0.4.1 and 0.4.2 failed on Travis, but they pass locally.
 >
 > And Travis is having a database downtime, so I can't check why. See:
 > https://www.traviscistatus.com/

 These errors appear to be Travis macOS hangs, due to #32804.

 I have restarted the relevant builds.

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

Re: [tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
-+-
 Reporter:  Vort |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  build, 043-must, 043-backport,   |  Actual Points:  0.1
  consider-backport-after-ci-passes  |
Parent ID:   | Points:  0.1
 Reviewer:  teor |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:5 teor]:
 > It was released in 0.4.3.2-alpha, and users noticed it, so it needs a
 changes file.

 Agreed. One of the points of a ChangeLog file is so we can go back and say
 "oh hey, you remember that thing we had with the automake bug? When was
 that?" and it's there.

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

Re: [tor-bugs] #33775 [Core Tor/sbws]: sbws measures some relays 100x lower than Torflow (was: sbws measures some relays 100x less than Torflow)

[Tor Bug Tracker & Wiki]

#33775: sbws measures some relays 100x lower than Torflow
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Major| Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: sbws does not detect changes in descriptor bandwidth values

[Tor Bug Tracker & Wiki]

#30733: sbws does not detect changes in descriptor bandwidth values
-+-
 Reporter:  starlight|  Owner:  juga
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:  fixed
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33121   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 I have opened ticket #33775, which is about low relay measurements from
 sbws (but not torflow). It could be related to this issue.

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

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

[Tor Bug Tracker & Wiki]

#33009: sbws bandwidth scans should require a minimum exit bandwidth
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 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:
  sbws-roadmap   |
Parent ID:  #33121   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I have opened ticket #33775, which is about low relay measurements from
 sbws (but not torflow). It could be related to this issue.

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

[tor-bugs] #33775 [Core Tor/sbws]: sbws measures some relays 100x less than Torflow

[Tor Bug Tracker & Wiki]

#33775: sbws measures some relays 100x less than Torflow
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  sbws: 1.1.x-final
Component:  Core |Version:
  Tor/sbws   |
 Severity:  Major|   Keywords:  sbws-majority-blocker, sbws-roadmap
Actual Points:   |  Parent ID:
   Points:  2|   Reviewer:
  Sponsor:   |
-+-
 Hi,

 I've received multiple reports from relay operators who are concerned
 their relays are being measured too low.

 At the moment, we only have 2 Torflow instances in the network, and 3 sbws
 instances. So bad sbws measurements can lower any relay's bandwidth,
 regardless of the Torflow measurement.

 Here is one report:
 https://lists.torproject.org/pipermail/tor-relays/2020-March/018321.html

 At the moment, the bandwidths are:

 moria1 494
 maatuska 4
 longclaw 5

 https://consensus-health.torproject.org/consensus-
 health-2020-03-31-21-00.html#6E1DA4C0B0C05FB721B42329C47A20DA22908AEB

 I have also received a similar report privately from a large relay
 operator.

 This bug could be related to #33009 or #30733.

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

Re: [tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
-+-
 Reporter:  Vort |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  build, 043-must, 043-backport,   |  Actual Points:  0.1
  consider-backport-after-ci-passes  |
Parent ID:   | Points:  0.1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * reviewer:   => teor


Comment:

 Replying to [comment:4 dgoulet]:
 > Ok... I had to find `m4_foreach_w` example online to discover that some
 special market needs to be added to the expanded variable even though
 without that it is expanded but doesn't work in the test!

 Sounds complicated!

 > See PR: https://github.com/torproject/tor/pull/1847

 I think we're using the wrong variables here, see the PR for details.

 > (I think this falls into the "too trivial" for a changes file...?)

 It was released in 0.4.3.2-alpha, and users noticed it, so it needs a
 changes file.

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

Re: [tor-bugs] #33534 [Applications/Tor Browser]: Review FF release notes from FF69 to latest (FF73)

[Tor Bug Tracker & Wiki]

#33534: Review FF release notes from FF69 to latest (FF73)
--+
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  12
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+

Comment (by pospeselr):

 Ok, diffed vanilla esr68 vs beta75 prefs in firefox.js and greprefs.js and
 here's the noteworthy new values:

 browser.aboutwelcome.enabled
 - this pref seems enable a one-time welcome screen that shows off
 firefox features and importing bookmarks and stuff
 browser.search.modernConfig
 - seems like mozilla working on a new system for configuring search
 engines, setting to false falls back to legacy
 browser.search.separatePrivateDefault
 - separete search engine config for private browsing mode, redundant
 for us since we're always in private browsing mode
 browser.ssb.enabled
 - site-specific browser (1602117) to launch websites in a window
 without browser UI
 browser.tabs.remote.separatedMozillaDomains
 - so this is a list of mozilla domains which are allowed to be loaded
 in a priviledged process, probably empty this list
 browser.urlbar.update1
 - new style for urlbar that sort of 'hovers' over the background when
 true
 device.storage.enabled
 - set to false to disable -> https://developer.mozilla.org/en-
 US/docs/Archive/B2G_OS/API/Device_Storage_API
 dom.push.enabled
 - set to false to disable push notifications
 dom.serviceWorkers.enabled
 - set to false to disable service workers
 extensions.experiments.enabled
 - enable to access experimental web extension APIs (suspect we want
 false) -> https://firefox-source-
 docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html
 #webextensions-experiments
 javascript.options.blinterp
 - enable the new experimental baseline interpeter ->
 https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-
 interpreter-in-firefox-70/
 marionette.enabled
 - enables the marionette remote access/testing thing, like Selenium ->
 https://firefox-source-docs.mozilla.org/testing/marionette/Intro.html
 media.autoplay.default
 - 0 => allow all, 1 => block audio, 5 => block audio+video (suspect we
 should disable all autoplay)
 media.videocontrols.picture-in-picture.enabled
 - enables the new picture-in-picture video viewer
 network.dns.skipTRR-when-parental-control-enabled
 - disable DoH when parental controls are enabled
 network.http.http3.enabled
 - enable http3 (seems http3 uses udp so I would guess we want to
 disable this) -> https://techdows.com/2019/11/mozilla-adds-http3-support-
 to-firefox-72-nightly.html
 permissions.fullscreen.allowed
 - when this is enabled permissions prompt will appear when ff is in
 full screen, when not it drops out of fullscreen (to avoid chrome spoofing
 we want this to be false)
 privacy.purge_trackers.enabled
 - purges cookies from tracking sites that have not been interacted
 with (we don't use tracking protection and we're in private browsing mode
 so this is not needed -> https://www.ghacks.net/2020/03/04/firefox-75
 -will-purge-site-data-if-associated-with-tracking-cookies/
 security.aboutcertificate.enabled
 - enables the new cert viewer (if we enable this, we need to port over
 our work adding in 'Onion Service' string to the security info of a page
 #23247)
 security.allow_eval_in_parent_process
 security.allow_eval_with_system_principal
 - these disable eval in certain contexts, ensure these are false ->
 https://bugzilla.mozilla.org/show_bug.cgi?id=1582512
 security.cert_pinning.hpkp.enabled
 - used to disable HPKP (HTTP Public Key Pinning) when false, pretty
 sure we want to keep it that way?
 security.enterprise_roots.enabled
 - lets firefox look to the OS for additional valid root CA issuers,
 set to false -> https://support.mozilla.org/en-US/kb/how-disable-
 enterprise-roots-preference
 security.identityblock.show_extended_validation
 - false in firefox, do we want to show the EV text?
 security.insecure_connection_icon.enabled
 - when true shows crossed out padlock on HTTP sites ->
 https://www.askvg.com/firefox-tip-show-hide-insecure-connection-icon-in-
 address-bar/
 security.osclientcerts.autoload
 - when true autoloads certs from OS cert store  (I assume we want this
 false) -> https://bugzilla.mozilla.org/show_bug.cgi?id=1592111
 security.pki.crlite_mode
 - when set to 2 this enables crlite, 0 disables, an offline cert
 revocation store -> 

[tor-bugs] #33774 [Applications]: Waiting for tor to start....

[Tor Bug Tracker & Wiki]

#33774: Waiting for tor to start
-+--
 Reporter:  rscottf1960  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Component:  Applications
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 I used to be able to connect with no problem. Now it stops with the
 "waiting for tor to start" message. When it finally fails, and I click the
 copy to clipboard option, it says 0 logs ready to be copied. I don't know
 what happened. This is the tor browser installer for windows listed on the
 web site.

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

Re: [tor-bugs] #33762 [Core Tor/Tor]: OnionService v3 running as onionbalance backend fails to reload failing with get_subcredential_for_handling_intro2_cell: Non-fatal assertion !(!service->ob_subcre

[Tor Bug Tracker & Wiki]

#33762: OnionService v3 running as onionbalance backend fails to reload failing
with get_subcredential_for_handling_intro2_cell: Non-fatal assertion
!(!service->ob_subcreds) failed.
--+
 Reporter:  s7r   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 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:  dgoulet, s7r  |Sponsor:
--+

Comment (by s7r):

 fix works. if the code also looks good to @dgoulet this can be merged -
 it's very important, otherwise log rotate systems that send SIGHUPs will
 make backend instances totally unavailable until they build their next
 descriptors. very bad.

 P.S.: is it a problem that it displays '''info''' prefixed log messages
 for the functions listed in the bottom of the ticket description?
 Shouldn't (at least) `ob_option_parse(): OnionBalance:
 MasterOnionAddress...` be '''notice''' level? This is a very important
 step for the operator to confirm that a particular backend instance has
 been able to register to its management server instance, and by
 '''notice''' is Tor's default log level.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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.3
  team-roadmap-november, network-team-roadmap-   |
  2020Q1, TorBrowserTeam202003R, ux-team |
Parent ID:  #30029   | Points:  20
 Reviewer:  mcs, sysrqb, antonela|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 acat and I were chatting about why the tor-browser patch uses a same-
 origin check (this check triggers a urlbar change when the user navigates
 from the current "aliased" site to a different .onion). However, we began
 thinking about how a same-origin check should be applied on .tor.onion
 domains. The same-origin check works because it uses the underlying
 `.onion` address for the current site and new site. Every .onion address
 is a separate origin, so the same-origin policy applies correctly. For the
 current patch, we should not need a same-origin policy for the .tor.onion
 aliases because they are only cosmetic. However, I expect in the future
 .tor.onion could be handled differently where a same-origin check should
 be evaluated correctly (as an example, maybe we populate the alt-svc cache
 mapping at startup instead of relying on https-everywhere rewriting).

 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`).

 Adding all new `*.tor.onion` scopes as new eTLDs doesn't scale very well
 (and it is a completely manual process and integrated in the browser at
 compile-time), so we should think about how we can improve this process,
 too. This also means that including arbitrary rulesets in the future could
 be a security risk (if/when `.tor.onion` is not simply a cosmetic UI
 layer). Currently, it is not a security risk.

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

Re: [tor-bugs] #33675 [Core Tor/Chutney]: Search microdescriptor files for relay ed25519 keys

[Tor Bug Tracker & Wiki]

#33675: Search microdescriptor files for relay ed25519 keys
---+---
 Reporter:  teor   |  Owner:  anuradha1904
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Chutney   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, prop311, outreachy-ipv6  |  Actual Points:  0.1
Parent ID:  #33428 | Points:  0.5
 Reviewer:  ahf|Sponsor:  Sponsor55-can
---+---

Comment (by teor):

 Replying to [comment:19 anuradha1904]:
 > Hey teor, can I ask alex the question regarding this ticket then? Thank
 you very much.

 Please ask your questions on the ticket, and someone will answer them :-)

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

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

[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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 acat and I briefly discussed the header format earlier. One piece of
 feedback reminded me that we should use X-Onion-Location, because we are
 not implementing a standardized HTTP header. However, acat pointed me to
 https://tools.ietf.org/html/rfc6648 where `X-*` headers are considered
 deprecated. So, we should think a little harder about the format of the
 value for this field. The `Location` HTTP header is
 [https://tools.ietf.org/html/rfc7231#page-68 defined] as:
 {{{

The "Location" header field is used in some responses to refer to a
specific resource in relation to the response.  The type of
relationship is defined by the combination of request method and
status code semantics.

  Location = URI-reference

The field value consists of a single URI-reference.  When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).

For 201 (Created) responses, the Location value refers to the primary
resource created by the request.  For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for
automatically redirecting the request.

If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the
URI reference used to generate the request target (i.e., the
redirection inherits the original reference's fragment, if any).

For example, a GET request generated for the URI reference
"http://www.example.org/~tim; might result in a 303 (See Other)
response containing the header field:

  Location: /People.html#tim

which suggests that the user agent redirect to
"http://www.example.org/People.html#tim;

Likewise, a GET request generated for the URI reference
"http://www.example.org/index.html#larry; might result in a 301
(Moved Permanently) response containing the header field:

  Location: http://www.example.net/index.html

which suggests that the user agent redirect to
"http://www.example.net/index.html#larry;, preserving the original
fragment identifier.
 }}}

 In the future, we may find it advantageous if we specify `Onion-Location`
 as a [https://httpwg.org/http-extensions/draft-ietf-httpbis-header-
 structure.html structured header] with a backwards compatible format
 matching that of the Location header.

 To be clear, we can use the current implementation and get this into
 Nightly builds, but we should think about this idea before the feature
 moves to Stable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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 catalyst):

 My rebase seems to have reverted part of
 6d03c0566568f4a56efb4aea2f32bcd86c090a22; I'll investigate whether that
 was git's fault or mine.

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

Re: [tor-bugs] #33771 [Applications/Tor Browser]: Missing LibEvent License

[Tor Bug Tracker & Wiki]

#33771: Missing LibEvent License
--+--
 Reporter:  sysrqb|  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:  boklm |Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:3 sysrqb]:
 > In any case, I'll open an upstream bug for updating the libevent license
 in Firefox.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1626380

 > We should include updated licenses for Tor Browser-specific
 components/libraries. gk mentioned we could add all of our unique licenses
 into `about:license`, as well, instead of bundling them in different text
 files in tor-browser-build. I'll open another ticket for that.

 #33773

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33773 [Applications/Tor Browser]: Add Tor Browser-specific licenses in about:license

[Tor Bug Tracker & Wiki]

#33773: Add Tor Browser-specific licenses in about:license
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam202006
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This idea came out of #33771 and #33772. GeKo mentioned that we don't need
 to ship a specific license for NSS because it is covered by
 `about:license`, and we could use `about:license` for the additional
 licenses we must ship, as well. Currently those Tor Browser-specific
 licenses are controlled by tor-browser-build and they are included as text
 files at build-time. Extending `about:license` is a good idea.

 The main disadvantage I see is downstream projects who take a tor browser
 package and re-use all of the tor parts but they don't use the browser. We
 could achieve this by continuing with adding licenses in text files and
 then patching them into tor-browser's `toolkit/content/license.html` at
 build time. I'm not very excited about the additional complexity this
 would require, 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] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by steph):

 No, I didn't, thank you!

 So I think this covers it:

 onionLocation.alwaysPrioritize=Always Prioritize Onions
 onionLocation.alwaysPrioritizeAccessKey=a
 onionLocation.notNow=Not Now
 onionLocation.notNowAccessKey=n
 onionLocation.description=There’s a more private and secure version of
 this site available over the Tor network via onion services. Onion
 services help website publishers and their visitors defeat surveillance
 and censorship.
 onionLocation.tryThis=Try Onion Services
 onionLocation.onionAvailable=.onion available
 onionLocation.learnMore=Learn more…
 onionLocation.always=Always
 onionLocation.askEverytime=Ask every time
 onionLocation.prioritizeOnionsDescription=Prioritize .onion sites when
 known.
 onionLocation.onionServicesTitle=Onion Services

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

Re: [tor-bugs] #33771 [Applications/Tor Browser]: Missing LibEvent License

[Tor Bug Tracker & Wiki]

#33771: Missing LibEvent License
--+--
 Reporter:  sysrqb|  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:  boklm |Sponsor:
--+--

Comment (by sysrqb):

 gk pointed me at `about:licenses` where Firefox already includes a license
 for libevent. However, the included is quite old (earlier than 2009). The
 in-tree license (under `ipc/chromium/src/third_party/libevent/` is
 correct, but that's not the one shipped with Firefox). It seems like
 copied the corresponding licenses in
 https://bugzilla.mozilla.org/show_bug.cgi?id=531821 and never updated them
 after that. Firefox [https://bugzilla.mozilla.org/show_bug.cgi?id=1360264
 bumped] its vendored libevent in 2017.

 In any case, I'll open an upstream bug for updating the libevent license
 in Firefox. We should include updated licenses for Tor Browser-specific
 components/libraries. gk mentioned we could add all of our unique licenses
 into `about:license`, as well, instead of bundling them in different text
 files in tor-browser-build. I'll open another ticket for that.

 In the meantime, I'd still like review for the above patches. Shipping a
 license for libevent that is 11 years old is not appropriate.

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

Re: [tor-bugs] #33733 [Internal Services/Tor Sysadmin Team]: How do home directories work?

[Tor Bug Tracker & Wiki]

#33733: How do home directories work?
-+-
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #33715   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tpa => irl
 * status:  needs_review => assigned


Comment:

 waiting for answers from irl

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

Re: [tor-bugs] #32038 [Applications/Tor Browser]: tor-browser-build license is unclear

[Tor Bug Tracker & Wiki]

#32038: tor-browser-build license is unclear
--+--
 Reporter:  JeremyRand|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202003R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * keywords:  TorBrowserTeam202003 => TorBrowserTeam202003R
 * status:  new => needs_review


Comment:

 The branch `bug_32038` has a patch for review, adding a license file:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_32038=b1d5ac3aef0cfa87c973b825f8b32db5bc9da6f7

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

Re: [tor-bugs] #31699 [Core Tor/Tor]: Remove unused configure.ac checks

[Tor Bug Tracker & Wiki]

#31699: Remove unused configure.ac checks
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:  #31698| Points:
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by catalyst):

 Started looking at this; still not done reviewing. The libcap check should
 probably remain because I'm pretty sure we're calling stuff in there, even
 if we're not conditionalizing based on `HAVE_LIBCAP`.

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

Re: [tor-bugs] #32268 [Internal Services/Tor Sysadmin Team]: second new onionoo backend

[Tor Bug Tracker & Wiki]

#32268: second new onionoo backend
-+-
 Reporter:  weasel   |  Owner:  irl
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31659   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 actually, it's blocked on #33733 because they're having trouble
 reproducing our prod environment in dev. but once that's done, i think it
 *is* waiting on irl.

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

Re: [tor-bugs] #32179 [Internal Services/Tor Sysadmin Team]: move orestis to be a new-style onionoo frontend

[Tor Bug Tracker & Wiki]

#32179: move orestis to be a new-style onionoo frontend
-+-
 Reporter:  weasel   |  Owner:  weasel
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31659   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 this is blocked on #32268

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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):

 I wrote the attached stun.lua script to parse pcap files collected from
 some old snowflake network health measurements from #32545.

 These capture files were generated by trying to bootstrap a Tor connection
 through snowflake 100 times. Each time the broker will hand the client a
 different snowflake to connect through. The lua script attempts to figure
 out the ip address of the snowflake and records whether or not NAT
 punching succeeded.

 For all of the snowflakes that the client fails to connect to, I noticed
 the following:
 - the client successfully receives an answer from the broker, meaning ICE
 candidate gathering succeeded at the snowflake
 - snowflakes always produce a non-local address. A geolocation of these IP
 addresses show they aren't necessarily in countries that practice
 censorship (I checked this after noticing we have stats that show
 snowflakes in e.g., China). In fact some of the failing snowflakes were in
 Germany, the US, and the UK.
 - the client successfully sent a Binding Request to the snowflake, but
 never receives a Binding Request from the snowflake or a Binding Success
 Response.

 This is a bit suspicious. If it was a firewall issue at the snowflake
 proxy's end, I would expect their firewall to allow outgoing STUN Binding
 Request packets to the client, since presumably it already allowed
 outgoing STUN packets to the STUN server in order to perform the ICE
 candidate collection. If it was a firewall issue on the client side, I
 would expect all snowflakes to fail.

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

Re: [tor-bugs] #32268 [Internal Services/Tor Sysadmin Team]: second new onionoo backend

[Tor Bug Tracker & Wiki]

#32268: second new onionoo backend
-+-
 Reporter:  weasel   |  Owner:  irl
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31659   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i think this is waiting on the metrics people :)

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

Re: [tor-bugs] #33766 [Internal Services/Tor Sysadmin Team]: DNS renumbering procedure fails if git server is unavailable (was: DNS renumbering procedure fails if git is untouched)

[Tor Bug Tracker & Wiki]

#33766: DNS renumbering procedure fails if git server is unavailable
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 weasel gave me a few more hints:

  6. ud-replicate *does* call the update script:

 {{{
 rebuild_zones=0
 if [ -e /var/lib/misc/thishost/dns-sshfp ]; then
   if ! cmp -s /var/lib/misc/thishost/dns-sshfp "$tempfile"; then
 rebuild_zones=1
   fi
 fi
 [..]
 if [ "${rebuild_zones}" -gt 0 ]; then
   sudo -u dnsadm /srv/dns.torproject.org/bin/update
 fi
 }}}

  7. the update can be triggered by hand with the last command above,
 `sudo -u dnsadm /srv/dns.torproject.org/bin/update`, possibly with
 `--force`

  8. the `$INCLUDE "/var/lib/misc/thishost/dns-sshfp"` from the
 `dns/domains.git` zonefile is not parsed by bind, but by
 "makezonefile or whatever it's called to syntax check and to add
 the SOA header"

 What seems to have happened here is specific to the migration of vineale
 and the git infrastructure: the `update` script failed because it could
 not pull from git (because the original server was done), and aborted
 everything.

 So the following should have happened instead:

  * `update` should have continued with the cached copy of the git repo if
 git pull failed
  * failing that, `ud-replicate` should have warned about the problem
 instead of silently succeeding, and retried until it worked

 The above two points feel like the code changes that could happen to avoid
 that problem in the future. Everything else seems like docs that could be
 thrown in `tsa/howto/ldap.mdwn`.

 But for now, i'll just go back to business as usual and try to get some
 more shit done instead.

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

Re: [tor-bugs] #33772 [Applications/Tor Browser]: Include NSS license in Nightly builds

[Tor Bug Tracker & Wiki]

#33772: Include NSS license in Nightly builds
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:  TorBrowserTeam202004  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 gk pointed me at `about:licenses`, and NSS is
 [https://gitweb.torproject.org/tor-browser.git/tree/security/nss/COPYING?h
 =tor-browser-68.6.0esr-9.5-1 distributed] under the MPL 2.0 license, so we
 are good here. I'll note that `about:licenses` does not specify **which**
 software is distributed under **which** license. But that is a different
 problem.

 {{{
 NSS is available under the Mozilla Public License, version 2, a copy of
 which
 is below.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
-+
Changes (by cohosh):

 * Attachment "stun.lua" 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] #21952 [Applications/Tor Browser]: Onion-location: increasing the use of onion services through automatic redirects and aliasing

[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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Replying to [comment:129 steph]:
 >
 > > @steph @pili @mcs @brade @pospeselr: We are using this text at the
 prompt. Any thought? Let me know if we are ok to reach l10n.
 >
 > How about we mirror with what's on the community page and say:
 >
 > .onion available
 > Try Onion Services
 > There’s a more private and secure version of this site available over
 the Tor network via onion services. Onion services help website publishers
 and their visitors defeat surveillance and censorship.
 > Learn more…
 > Not Now
 > Always Prioritize Onions
 >

 steph: I don't see comments for the strings in `about:preferences`, I'm
 not sure if it's because they are fine as they are, or because you only
 saw the ones in the mockup for the urlbar notification. These should be
 all the strings that are currently in the latest patch:
 {{{
 onionLocation.alwaysPrioritize=Always Prioritize Onionsites
 onionLocation.alwaysPrioritizeAccessKey=a
 onionLocation.notNow=Not Now
 onionLocation.notNowAccessKey=n
 onionLocation.description=Website publishers can protect users by adding a
 security layer. This prevents eavesdroppers from knowing that you are the
 one visiting that website.
 onionLocation.tryThis=Try this: Onionsite
 onionLocation.onionAvailable=Onionsite available
 onionLocation.learnMore=Learn more
 onionLocation.always=Always
 onionLocation.askEverytime=Ask you every time
 onionLocation.prioritizeOnionsDescription=Prioritize onionsites when they
 are available.
 onionLocation.onionServicesTitle=Onion Services
 }}}

 and the screenshots where these appear:
 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952_latest_aboutpreferences.png
 and
 
https://trac.torproject.org/projects/tor/attachment/ticket/21952/withouticon.png
 (note the latter strings differ from the mockup antonela sent). Perhaps
 you already saw this, but I just wanted to make sure.

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

[tor-bugs] #33772 [Applications/Tor Browser]: Include NSS license in Nightly builds

[Tor Bug Tracker & Wiki]

#33772: Include NSS license in Nightly builds
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam202004
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor Browser does not currently include NSS' license in the Nightly builds.

 We can easily include it in all builds for simplicity.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by acat):

 * Attachment "21952_latest_aboutpreferences.png" added.


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

Re: [tor-bugs] #33771 [Applications/Tor Browser]: Missing LibEvent License

[Tor Bug Tracker & Wiki]

#33771: Missing LibEvent License
--+--
 Reporter:  sysrqb|  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:  boklm |Sponsor:
--+--

Comment (by sysrqb):

 Also, we have OpenSSL's license under PluggableTransports and that is a
 little weird, but as far as I know that should not be a problem.

 The licenses included in the commits in the previous comment were copied
 from the currently used git tags for the respective projects.

 Maybe we should add into our release process confirming that we are
 bundling the correct license whenever we include a new version of a
 project.

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

Re: [tor-bugs] #33771 [Applications/Tor Browser]: Missing LibEvent License

[Tor Bug Tracker & Wiki]

#33771: Missing LibEvent License
--+--
 Reporter:  sysrqb|  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:  boklm |Sponsor:
--+--
Changes (by sysrqb):

 * keywords:   => TorBrowserTeam202004R
 * cc: gk (added)
 * status:  new => needs_review


Comment:

 Master: https://gitweb.torproject.org/user/sysrqb/tor-browser-
 build.git/commit/?h=bug_33771=e9bfa29052a68ab85d8666a34c5bf8a0f8b82594

 Maint-9.0: https://gitweb.torproject.org/user/sysrqb/tor-browser-
 
build.git/commit/?h=bug_33771_maint-9.0=a5643d408f133c28d850d08950127f44316a5a18

 This includes updated licenses for Tor, HTTPS-Everywhere, and NoScript, as
 well as a new license file for Libevent.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[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:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

 * status:  needs_review => merge_ready


Comment:

 Looks great, thanks.

 If you would, please also change the dummy addresses in client/torrc and
 client/torrc-localhost in the snowflake repo.

 BTW the reason why the port number is 2 instead of 1 in meek-azure is that
 we were using a [https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/projects/tor-browser/Bundle-
 Data/PTConfigs/bridge_prefs.js?id=78ab93d70e73cf37550f45d6fb8fd61825bc1e95#n44
 different port number] for each meek backend. meek-google at 0.0.2.0:1
 (never deployed), meek-amazon at 0.0.2.0:2, meek-azure at 0.0.2.0:3. Then
 [https://gitweb.torproject.org/builders/tor-browser-
 build.git/commit/projects/tor-browser/Bundle-
 Data/PTConfigs/bridge_prefs.js?id=22af54508a1e98bec13ee9580aac7c1b907043e8
 here] meek-azure took over port 2 when meek-amazon was removed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33771 [Applications/Tor Browser]: Missing LibEvent License

[Tor Bug Tracker & Wiki]

#33771: Missing LibEvent License
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:  boklm
  Sponsor:|
--+--
 Unless I missed the license somewhere, we are not distributing libevent
 (in binary form) along with its license. We should correct 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] #33750 [Internal Services/Services Admin Team]: Hosting BTCPayserver

[Tor Bug Tracker & Wiki]

#33750: Hosting BTCPayserver
-+-
 Reporter:  hiro |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 I have been looking if we can better manage this snowflake somewhere else
 out of our current infra and puppet repository.

 I have been looking at cloud providers that would allow us to deploy a
 docker-compose setup directly.

 Scaleway:
 https://www.scaleway.com/en/kubernetes-kapsule/
 GP1-XS - 4 vCPUs - 16 GB - 150 GB NVMe - 500 Mbit/s - €39/month for a
 kubernetes cluster
 We could just run a single VM and install compose.

 Digital ocean has several options. Either via droplet or via kubernetes.
 Prices are somewhat similar.

 The bitpay people suggest lunanode: https://launchbtcpay.lunanode.com/
 approx 10$ per month.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#31422: Make BridgeDB report internal metrics
-+-
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 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):

 * cc: cohosh, metrics-team (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] #33010 [Metrics/Ideas]: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a cloudflare-hosted static site

[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:17 woswos]:

 > ''Blocking via an unsolvable CAPTCHA''
 > https://patents.google.com/patent/US9407661

 yes, they own a so called Troll Captcha patent and recaptha effectively
 presents you this type of unsolvable captcha. or by connecting through
 exit node, just the Message of "generate an unsolvable challenge-response
 test based on identifying the request as being associated with the
 malicious activity."

 While "associated with the malicious activity" is already an high amount
 of requests that any node is processing.

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

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

Re: [tor-bugs] #27657 [Applications/Tor Browser]: Show .onion icon on Identity drop down?

[Tor Bug Tracker & Wiki]

#27657: Show .onion icon on Identity drop down?
--+---
 Reporter:  gk|  Owner:  pospeselr
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #30025| Points:  6
 Reviewer:|Sponsor:  Sponsor27-can
--+---
Changes (by pili):

 * owner:  tbb-team => pospeselr
 * 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] #27187 [Metrics/Onionoo]: Possible for inconsistency between summary and details with AS number

[Tor Bug Tracker & Wiki]

#27187: Possible for inconsistency between summary and details with AS number
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * cc: metrics-team (added)
 * status:  new => needs_review


Comment:

 I think it's related to how we're merging newly created `NodeStatus`
 instances with data from parsed descriptors with existing instances from
 the previous run

 I wrote a patch that fixes inconsistencies related to host names. I didn't
 find any inconsistencies related to ASes in the current data set. I cannot
 say for sure whether this patch will fix them, too.

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-27187=aae785965fb0ada9e56f27b35431d566a6a18f12
 commit aae7859 in my task-27187 branch].

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

Re: [tor-bugs] #33518 [Community/Tor Browser Manual]: Create "Learn More" links in Tor Browser manual to explain common Onion Service connection errors

[Tor Bug Tracker & Wiki]

#33518: Create "Learn More" links in Tor Browser manual to explain common Onion
Service connection errors
--+---
 Reporter:  pili  |  Owner:  ggus
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor27-can
--+---
Changes (by pili):

 * parent:  #30025 =>


Comment:

 Un-parenting

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

Re: [tor-bugs] #33255 [Metrics]: Review existing graphing code

[Tor Bug Tracker & Wiki]

#33255: Review existing graphing code
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  1
 Reviewer:   |Sponsor:  Sponsor59
-+--
Changes (by acute):

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


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

Re: [tor-bugs] #33255 [Metrics]: Review existing graphing code

[Tor Bug Tracker & Wiki]

#33255: Review existing graphing code
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33327   | Points:  1
 Reviewer:   |Sponsor:  Sponsor59
-+--

Comment (by acute):

 This was a comprehensive review, and your conclusions are spot on.

 >mean time to download first of {51200,1048576,5242880} bytes...
 >number of transfer {PROXY,READ} errors...

 To add to this, if we were to add different sizes of transfers into our
 tgen models, they will automatically be added as keys for the
 analysis/visualisation also.

 Similarly, all types of errors encountered by tgen will be present in the
 final visualization, so any {PROXY,READ,WRITE,AUTH,TIMEOUT,STALLOUT,MISC}
 errors can appear in the plots, if they were encountered.

 I believe this covers everything.

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

Re: [tor-bugs] #30891 [Applications/Tor Check]: check.torproject.org is unreachable commonly, regularly, frequently, persistently, and intermittently

[Tor Bug Tracker & Wiki]

#30891: check.torproject.org is unreachable commonly, regularly, frequently,
persistently, and intermittently
-+-
 Reporter:  monmire  |  Owner:  arlolra
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Check   |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  Tor Check-unreachable issue  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

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


Comment:

 We've completely changed everything since this bug was filed, let's see if
 another one gets filed in its place, but hopefully this is not an issue
 anymore.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-
Changes (by steph):

 * cc: stephw (removed)
 * cc: steph (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] #33770 [Internal Services/Service - git]: GitLab tickets should go in their own component

[Tor Bug Tracker & Wiki]

#33770: GitLab tickets should go in their own component
-+
 Reporter:  irl  |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 At the moment the GitLab tickets arrive in my inbox, and clutter the view
 of git.tpo tickets. This is unhelpful. Can the GitLab team create a
 component with appropriate default owner?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[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:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 Thanks dcf for all that background, that was extremely useful.

 I wrote a patch to change the dummy addresses to the 192.0.2.0/24 range.
 And kept up a pattern of mapping the X in the original 0.0.X.0 address to
 192.0.2.X.

 I checked to make sure it built in the latest version of Tor Browser, and
 that `nyx -i 9151` now works.

 This works as a temporary fix but we should push forward with updating the
 way tor deals with new style PTs that don't have traditional bridge lines.
 #18611 seems like a good ticket to track all that in.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [Circumvention/Snowflake]: snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth used

[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:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #19001   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * Attachment "0001-Bug-33693-Change-dummy-addresses-for-snowflake-
 and-m.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] #32120 [Community/Tor Browser Manual]: Figure out what to do with hidden 'Learn More' link in about:preferences#tor in the 'Advanced' section

[Tor Bug Tracker & Wiki]

#32120: Figure out what to do with hidden 'Learn More' link in
about:preferences#tor in the 'Advanced' section
--+--
 Reporter:  pospeselr |  Owner:  ggus
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team, docshackathon|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pili):

 * keywords:  ux-team => ux-team, docshackathon


Comment:

 This could be a good ticket for the docshackathon

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

Re: [tor-bugs] #33646 [Core Tor/Tor]: Wrong list of enabled modules

[Tor Bug Tracker & Wiki]

#33646: Wrong list of enabled modules
-+-
 Reporter:  Vort |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.2-alpha
 Severity:  Minor| Resolution:
 Keywords:  build, 043-must, 043-backport,   |  Actual Points:  0.1
  consider-backport-after-ci-passes  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Ok... I had to find `m4_foreach_w` example online to discover that some
 special market needs to be added to the expanded variable even though
 without that it is expanded but doesn't work in the test!

 See PR: https://github.com/torproject/tor/pull/1847

 (I think this falls into the "too trivial" for a changes file...?)

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

[tor-bugs] #33769 [Internal Services/Service - git]: Creating issues by email or commenting on merge requests by mail is not working in Gitlab

[Tor Bug Tracker & Wiki]

#33769: Creating issues by email or commenting on merge requests by mail is not
working in Gitlab
-+
 Reporter:  gk   |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Gitlab has the option to do various tasks, like creating issues and
 commenting on merge requests, by email. I tried both commenting on merge
 requests and creating an issue and both failed. Looking at my mail headers
 they look good (according to
 https://docs.gitlab.com/ee/administration/reply_by_email.html), so
 something else is wrong.

 Another interesting bit is that I only sent an email trying to create a
 particular issue (no GUI interaction after/before) and arma is getting a
 notification (there is no "arma" string in the mail body), yet there is no
 issue in Gitlab created.

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

Re: [tor-bugs] #33750 [Internal Services/Services Admin Team]: Hosting BTCPayserver

[Tor Bug Tracker & Wiki]

#33750: Hosting BTCPayserver
-+-
 Reporter:  hiro |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sstevenson):

 Here are the answers from the person from BTCPayServer who is currently
 running a server for us:

  1. It would be nice if we can have an idea of the setup that BTC is
 currently running for us.
 We're running it on LunaNode host http://launchbtcpay.lunanode.com

 2. What are the requirements?

 - 2 GB RAM
 - cca 60GB of SSD storage
 - Docker support

 3. How many coins are supported?
 For now we only deployed Bitcoin and Lightning Network for you, however we
 support a dozen more https://docs.btcpayserver.org/development/altcoins
 (be aware that altcoins are maintained by their own community, we treat
 them as plugins to btcpay, and you'd need more RAM and storage since every
 new coin is essentially a new node, I personally don' think it's worth it
 since you already have a setup for altcoins, but you can give it a try).

 As he says, we have no reason to accept anything other than Bitcoin right
 now. - Sarah

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[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:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  11.6
  roadmap-november, tbb-9.5, network-team-   |
  roadmap-2020Q1, TorBrowserTeam202003R  |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by antonela):

 Thanks, Steph!

 Looks good for me.

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

Re: [tor-bugs] #17809 [Applications/Quality Assurance and Testing]: tbb-tests/browser_tor_TB4.js is out-of-date

[Tor Bug Tracker & Wiki]

#17809: tbb-tests/browser_tor_TB4.js is out-of-date
-+-
 Reporter:  mcs  |  Owner:
 |  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-test-failures|  Actual Points:
  ReleaseTrainMigration  |
Parent ID:  #30832   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor58
-+-
Changes (by acat):

 * keywords:  tbb-test-failures => tbb-test-failures ReleaseTrainMigration


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

Re: [tor-bugs] #19670 [Applications/Quality Assurance and Testing]: Regression test for blocking of Components.interfaces fails

[Tor Bug Tracker & Wiki]

#19670: Regression test for blocking of Components.interfaces fails
-+-
 Reporter:  gk   |  Owner:
 |  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-test-failures|  Actual Points:
  ReleaseTrainMigration  |
Parent ID:  #30832   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor58
-+-
Changes (by acat):

 * keywords:  tbb-test-failures => tbb-test-failures ReleaseTrainMigration


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

Re: [tor-bugs] #30832 [Applications/Tor Browser]: Fix tor-browser tbb-tests

[Tor Bug Tracker & Wiki]

#30832: Fix tor-browser tbb-tests
--+---
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ReleaseTrainMigration |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor58
--+---
Changes (by acat):

 * keywords:  ff68-esr => ReleaseTrainMigration


Comment:

 Removing ff68-esr keyword, I think it's more realistic to aim for
 ReleaseTrainMigration.

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

Re: [tor-bugs] #33549 [Metrics]: Simplify logging configuration across code bases

[Tor Bug Tracker & Wiki]

#33549: Simplify logging configuration across code bases
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+-

Comment (by karsten):

 Great! Pushed to metrics-base and updated all code bases except for
 ExoneraTor where I'd like to wait with making changes until #24542 is
 merged to avoid unnecessary merge conflicts.

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

Re: [tor-bugs] #33663 [Metrics/Exit Scanner]: Check checktest.py related errors shown by our network-health scanners

[Tor Bug Tracker & Wiki]

#33663: Check checktest.py related errors shown by our network-health scanners
-+-
 Reporter:  gk   |  Owner:
 |  metrics-team
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:  0.5
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * owner:  gk => metrics-team
 * 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] #33663 [Metrics/Exit Scanner]: Check checktest.py related errors shown by our network-health scanners

[Tor Bug Tracker & Wiki]

#33663: Check checktest.py related errors shown by our network-health scanners
-+-
 Reporter:  gk   |  Owner:
 |  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:  0.5
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => new


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

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

[Tor Bug Tracker & Wiki]

#10831: Captchas are not accessible for blind users
-+-
 Reporter:  PZajda   |  Owner:  juggy
 Type:  enhancement  | Status:
 |  assigned
 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 pili):

 * owner:  (none) => juggy
 * 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] #33759 [Core Tor/sbws]: recent_measurements_excluded_few_count is used twice in bandwidth spec

[Tor Bug Tracker & Wiki]

#33759: recent_measurements_excluded_few_count is used twice in bandwidth spec
--+--
 Reporter:  gk|  Owner:  gk
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, GeorgKopppen202003  |  Actual Points:
Parent ID:| Points:
 Reviewer:  juga  |Sponsor:
--+--
Changes (by gk):

 * keywords:  tor-spec => tor-spec, GeorgKopppen202003


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #25021, #32927, #33067, #33180, ...

[Tor Bug Tracker & Wiki]

Batch modification to #25021, #32927, #33067, #33180, #33181, #33500, #33696, 
#33758, #33599 by gk:


Comment:
Moving my tickets to April where needed.

--
Tickets URL: 

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

Re: [tor-bugs] #33758 [Metrics/Consensus Health]: Fix exitmap related bad relay tests

[Tor Bug Tracker & Wiki]

#33758: Fix exitmap related bad relay tests
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus Health |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:  #33180   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  network-health, network-health-roadmap-2020Q1 => network-
 health, network-health-roadmap-2020Q1, GeorgKoppen202003


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

Re: [tor-bugs] #33663 [Metrics/Exit Scanner]: Check checktest.py related errors shown by our network-health scanners

[Tor Bug Tracker & Wiki]

#33663: Check checktest.py related errors shown by our network-health scanners
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:  0.5
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => new


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

Re: [tor-bugs] #33181 [Metrics/Consensus Health]: We should look over all our bad relay scanners we have and document them

[Tor Bug Tracker & Wiki]

#33181: We should look over all our bad relay scanners we have and document them
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus Health |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  network-health, network-health-roadmap-2020Q1 => network-
 health, network-health-roadmap-2020Q1, GeorgKoppen202003


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

Re: [tor-bugs] #33180 [Metrics/Consensus Health]: Fix issues with bad relay scanners

[Tor Bug Tracker & Wiki]

#33180: Fix issues with bad relay scanners
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus Health |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-health, network-health-  |  Actual Points:
  roadmap-2020Q1, GeorgKoppen202003  |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => assigned
 * keywords:  network-health, network-health-roadmap-2020Q1 => network-
 health, network-health-roadmap-2020Q1, GeorgKoppen202003


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

Re: [tor-bugs] #33679 [Core Tor/Tor]: Make sure every address function that takes for_listening supports IPv6

[Tor Bug Tracker & Wiki]

#33679: Make sure every address function that takes for_listening supports IPv6
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop312, ipv6, outreachy-ipv6,   |  Actual Points:
  network-team-roadmap-2020Q1|
Parent ID:  #33049   | Points:  0.5
 Reviewer:  teor |Sponsor:
 |  Sponsor55-must
-+-
Changes (by MrSquanchee):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:15 teor]:


 > The test has an invalid IPv6 address,

 Thanks teor,

 The PR is all green now :)
 You can review it [https://github.com/torproject/tor/pull/1831 here].

 Replying to [comment:15 teor]:
 > It looks like the data returned is different on Windows vs macOS/Linux,
 when tor_inet_pton() gets some invalid addresses.
 > I opened #33768 to fix this bug - the functions should behave the same
 across all platforms.

 Yeah !! sometimes stupidity proves to be useful. haha.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

[Tor Bug Tracker & Wiki]

#10831: Captchas are not accessible for blind users
-+-
 Reporter:  PZajda   |  Owner:  (none)
 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
-+-

Comment (by 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!

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

Re: [tor-bugs] #33735 [Applications/Tor Browser]: Impossible to register on a site https://dynasty-scans.com/

[Tor Bug Tracker & Wiki]

#33735: Impossible to register on a site https://dynasty-scans.com/
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by pili):

 I am able to reproduce this but I'm unsure if this is expected behaviour
 due to "Safer" mode or if it's a website issue.

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

Re: [tor-bugs] #33090 [Metrics/Library]: Make all Descriptor implementors serializable

[Tor Bug Tracker & Wiki]

#33090: Make all Descriptor implementors serializable
-+--
 Reporter:  notirl   |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  0.5
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

 * actualpoints:   => 0.5


Comment:

 Great, thanks for reviewing and testing this patch! Merged to master.

 I'm putting in my 0.5 actual points for working on this patch. Please add
 your actual points, so that we get a realistic picture how much effort we
 spent on this enhancement. And please close the ticket afterwards.

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

Re: [tor-bugs] #33764 [Applications/Tor Browser]: Unable to open browser

[Tor Bug Tracker & Wiki]

#33764: Unable to open browser
--+--
 Reporter:  sanjayjc1992@…|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pili):

 * owner:  (none) => tbb-team
 * cc: phw (added)
 * version:  Tor: 0.4.3.3-alpha =>
 * component:  Applications => Applications/Tor Browser
 * sponsor:  SponsorU =>


Comment:

 phw: is this an issue with connecting to a bridge?

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

Re: [tor-bugs] #28906 [Metrics/Relay Search]: host_name search failing

[Tor Bug Tracker & Wiki]

#28906: host_name search failing
--+--
 Reporter:  phoul |  Owner:  metrics-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |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 have #27187 for this issue. Closing as duplicate and
 fixing the bug there.

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