Re: [tor-bugs] #19919 [Core Tor/Tor]: If ORPort address is publicly routable, use it to guess Address

[Tor Bug Tracker & Wiki]

#19919: If ORPort address is publicly routable, use it to guess Address
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.10
 Severity:  Normal   | Resolution:
 Keywords:  address-guessing config torrc|  Actual Points:
  bootsrap relay needs-analysis tarpit   |
Parent ID:  #5940| Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #24403 => #5940


Comment:

 Part of #5940

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

Re: [tor-bugs] #30954 [Core Tor/Tor]: Address torrc option is ignored if set second time for the IPv6 address

[Tor Bug Tracker & Wiki]

#30954: Address torrc option is ignored if set second time for the IPv6 address
--+--
 Reporter:  s7r   |  Owner:  neel
 Type:  enhancement   | Status:  assigned
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #5940 | Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:  #24403 => #5940


Comment:

 Needed for #5940

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

Re: [tor-bugs] #24777 [Core Tor/Tor]: Make relays try IPv6 ORPorts for directory uploads and downloads

[Tor Bug Tracker & Wiki]

#24777: Make relays try IPv6 ORPorts for directory uploads and downloads
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #5940| Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #24403 => #5940


Comment:

 Needed for #5940

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

Re: [tor-bugs] #31413 [Core Tor/Tor]: Check for internal IPv6 connects and extends

[Tor Bug Tracker & Wiki]

#31413: Check for internal IPv6 connects and extends
-+--
 Reporter:  neel |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay  |  Actual Points:
Parent ID:  #24405   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * parent:  #24403 => #24405


Comment:

 Part of #24405

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

Re: [tor-bugs] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

[Tor Bug Tracker & Wiki]

#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Progress. I completed the 10 rounds of exit scanning by patching
 `relay_perf.py`:
 {{{
 async def build_two_hop_circuit(state, guard, exit_node):
 +circuit = {}
  success = None
  error = ""
  t_start = time.time()
 }}}
 Now I get a TLS error when connecting to Onionoo:
 {{{
   File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line
 1418, in _inlineCallbacks
 result = g.send(result)
   File "/home/gk/exit-dns/tor_dns_survey/relay_perf.py", line 127, in
 _main
 exit_results["_relays"] = relay_data(True)
   File "/home/gk/exit-dns/tor_dns_survey/relay_perf.py", line 28, in
 relay_data
 response = urllib.request.urlopen(req).read()
   File "/usr/lib/python3.7/urllib/request.py", line 222, in urlopen
 return opener.open(url, data, timeout)
   File "/usr/lib/python3.7/urllib/request.py", line 525, in open
 response = self._open(req, data)
   File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
 '_open', req)
   File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
 result = func(*args)
   File "/usr/lib/python3.7/urllib/request.py", line 1360, in https_open
 context=self._context, check_hostname=self._check_hostname)
   File "/usr/lib/python3.7/urllib/request.py", line 1319, in do_open
 raise URLError(err)
 urllib.error.URLError: 
 }}}

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

Re: [tor-bugs] #24604 [Core Tor/Tor]: Decorate IPv6 addresses in connection_t->address to avoid ambiguity

[Tor Bug Tracker & Wiki]

#24604: Decorate IPv6 addresses in connection_t->address to avoid ambiguity
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #32314   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #24403 => #32314


Comment:

 #32314 should fix 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] #24000 [Core Tor/Tor]: circuit_send_intermediate_onion_skin() and extend_cell_format() should check for IPv6

[Tor Bug Tracker & Wiki]

#24000: circuit_send_intermediate_onion_skin() and extend_cell_format() should
check for IPv6
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 034-triage-20180328, merge-|  Actual Points:
  deferred, 035-triaged-in-20180711, |
  040-deferred-20190220  |
Parent ID:  #24405   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by teor):

 * parent:  #24403 => #24405


Comment:

 Covered by #24405

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

Re: [tor-bugs] #4565 [Core Tor/Tor]: Enable relays to talk to other relays via IPv6

[Tor Bug Tracker & Wiki]

#4565: Enable relays to talk to other relays via IPv6
-+-
 Reporter:  karsten  |  Owner:  ln5
 Type:  project  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 tor-relay needs-design  |  Actual Points:
Parent ID:  #24405   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #24403 => #24405


Comment:

 Covered by #24405

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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/Exit Scanner]: 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/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Please consider setting up both, IPv4 - & IPv6 only domain. To test them
 individually. As the exiting IP will be punished differently like
 another's IP but while it's the same exit, only different protocol.

 Also important can be the first seen date of a fingerprint. To group out
 if only "fresh' exit IPs can reaches it's destinations for a short period
 of time until they are burned with endless troll captcha.

 This will hopefully help to proof all the frustration and headache that
 cloudflaw is throughing against all Tor users on daily basis.

 For every UA not a browser, I guess >90 fail rates.

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

Re: [tor-bugs] #29343 [Metrics/Ideas]: Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to Onionoo

[Tor Bug Tracker & Wiki]

#29343: Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to
Onionoo
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Ideas   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-health  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:   => network-health


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

Re: [tor-bugs] #6939 [Core Tor/Tor]: Missing IPv6 ORPort reachability check

[Tor Bug Tracker & Wiki]

#6939: Missing IPv6 ORPort reachability check
-+-
 Reporter:  shamrock |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, ipv6-relay, self-   |  Actual Points:
  test, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #13112   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #24403 => #13112


Comment:

 This code duplicates code in #13112, we should take the best combination
 of both branches.

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

Re: [tor-bugs] #24611 [Core Tor/Chutney]: Add a chutney network that does reachability tests

[Tor Bug Tracker & Wiki]

#24611: Add a chutney network that does reachability tests
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay address-detection  |  Actual Points:
  reachability   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
-+-
Description changed by teor:

Old description:

> Chutney sets `AssumeReachability 1` in all its networks.
>
> We should make a network which doesn't set AssumeReachability, so we can
> test relay reachability changes.
>
> We might even want to add the network to `make test-network-all` if it's
> fast enough, or add a separate make target if it's not.

New description:

 Chutney sets `AssumeReachability 1` in all its networks.

 We should make a network which doesn't set AssumeReachability, so we can
 test relay reachability changes.

 As part of Sponsor 55, we want to make reachability chutney networks part
 of:
 * `make test-network`
 * `make test-network-all`
 * Tor's Travis CI
 * Chutney's Travis CI

--

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

Re: [tor-bugs] #24611 [Core Tor/Chutney]: Add a chutney network that does reachability tests

[Tor Bug Tracker & Wiki]

#24611: Add a chutney network that does reachability tests
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay address-detection  |  Actual Points:
  reachability   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 As part of Sponsor 55, we want to make these chutney networks part of
 `make test-network`, `make test-network-all`, and our Travis CI.

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

Re: [tor-bugs] #24611 [Core Tor/Chutney]: Add a chutney network that does reachability tests

[Tor Bug Tracker & Wiki]

#24611: Add a chutney network that does reachability tests
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay address-detection  |  Actual Points:
  reachability   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #17782 => #24403


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

Re: [tor-bugs] #33011 [Circumvention/Snowflake]: Remove erroneous logging around pt.*Error calls

[Tor Bug Tracker & Wiki]

#33011: Remove erroneous logging around pt.*Error calls
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #33011 [Circumvention/Snowflake]: Remove erroneous logging around pt.*Error calls

[Tor Bug Tracker & Wiki]

#33011: Remove erroneous logging around pt.*Error calls
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "0001-Remove-erroneous-logging-around-pt.-Error-calls.patch"
 added.


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

[tor-bugs] #33011 [Circumvention/Snowflake]: Remove erroneous logging around pt.*Error calls

[Tor Bug Tracker & Wiki]

#33011: Remove erroneous logging around pt.*Error calls
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 #31794 added logging around every function call that returns an `error`
 type; but this is the wrong thing to do in the case of functions like
 [https://godoc.org/git.torproject.org/pluggable-
 transports/goptlib.git#CmethodError pt.CmethodError],
 [https://godoc.org/git.torproject.org/pluggable-
 transports/goptlib.git#SmethodError pt.SmethodError], and
 [https://godoc.org/git.torproject.org/pluggable-
 transports/goptlib.git#ProxyError pt.ProxyError]. These functions are
 called for their side effect of sending a PT error message on stdout; it
 happens that they also return a representation of the error message as an
 `error` object for the caller to use if it wishes. They ''always'' return
 a non-`nil` `error` object; a non-`nil` error is not an exceptional event
 to be logged.

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

Re: [tor-bugs] #32753 [Core Tor/Tor]: Tor should lower-case its BridgeDistribution string

[Tor Bug Tracker & Wiki]

#32753: Tor should lower-case its BridgeDistribution string
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-backport 041-backport|  Actual Points:
  042-backport easy anticensorship-wants fast-   |
  fix 043-should |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor28
-+-
Changes (by ahf):

 * sponsor:   => Sponsor28


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

Re: [tor-bugs] #28970 [Core Tor/Tor]: tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#28970: tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624:
setup_intro_circ_auth_key: Non-fatal assertion
-+-
 Reporter:  torcrash |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.9
 Severity:  Critical | Resolution:  fixed
 Keywords:  consider-backport-after-0424,|  Actual Points:  0.1
  042-backport, 041-backport, 040-backport,  |
  035-backport, tor-client, tor-hs, postfreeze-  |
  ok, 040-unreached-must, network-team-roadmap-  |
  august, regression?, 041-unreached-must,   |
  042-should |
Parent ID:  #29995   | Points:  5
 Reviewer:  teor |Sponsor:
 |  Sponsor27-must
-+-

Comment (by cypherpunks):

 Yes, I got this bug too now and found version of Tor that Orbot is
 shipping is still **0.4.1.5-RC**

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

Re: [tor-bugs] #32923 [Applications/Tor Browser]: Detached Tor Browser Firedox APK - Option to Customize Configuration - VPN Function - Android

[Tor Bug Tracker & Wiki]

#32923: Detached Tor Browser Firedox APK - Option to Customize Configuration - 
VPN
Function - Android
---+---
 Reporter:  onestep|  Owner:  tbb-team
 Type:  enhancement| Status:  reopened
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:  Tor:
   |  0.4.2.5
 Severity:  Major  | Resolution:
 Keywords:  Tor Browser APK Android VPN Nodes  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [ticket:32923 onestep]:
 >
 > Just need a separate Tor Browser APK that can be used with good old
 Orbot. Or a new form of something similar that can allow users to choose.
 >
 >


 There is a workaround. Using orbot directly with tbb without leaks.  You
 can reconfigure tbb to use not it's own built-in Tor Socksport but orbots.

 Go-to
 {{{
 about:config
 }}}
  And change socks 5 Port to default 9050. Traffic will now flow through
 orbot. And tbb can work fine in coexistence.

 Simply ignore the bundled Tor of tbb!

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

Re: [tor-bugs] #32923 [Applications/Tor Browser]: Detached Tor Browser Firedox APK - Option to Customize Configuration - VPN Function - Android

[Tor Bug Tracker & Wiki]

#32923: Detached Tor Browser Firedox APK - Option to Customize Configuration - 
VPN
Function - Android
---+---
 Reporter:  onestep|  Owner:  tbb-team
 Type:  enhancement| Status:  reopened
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:  Tor:
   |  0.4.2.5
 Severity:  Major  | Resolution:
 Keywords:  Tor Browser APK Android VPN Nodes  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [ticket:32923 onestep]:

 > Also, as Android' built in Always-on VPN can take advantage of outdated
 Orbot's VPN feature to tunnel everything over Tor with zero leak when user
 chooses Block internet without VPN option in Android network settings.
 >

 This is simply and sadly not true! Don't rely on this feature. It is leaky
 by design! Don't trust this block anything but or orbot feature please!

 This Android feature natively is multi user supported. This means you can
 run a 2nd profile (user) or Android guest account or Android work profile
 under same user without switching and have actively bypass the Android'
 built in Always-on VPN (block everything else's) option.

 In fact you can even configure two or more Android always online VPN in
 coexistence parallel. For this profiles each.


 And tunneling and blocking some system process seems broken too. Ntp for
 example. Feel free to check with Wireshark on your own.

 This is the reason I badly missing transparent proxy with root support
 removed from orbot earlier. :(

 ...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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/Exit Scanner]: 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/Exit Scanner  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * cc: pili (added)


Comment:

 This project would be a great gsoc idea.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33010 [Metrics/Exit Scanner]: 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/Exit Scanner  |Version:
 Severity:  Normal|   Keywords:  network-health
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We should track the rate that cloudflare gives captchas to Tor users over
 time.

 My suggested way of doing that tracking is to sign up a very simple static
 webpage to be fronted by cloudflare, and then fetch it via Tor over time,
 and record and graph the rates of getting a captcha vs getting the real
 page.

 The reason for the "simple static page" is to make it really easy to
 distinguish whether we're getting hit with a captcha. The "distinguishing
 one dynamic web page from another" challenge makes exitmap tricky in the
 general case, but we can remove that variable here.

 One catch is that Cloudflare currently gives alt-svc headers in response
 to fetches from Tor addresses. So that means we need a web client that can
 follow alt-srv headers -- maybe we need a full Selenium like client?

 Once we get the infrastructure set up, we would be smart to run a second
 one which is just wget or curl or lynx or something, i.e. which doesn't
 behave like Tor Browser, in order to be able to track the difference
 between how Cloudflare responds to Tor Browser vs other browsers.

 I imagine that Cloudflare should be internally tracking how they're
 handling Tor requests, but having a public tracker (a) gives the data to
 everybody, and (b) helps Cloudflare have a second opinion in case their
 internal data diverges from the public version.

 The Berkeley ICSI group did research that included this sort of check:
 https://www.freehaven.net/anonbib/#differential-ndss2016
 https://www.freehaven.net/anonbib/#exit-blocking2017
 but what I have in mind here is essentially a simpler subset of this
 research, skipping the complicated part of "how do you tell what kind of
 response you got" and with an emphasis on automation and consistency.

 There are two interesting metrics to track over time: one is the fraction
 of exit relays that are getting hit with captchas, and the other is the
 chance that a Tor client, choosing an exit relay in the normal weighted
 faction, will get hit by a captcha.

 Then there are other interesting patterns to look for, e.g. "are certain
 IP addresses punished consistently and others never punished, or is
 whether you get a captcha much more probabilistic and transient?" And does
 that pattern change over time?

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

Re: [tor-bugs] #32992 [Applications/Tor Browser]: Android Project for LZMA

[Tor Bug Tracker & Wiki]

#32992: Android Project for LZMA
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:1 boklm]:
 > What do you mean by "Android Project for LZMA"?
 From now on tbb Android and orbot can built with this library flag set in
 configure.
 {{{
 --with-lzma
 }}}
 Effectively reducing directory bandwidth by fetching better compressed
 descriptors

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

Re: [tor-bugs] #32991 [Applications/Tor Browser]: Android Project For ZSTD

[Tor Bug Tracker & Wiki]

#32991: Android Project For ZSTD
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Build with zstd flag for lib support since it exists

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

Re: [tor-bugs] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  043-should|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Here's the script I used for bisecting:
 {{{
 if ! test -f configure; then
 # abort bisect if setup fails
 ./autogen.sh  || exit 255
 # fragile hardening is required to trigger the bug
 # disabling asciidoc makes configure require fewer dependencies
 ./configure --disable-asciidoc --enable-fragile-hardening || exit 255
 fi

 # skip bisect of this commit if it doesn't build
 make src/app/tor || exit 125
 python3 "$STEM_SOURCE_DIR"/run_tests.py --tor src/app/tor --integ --test
 process.test_take_ownership_via_controller --log TRACE --log-file stem.log
 }}}

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

Re: [tor-bugs] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  043-should|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => closed
 * cc: catalyst (added)
 * resolution:   => worksforme


Comment:

 It looks like this timing issue was introduced in the #30984 refactor,
 perhaps in commit c744d23c8d. (At least on my machine.)

 Tor doesn't guarantee control reply timing. And we're unlikely to be able
 to restore the old timing behaviour. So stem's tests should be adapted to
 work with the timing in both Tor 0.4.2 and Tor master.

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

Re: [tor-bugs] #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:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by teor):

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


Comment:

 Note: Torflow's partitions have a similar issue, but it's actually worse:
 a relay can get stuck in a low-bandwidth partition forever.

 So perhaps this isn't strictly a blocker, because the new behaviour is
 eventually better. But the fix is so easy, we should just do it.

 I suggest we only use the top 75% of exits as the second hop, which should
 remove the long tail of slow exits. (These slow exits are also more likely
 to fail to connect, and therefore fail the entire bandwidth test. So this
 change should also improve sbws efficiency.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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 |   Keywords:  sbws-majority-blocker
Actual Points: |  Parent ID:
   Points:  1  |   Reviewer:
  Sponsor: |
---+---
 When sbws is constructing a two-hop measurement circuit to run a test, it
 tries to pick an exit that has at least twice the consensus weight of the
 current relay-under-test:
 https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216

 So this means that in this case, sbws would have picked any exit that was
 not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of
 at least, well, 2.  That's not a lot.

 As it turns out, something like 10% of exits have under a 600Kbyte/sec
 advertised bandwidth.  So it seems pretty easy from this weight=1
 bootstrap scenario to get paired with an exit that will give poor test
 results.

 Perhaps bwauth path selection should also choose a testing pair from
 exits/relays with a certain absolute minimum of weight or advertised
 bandwidth?

 Reported by Jimmy on tor-relays:
 https://lists.torproject.org/pipermail/tor-relays/2020-January/018027.html

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

Re: [tor-bugs] #33007 [Community/Relays]: Bridge campaign retrospective

[Tor Bug Tracker & Wiki]

#33007: Bridge campaign retrospective
--+---
 Reporter:  arma  |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s30-o24a1 |  Actual Points:
Parent ID:  #31281| Points:  0.25
 Reviewer:|Sponsor:  Sponsor30-can
--+---
Changes (by phw):

 * parent:   => #31281


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

Re: [tor-bugs] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
--+---
 Reporter:  phw   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s30-o24a1 |  Actual Points:
Parent ID:  #31281| Points:  3
 Reviewer:|Sponsor:  Sponsor30-can
--+---

Comment (by arma):

 I am excited about this one, because it's the culmination of all the back-
 end work: just having the data in a data set is a good step zero, but
 giving it to users (bridge operators) in a usable way is where it all
 needs to lead.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
--+--
 Reporter:  phw   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:  s30-o24a1
Actual Points:|  Parent ID:  #31281
   Points:  3 |   Reviewer:
  Sponsor:  Sponsor30-can |
--+--
 Bridge operators often want to know what distribution bucket their bridge
 fell into. Since #29480, one can find out by inspecting our
 [https://collector.torproject.org/recent/bridge-pool-assignments/ archived
 bridge pool assignments] but that's cumbersome and not user friendly. We
 should instead show the bucket on the bridge's relay search page. How can
 we get this done?

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

Re: [tor-bugs] #32864 [Community/Relays]: Reproduce Arthur's exit failures and then contact or badexit the relays

[Tor Bug Tracker & Wiki]

#32864: Reproduce Arthur's exit failures and then contact or badexit the relays
---+--
 Reporter:  arma   |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health, GeorgKoppen202001  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 See #29343 for an older version of this ticket.

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

Re: [tor-bugs] #29343 [Metrics/Ideas]: Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to Onionoo

[Tor Bug Tracker & Wiki]

#29343: Run arthur's DNS timeout scanner, archive it in CollecTor, and add it to
Onionoo
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 See #32864 for a newer version of this ticket.

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

Re: [tor-bugs] #32314 [Core Tor/Tor]: Can't connect to literal IPv6 address containing double colon

[Tor Bug Tracker & Wiki]

#32314: Can't connect to literal IPv6 address containing double colon
-+-
 Reporter:  liberat  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-exit, ipv6,  |  Actual Points:  0.1
  BugSmashFund, 042-backport, 043-should |
Parent ID:  #26664   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => needs_revision
 * keywords:  tor-client, tor-exit, ipv6, BugSmashFund, check-backport
 043-should? => tor-client, tor-exit, ipv6, BugSmashFund, 042-backport,
 043-should


Comment:

 Looking at the tests from #30721, Tor now expects square brackets for
 ambiguous IPv6 cases:
 {{{
   /* And this is an ambiguous case, which is interpreted as an IPv6
 address. */
   TEST_ADDR_V6_PARSE_CANONICAL("11:22::88:99", 0);
   /* Use square brackets to resolve the ambiguity */
   TEST_ADDR_V6_PARSE_CANONICAL("[11:22::88:99]", 1);
   TEST_ADDR_V6_PORT_PARSE("[11:22::88]:99",
"11:22::88",99);
 }}}
 https://github.com/torproject/tor/pull/1068/files#diff-
 048243cd6d9ed36dda0944181d8ec8abR1285

 So it looks like this issue still happens in Tor 0.4.2.

 We should make sure that an ambiguous IPv6 address always has square
 brackets, as soon as it is parsed by the client, and whenever it's sent
 via the Tor protocol.

 We could handle ambiguous cases at the exit using the previous behaviour.
 (Assume IPv6 with a default port.)

 We can make exceptions for client and exit code, but we should not allow
 ambiguous addresses in other code. (For example: config code, directory
 document parsing code.)

 Who wants to turn these patches into a pull request?
 * https://trac.torproject.org/projects/tor/ticket/32314#comment:1
 * a similar fix that canonicalises MapAddress config and request parsing
 * a fix for exits that canonicalises IPv6 addresses
   * the simplest way to fix this issue is to try parsing as an address
 first, then try parsing as an address and port

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

Re: [tor-bugs] #30946 [Circumvention/BridgeDB]: Port BridgeDB to Python 3

[Tor Bug Tracker & Wiki]

#30946: Port BridgeDB to Python 3
+--
 Reporter:  phw |  Owner:  (none)
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  python  |  Actual Points:
Parent ID:  | Points:  10
 Reviewer:  |Sponsor:
+--

Comment (by atagar):

 Hi Philipp. It took alot of work but I've finished porting BridgeDB to
 python 3. The port is available within my python3 branch...

 https://github.com/atagar/bridgedb/commits/python3

 Tests now pass with python 3.5 but has not been exercised in a runtime
 context. Its tests provide good coverage so should be close.

 If tor would ever care to hire a BridgeDB maintainer to replace Isis let
 me know. The codebase relies excessively on catch-alls to mask underlying
 instability so there's quite a bit of room for stabilization.

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

Re: [tor-bugs] #33007 [Community/Relays]: Bridge campaign retrospective

[Tor Bug Tracker & Wiki]

#33007: Bridge campaign retrospective
--+---
 Reporter:  arma  |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s30-o24a1 |  Actual Points:
Parent ID:| Points:  0.25
 Reviewer:|Sponsor:  Sponsor30-can
--+---
Changes (by phw):

 * keywords:   => s30-o24a1
 * points:   => 0.25
 * sponsor:   => Sponsor30-can


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

Re: [tor-bugs] #32314 [Core Tor/Tor]: Can't connect to literal IPv6 address containing double colon

[Tor Bug Tracker & Wiki]

#32314: Can't connect to literal IPv6 address containing double colon
-+-
 Reporter:  liberat  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.6
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-exit, ipv6,  |  Actual Points:  0.1
  BugSmashFund, check-backport 043-should?   |
Parent ID:  #26664   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_information


Comment:

 We did some fixes to IPv6 address parsing in #23082 in 0.4.0.1-alpha, and
 #30721 in 0.4.2.1-alpha.

 Can you please test with Tor 0.4.2, and see if this issue still happens?
 (It would also be good to test with an exit running Tor 0.4.2. The easiest
 way to do that is to use chutney: https://git.torproject.org/chutney.git )

 If the issue was fixed in #30721 in 0.4.2.1-alpha, we might want to
 backport parts of https://github.com/torproject/tor/pull/1068 to 0.4.0.
 But we should be really sure we get it right.

 I don't think we should try to backport #23082 or #30721 to 0.3.5.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33007 [Community/Relays]: Bridge campaign retrospective

[Tor Bug Tracker & Wiki]

#33007: Bridge campaign retrospective
--+--
 Reporter:  arma  |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In the S30 January meeting notes:
 https://lists.torproject.org/pipermail/tor-
 project/2020-January/002655.html
 we have this great phrase
 {{{
 We ran a bridge setup campaign resulting in approximately 100 new bridges
 (Obj 2.4) --phw
 }}}

 But: how many of those bridges are still running, now that it's some
 months later?

 This is especially a good time to do a retrospective, because we have
 contact info for each of the bridges, and we can send a "so, what
 changed?" mail to each of the bridges that are no longer up -- both to
 nudge them into putting the bridges back up, but also to solicit bug
 reports and ux issues for bridge operators.

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

Re: [tor-bugs] #32969 [Core Tor/Chutney]: Chutney 'bootstrap-network.sh' shouldn't overwrite 'CHUTNEY_DATA_DIR'

[Tor Bug Tracker & Wiki]

#32969: Chutney 'bootstrap-network.sh' shouldn't overwrite 'CHUTNEY_DATA_DIR'
--+
 Reporter:  opara |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We'd need to check this fix a bit more carefully, but it seems like a good
 idea.

 Would you like to submit a pull request to:
 https://github.com/torproject/chutney

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

Re: [tor-bugs] #32972 [Core Tor/Chutney]: Chutney doesn't remove temporary files after processing warnings

[Tor Bug Tracker & Wiki]

#32972: Chutney doesn't remove temporary files after processing warnings
--+
 Reporter:  opara |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Sounds like a good fix!

 Would you like to submit a pull request to:
 https://github.com/torproject/chutney

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

Re: [tor-bugs] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  043-must => 043-should
 * actualpoints:  0.2 =>


Comment:

 This bug only occurs with `./configure --enable-fragile-hardening` on my
 system. So it may be a tor/stem race condition bug. (#29437 is a similar
 bug, we may need #30901 to debug this kind of race condition.)

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

Re: [tor-bugs] #33000 [Applications/Tor Browser]: Click-to-play does not work on embedded videos on the blog in safer mode

[Tor Bug Tracker & Wiki]

#33000: Click-to-play does not work on embedded videos on the blog in safer mode
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * cc: ma1 (added)


Comment:

 This is reproducible on Standard by disabling Noscript's media capability
 for Default.

 Hi ma1, is this a known bug? I don't see any obvious open issues for it.
 It's an embedded third-party iframe from youtube. Media cap is disabled.
 The video element shows the play button. After clicking the element so the
 video begins, Noscript shows click-to-play. After clicking the element
 again, Noscript prompts for allowing media. After allowing media the video
 shows a spinning animation and then returns to showing the play element.

 https://blog.torproject.org/2019-campaign-wrapup-tor-take-back-the-
 internet

 and reproducible here:
 https://www.w3schools.com/html/tryit.asp?filename=tryhtml_youtubeiframe

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

Re: [tor-bugs] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-must  |  Actual Points:  0.2
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  043-should => 043-must
 * actualpoints:   => 0.2


Comment:

 We broke this in 0.4.3, so we have to fix it.

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

Re: [tor-bugs] #32822 [Core Tor/Tor]: Make authorities add their own IPv6 address to trusted dir servers

[Tor Bug Tracker & Wiki]

#32822: Make authorities add their own IPv6 address to trusted dir servers
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  0.4
Parent ID:| Points:  0.2
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by teor):

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


Comment:

 Let's do this in 0.4.4: it's a feature, and there's no need to add it at
 the last minute.

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

Re: [tor-bugs] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This stem test passes on 0.4.2:
 * https://travis-ci.org/torproject/tor/jobs/637709536

 But fails on master:
 Stem logs:
 * https://travis-ci.org/teor2345/tor/builds/639735548#L5757
 Tor logs:
 * https://travis-ci.org/teor2345/tor/builds/639735548#L4708
 (I think the Tor logs are too verbose to show anything interesting.)

 So it's probably a Tor bug.

 I can also reproduce these results locally with the latest tor and stem
 master, so I should be able to bisect.

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

Re: [tor-bugs] #33003 [Applications/Tor Browser]: Tor browser / Firefox telemetry data

[Tor Bug Tracker & Wiki]

#33003: Tor browser / Firefox telemetry data
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeamTriaged |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * keywords:   => TorBrowserTeamTriaged
 * priority:  High => Medium
 * severity:  Major => Normal


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

Re: [tor-bugs] #33003 [Applications/Tor Browser]: Tor browser / Firefox telemetry data

[Tor Bug Tracker & Wiki]

#33003: Tor browser / Firefox telemetry data
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 I don't understand the bug. Tor Browser has some preferences with URLs as
 their value and some of them contain "mozilla" or "google" or "org" (?).
 Their existence is not a bug, if they are used in unexpected ways, then
 that may be a bug. This happens occasionally, but are you reporting this
 is happening now? Can you provide steps for reproducing it?

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

Re: [tor-bugs] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I created a diagnostics branch that just runs test-stem, and just the
 affected test:
 * do not merge: https://github.com/torproject/tor/pull/1678

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  043-should
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 Stem's `test_take_ownership_via_controller` test fails when run in Travis
 CI. This is a recent failure, some time in the last month or two.

 See, for example:
 https://travis-ci.org/torproject/tor/jobs/639546796

 We're trying to work out if it's a Tor or Stem issue right now, here's the
 corresponding Stem ticket:
 https://github.com/torproject/stem/issues/52

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

Re: [tor-bugs] #33004 [Applications/GetTor]: Modify tests and update README to properly test GetTor locally

[Tor Bug Tracker & Wiki]

#33004: Modify tests and update README to properly test GetTor locally
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw, hiro|Sponsor:
-+
Changes (by cohosh):

 * status:  new => needs_revision
 * reviewer:   => phw, hiro


Comment:

 I've added a few commits to clean up the current tests so that they run on
 developer machines:
 https://dip.torproject.org/cohosh/gettor/compare/master...ticket%2F33004

 In particular, these commits:
 - create a database in the testing directory for testing purposes
 - use a test config file instead of a hardcoded file that doesn't exist
 outside of the deployment machine
 - avoid doing any tests that require knowledge of secrets, such as twitter
 auth keys
 - Fix some minor bugs/edge cases

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

Re: [tor-bugs] #19327 [Core Tor/Tor]: controller: expose fine-grained circuit detail.

[Tor Bug Tracker & Wiki]

#19327: controller: expose fine-grained circuit detail.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-control isolation test-support   |  Actual Points:
  intro  |
Parent ID:  #17284   | Points:  5
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:26 aveuiller]:
 > As for the CI errors, it was related to some memory leaks, so I fixed
 them.
 > However, it seems that the integration tests with Stem are still failing
 but I tried with the master branch and it fails too on my device.
 > I'm looking into it but it seems unrelated to my changes. :)

 Tor's stem `test_take_ownership_via_controller` test is currently failing,
 possibly due to some unrelated changes in stem or tor:
 https://github.com/torproject/stem/issues/52

 Your PR fails the same test:
 https://travis-ci.org/torproject/tor/jobs/639537151#L3665

 Once the `test_take_ownership_via_controller` issue is fixed, the stem
 tests will hang, and we don't know why. It's been going on for a while. So
 we are going to implement #30901 to get some diagnostics.

 The stem CI job is marked as "allow_failure" in Travis, so you can pretty
 much ignore the results.

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

Re: [tor-bugs] #32870 [Applications/Tor Browser]: Bump version of pion webrtc in Tor Browser

[Tor Bug Tracker & Wiki]

#32870: Bump version of pion webrtc in Tor Browser
--+--
 Reporter:  cohosh|  Owner:  cohosh
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202001R |  Actual Points:  .7
Parent ID:  #31971| Points:  1
 Reviewer:|Sponsor:  Sponsor28
--+--

Comment (by cohosh):

 Here's an updated commit message/branch name:
 https://gitweb.torproject.org/user/cohosh/tor-browser-
 build.git/log/?h=ticket/32870

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

Re: [tor-bugs] #32034 [Core Tor/Tor]: tor reads PT protocol messages from stderr

[Tor Bug Tracker & Wiki]

#32034: tor reads PT protocol messages from stderr
--+
 Reporter:  dcf   |  Owner:  neel
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.2-alpha
 Severity:  Normal| Resolution:  invalid
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 Created #33005 for 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] #32999 [Internal Services/Tor Sysadmin Team]: Add irl to the "check" and "tordnsel" LDAP groups

[Tor Bug Tracker & Wiki]

#32999: Add irl to the "check" and "tordnsel" LDAP groups
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Sounds good to me!

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

Re: [tor-bugs] #33005 [Core Tor/Tor]: Lower log level of standard error messages from PT's

[Tor Bug Tracker & Wiki]

#33005: Lower log level of standard error messages from PT's
--+--
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor28
--+--
Changes (by ahf):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #33005 [Core Tor/Tor]: Lower log level of standard error messages from PT's

[Tor Bug Tracker & Wiki]

#33005: Lower log level of standard error messages from PT's
--+--
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor28
--+--

Comment (by ahf):

 PR https://github.com/torproject/tor/pull/1677 - awaiting CI.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33005 [Core Tor/Tor]: Lower log level of standard error messages from PT's

[Tor Bug Tracker & Wiki]

#33005: Lower log level of standard error messages from PT's
--+--
 Reporter:  ahf   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  tor-pt
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor28 |
--+--
 While trying to reproduce #32034 I noticed we were logging messages sent
 from a PT on stderr with `warn` as log level, which is probably too high.

 Already wrote a patch for it in #32034, but I need to update the changes
 file to use this ticket ID.

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

Re: [tor-bugs] #32435 [Applications/Tor Browser]: Compile clang for Linux x86_64 with WASM support

[Tor Bug Tracker & Wiki]

#32435: Compile clang for Linux x86_64 with WASM support
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, GeorgKoppen202001, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32434   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-security, GeorgKoppen202001, TorBrowserTeam202001R => tbb-
 security, GeorgKoppen202001, TorBrowserTeam202001
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:4 gk]:
 > `bug_32389` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_32389&id=298b18f9e1319077e8909b5ec43f270fbfabf405)
 has a build patch up for review.

 One small simplification: I think the line `rlbox: '[% c("var/nightly") &&
 c("var/linux-x86_64") %]'` can be moved to `targets/linux-x86_64` instead
 of `targets/linux`, so that the part `&& c("var/linux-x86_64")` can be
 removed.

 We can also remove the lines `rlbox: 0` for the other platforms, as it is
 disabled by default.

 With only one place where it is set, I think this makes it easier to see
 in which case it is enabled.

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

Re: [tor-bugs] #19757 [Applications/Tor Browser]: Make a menu to add onion and auth-cookie to TB

[Tor Bug Tracker & Wiki]

#19757: Make a menu to add onion and auth-cookie to TB
-+-
 Reporter:  mrphs|  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:  5
  TorBrowserTeam202001R  |
Parent ID:  #3   | Points:  8
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by pospeselr):

 > https://gitweb.torproject.org/user/brade/tor-
 
browser.git/tree/browser/components/onionservices/content/savedKeysDialog.js?h=bug19757-01&id=fb12d169bfe97b5a71a9135ad1efe25d39a1c097#n56
 >{{{
 >// Remove in reverse index order to avoid issues caused by index changes.
 >for (let i = indexesToDelete.length - 1; i >= 0; --i) {
 >  await this._deleteOneKey(torController, indexesToDelete[i]);
 >}
 >}}}

 This feels a bit fishy to me. We're saving off a list of indices and then
 individually removing them from both {{{this._keyInfoList}}} and
 {{{this._tree}}}. This happens in an async context, so wouldn't it be
 possible for the indices to become invalidated if keys were to be added in
 the middle of a large batch of deletions?

 I *think* a better way to do this would be to first create a list of the
 hsAdresses we want to remove,  do our synchronous work updating
 {{{this._keyInfoList}}} and {{{this._tree}}}, then call
 {{{onionAuthRemove}}} with all of our hsAddresses (assuming they can't all
 be batched together into one call to tor).

 Alternatively, we could call {{{loadSavedKeys()}}} after a multi-delete to
 ensure the UI matches the tor backing store.

 Apart from that, these changes look good to me.

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

[tor-bugs] #33004 [Applications/GetTor]: Modify tests and update README to properly test GetTor locally

[Tor Bug Tracker & Wiki]

#33004: Modify tests and update README to properly test GetTor locally
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Right now the README only says to run:
 `$ pytest-3 tests/`

 However, tests will always fail due to the lack of a database and hard-
 coded config files in the the gettor code. We should update this code and
 the testing instructions to be able to test code locally before deploying
 on gettor-01.

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

Re: [tor-bugs] #19327 [Core Tor/Tor]: controller: expose fine-grained circuit detail.

[Tor Bug Tracker & Wiki]

#19327: controller: expose fine-grained circuit detail.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-control isolation test-support   |  Actual Points:
  intro  |
Parent ID:  #17284   | Points:  5
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by aveuiller):

 Thanks for the review. I updated the code and answered to your comment
 about printing the booleans.

 As for the CI errors, it was related to some memory leaks, so I fixed
 them.
 However, it seems that the integration tests with Stem are still failing
 but I tried with the master branch and it fails too on my device.
 I'm looking into it but it seems unrelated to my changes. :)

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

Re: [tor-bugs] #33003 [Applications/Tor Browser]: Tor browser / Firefox telemetry data

[Tor Bug Tracker & Wiki]

#33003: Tor browser / Firefox telemetry data
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


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

Re: [tor-bugs] #30237 [Applications/Tor Browser]: Tor Browser: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#30237: Tor Browser: Improve TBB UI of hidden service client authorization
-+-
 Reporter:  asn  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  Actual Points:  16
  TorBrowserTeam202001R  |
Parent ID:  #3   | Points:  17
 Reviewer:  pospeselr, sysrqb|Sponsor:
 |  Sponsor27-must
-+-

Comment (by pospeselr):

 The control port changes look good to me.

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

Re: [tor-bugs] #22346 [Metrics/Analysis]: Investigate drop in Tor Browser update pings in early 2017, 2018, 2019 and 2020

[Tor Bug Tracker & Wiki]

#22346: Investigate drop in Tor Browser update pings in early 2017, 2018, 2019 
and
2020
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * type:  defect => task


Comment:

 I took another look at the database to see if what we're seeing here is an
 artifact of processing web server request logs.

 First, I looked at requested sites to see if this is in any way related to
 the change from `www.tp.o`/`dist.tp.o` to `aus1.tp.o` that was mentioned 3
 years ago or similar changes after that. Here's a graph:

 [[Image(tbup-site-2020-01-20.png, 700px)]]

 No, this is not the reason. There was just one such switch, and even
 though it coincides with the first drop, there was no other switch after
 that.

 Second, I looked at requested servers to see if this is maybe related to
 web servers being added to or removed from the rotation. For example, it
 could be that some servers do not properly sync their request logs to the
 metrics server. Here's a graph:

 [[Image(tbup-server-2020-01-20.png, 700px)]]

 There have been quite a few web servers over the years, so that this graph
 is a bit harder to read. That's why I included absolute and relative
 numbers. The first drop is a bit confusing, also related to the site
 change, but the other three drops do not show any correlation with server
 changes at start or end of the drop. The second drop had server changes in
 the middle of the drop, but apparently those did not affect numbers much.
 The third and fourth drop did not have any server changes.

 All in all, I don't see a bug in the data processing part, at least not an
 obvious one. It seems to me that these requests are real.

 I'm changing the ticket type to task, because a defect in a Metrics/*
 component implies that there's a bug in our code, and right now I don't
 see that that's the case.

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

Re: [tor-bugs] #30570 [Applications/Tor Browser]: Implement per-site security settings support

[Tor Bug Tracker & Wiki]

#30570: Implement per-site security settings support
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #25658   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-

Comment (by pospeselr):

 Replying to [comment:19 ma1]:
 >But do you need the blocked resource/message ration be 1/1? Could it be
 just a coarse-grained >asynchronous message which coalesces a certain
 number of blocking events, e.g. at DOM Completion and then with a 500ms
 granularity, if any occurs (providing details about each blocked
 subresource, of course, but wholesale)?
 >
 I think this sounds reasonable.

 Replying to [comment:19 ma1]:
 > I don't believe that would have any perceivable performance impact, but
 a finer-grained per-site setup message can be easily arranged, yes.
 I'll defer to your judgement here. If you think sending over the entire
 settings object is unlikely to cause noticeable perf problems then let's
 just go with whatever approach is easiest to do correctly. We can come
 back to it later if it poses an issue in the future.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33003 [- Select a component]: Tor browser / Firefox telemetry data

[Tor Bug Tracker & Wiki]

#33003: Tor browser / Firefox telemetry data
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Component:  - Select a component
  Version:   |   Severity:  Major
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 https://seclists.org/fulldisclosure/2019/May/17

 It seems this issue is still not fixed although it has been announced in
 May 2019. URLs containing "mozilla", "google" etc. (as described) can
 still be found in `about:config`

 This is well known in Firefox and there are various `user.js` projects
 which eliminate background connections.

 Although in the case of Tor Browser the IP address is anonymized this is
 still unacceptable, especially for a browser which claims to be focused on
 protecting privacy.

 As a privacy focused user: I expect 0 (zero) background connections and no
 possibility to enable such (through preferences or through
 `about:config`).

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

Re: [tor-bugs] #22346 [Metrics/Analysis]: Investigate drop in Tor Browser update pings in early 2017, 2018, 2019 and 2020

[Tor Bug Tracker & Wiki]

#22346: Investigate drop in Tor Browser update pings in early 2017, 2018, 2019 
and
2020
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * Attachment "tbup-server-2020-01-20.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] #22346 [Metrics/Analysis]: Investigate drop in Tor Browser update pings in early 2017, 2018, 2019 and 2020

[Tor Bug Tracker & Wiki]

#22346: Investigate drop in Tor Browser update pings in early 2017, 2018, 2019 
and
2020
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * Attachment "tbup-site-2020-01-20.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] #32985 [Internal Services/Tor Sysadmin Team]: make ikiwiki show proper headings

[Tor Bug Tracker & Wiki]

#32985: make ikiwiki show proper headings
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i enabled the headinganchors plugin and things look much better 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] #32787 [Internal Services/Tor Sysadmin Team]: Delete tb-crashes role

[Tor Bug Tracker & Wiki]

#32787: Delete tb-crashes role
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam202001 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i removed the role and group from LDAP, all done here.

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

Re: [tor-bugs] #32787 [Internal Services/Tor Sysadmin Team]: Delete tb-crashes role

[Tor Bug Tracker & Wiki]

#32787: Delete tb-crashes role
-+-
 Reporter:  sysrqb   |  Owner:  anarcat
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam202001 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tbb-team => anarcat
 * status:  needs_information => accepted


Comment:

 actually, the role is not defined anywhere, so if they exist, those files
 are already unowned.

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

Re: [tor-bugs] #32827 [Internal Services/Services Admin Team]: archive.tpo's rsync logs ip addresses (and it shouldn't)

[Tor Bug Tracker & Wiki]

#32827: archive.tpo's rsync logs ip addresses (and it shouldn't)
-+-
 Reporter:  arma |  Owner:  anarcat
 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 anarcat):

 i've filed this as a security issue as per
 https://github.com/systemd/systemd/security/policy

 after a timeout, i'll file it as a bug.

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

Re: [tor-bugs] #32827 [Internal Services/Services Admin Team]: archive.tpo's rsync logs ip addresses (and it shouldn't)

[Tor Bug Tracker & Wiki]

#32827: archive.tpo's rsync logs ip addresses (and it shouldn't)
-+-
 Reporter:  arma |  Owner:  anarcat
 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 anarcat):

 > this probably affects other components, as I just reused existing code
 when i set that up. we also need to track that.

 at first glance, that's the only server which has that problem.

 i've censored the IP addresses from the rsync access log in a5726714, but
 we have another problem: rsync is started by systemd socket activation,
 which happily spills those IP addresses all over itself:

 {{{
 Jan 20 20:09:45 archive-01/archive-01 systemd[1]: Started rsync daemon
 archive (10.0.0.1:35380).
 Jan 20 20:09:45 archive-01/archive-01 systemd[1]: rsyncd-
 archive@76504-159.69.63.226:873-10.0.0.1:35380.service: Succeeded.
 }}}

 In that context, `10.0.0.1` is my IP address, which I censored in this
 copy-paste.

 so this is only partly 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] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Alright it looks like it checks like gettor checks the received email for
 strings that match any known locales, as defined by a
 [https://gitweb.torproject.org/gettor.git/tree/gettor/utils/strings.py#n89
 locale json].

 However, after looking at the other json files
 [https://gitweb.torproject.org/gettor.git/tree/share/locale in this
 directory], it seems like there's a conflation between translated gettor
 message body and the tor browser binary links. We only have json files for
 translating the message body into three languages so far, which we should
 open a separate ticket to expand on, but there's no reason why we can't
 give out links for the requested locale as long as we have 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] #32823 [Core Tor/Tor]: support Android SharedPreferences xml as a torrc format

[Tor Bug Tracker & Wiki]

#32823: support Android SharedPreferences xml as a torrc format
-+-
 Reporter:  eighthave|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, xml, tbb-mobile, torrc, |  Actual Points:
  sharedpreferences  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 I agree there should be a canonical config data format, but not
 necessarily the file format.  My guess is that the existing configuration
 options can already be treated as a data model, then treat the formats as
 just representations of that data model.  This data model is also what
 already exists in Tor's C code.  E.g. like how its easy to convert data
 files between YAML, JSON, and TOML.  Hugo (written in Go) and Jekyll
 (written in Ruby) can use YAML/JSON/TOML interchangeably for data/config
 files.  Then the data model is the canonical format, and the file formats
 are just containers for that.  At the highest level, there is key/value
 pairs `RunAsDaemon`/boolean, `DNSPort`/int+string, `Bridges`/string.  This
 will be a little trickier, since we're talking XML and ''torrc'', but
 unless I've overlooked something in the ''torrc'' format, it seems that
 the data model is already simple enough to map cleanly.
 `SharedPreferences` XML already gives us a format with the basic data
 formats that are needed.  As a side note, this would make it easy to also
 use TOML/YAML/JSON as needed.

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

Re: [tor-bugs] #32827 [Internal Services/Services Admin Team]: archive.tpo's rsync logs ip addresses (and it shouldn't)

[Tor Bug Tracker & Wiki]

#32827: archive.tpo's rsync logs ip addresses (and it shouldn't)
-+-
 Reporter:  arma |  Owner:  anarcat
 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:
-+-
Changes (by anarcat):

 * owner:  (none) => anarcat
 * 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] #32981 [Internal Services/Tor Sysadmin Team]: New RT queue 'training'

[Tor Bug Tracker & Wiki]

#32981: New RT queue 'training'
-+-
 Reporter:  ggus |  Owner:  pili
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32893   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-
Changes (by anarcat):

 * owner:  anarcat => pili
 * status:  accepted => assigned


Comment:

 I've created the new queue, at least I think I did. The setup was a little
 more complicated than I thought it would be. I documented my findings
 here:

 https://help.torproject.org/tsa/howto/rt/

 The next step is to test the queue. See if you can make sense of it! :)

 @pili: I assigned you this ticket, as an RT admin, for the next step. I
 believe that would be to grant gus access to the queue somehow, which
 might require creating a group. Let me know if you need help!

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

Re: [tor-bugs] #31377 [Applications/GetTor]: Create a GetTor survival guide

[Tor Bug Tracker & Wiki]

#31377: Create a GetTor survival guide
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  survival-guide   |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Updating this to say that most of these are accounted for. I believe what
 we have left is to document what happens when we call `export_stats` as
 well as any log file processing. That might also be in progress though :)

 Here's the current survival guide: https://dip.torproject.org/torproject
 /anti-censorship/gettor-project/gettor/-/wikis/Gettor-Service-Operator-
 HowTo

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
-+--
 When testing GetTor, I get links for en-US binaries even when I request a
 different locale. I've checked that the requested locales are available so
 I think there is a bug in the email processor. The following locales *are*
 processed correctly:
 - `en` to `en-US`
 - `pt` to `pt-BR`
 - `es` to `es-ES`

 However, I tried `ru`, `ar`, and `fa` and these all sent me `en-US` links.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs https-everywhere tor-ux   |  Actual Points:
  network-team-roadmap-november  |
  TorBrowserTeam202001   |
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by acat):

 Some thoughts after thinking a bit how to implement this.

 Supporting local redirects from human-memorable addresses (`.tor.onion` ->
 `.onion`) can be done with https-everywhere extension as is, either by
 adding a 3rd-party update channel or by adding custom rulesets in debug
 mode (the latter is less usable I assume). With respect to update
 channels, it should not be difficult to modify https-everywhere to allow
 enabling/disabling automatic updates per channel and not globally as it is
 currently implemented, and this is something that might be interesting
 also for non Tor Browser https-everywhere users (although I don't think
 many people have more update channels than the default one).

 Then we need to show the human-memorable URL in the urlbar, plus possibly
 some visual feedback indicating that there was some kind of local redirect
 (I guess the concrete UX solution still needs to be decided). This has to
 be implemented in Tor Browser, since AFAIK there is no way to achieve that
 using a WebExtension like https-everywhere only. There are several ways
 this can be implemented from the Tor Browser side, but at the end of the
 day we need some way to know whether for the current `.onion` page we have
 some `.tor.onion` human-memorable "alias" that the user trusts.

 With the current implementation, it would be difficult from Tor Browser
 side to ask https-everywhere questions like: is there any `.onion` mapping
 for this `.tor.onion` domain the user just entered? So I think the
 simplest is to observe `.tor.onion` -> `.onion` redirects and assume that
 when this happens it's because the original `.tor.onion` is a  human-
 memorable alias for the corresponding `.onion` that the user trusts.
 Observing http requests like that should be quite simple to do from Tor
 Browser side, and this implementation would work independently of https-
 everywhere: we just observe `.tor.onion` -> `.onion` redirects, but we
 don't need to know how or by whom these redirects were done.

 A few questions/issues regarding showing short `.tor.onion` in urlbar:

   1. Whenever there is a `.tor.onion` -> `.onion` redirect, should we
 display the full original URL in the urlbar,   or just replace the
 hostname for the human-memorable one in the final URL? For example, let's
 say we observe a redirect from http://nytimes.securedrop.tor.onion to
 https://www.nyttips4bmquxfzw.onion (upgrade to https + translate from
 `.tor.onion` + adding www). In this case I think it would not make much
 sense to show the original URL, but just display
 https://www.[nytimes.securedrop.tor.onion] (and if we follow the solution
 I mentioned, show https://www.nyttips4bmquxfzw.onion when user clicks on
 it).

   2. What should we do when user keeps navigating in subpages of some
 `.onion`, given the fact that the `.tor.onion` -> `.onion` is only
 observed in the first navigation? Should we show the human-memorable
 `.tor.onion` in the urlbar for that tab until the user navigates away from
 the underlying `.onion`? Do we also need to show `.tor.onion` for links
 opened in a new tab from there?

   3. Do we need to show `.tor.onion` when user navigates directly to a
 `.onion` page for which we have some `.tor.onion` "rule"? (mentioned by
 sysrqb in a IRC conversation)

 If we were to implement 3) I think we would need to be able to ask https-
 everywhere for some kind of reverse lookup to obtain a `.tor.onion` for a
 given `.onion` hostname, so the current approach of just observing http
 redirects from Tor Browser would not work.

 Note that if we had an explicit list of `.tor.onion` -> `.onion` pairs
 indicating this mapping (like a /etc/hosts file) we would not need to be
 looking for redirects to infer the `.tor.onion` -> `.onion` relationship,
 and doing a "reverse lookup" (finding a `.tor.onion` that corresponds to
 some `.onion`) would be trivial. I also think that designing a UI to
 view/edit `.tor.onion` rules/mappings would be much easier than doing one
 f

Re: [tor-bugs] #32997 [Circumvention/BridgeDB]: Captcha error on bridges.torproject.org

[Tor Bug Tracker & Wiki]

#32997: Captcha error on bridges.torproject.org
+
 Reporter:  amirhossein |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Major   | Resolution:
 Keywords:  bridgedb-reportbug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by cohosh):

 * component:  Applications/GetTor => Circumvention/BridgeDB


Comment:

 Switching the component to BridgeDB

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

Re: [tor-bugs] #32977 [Applications/GetTor]: Move GetTor github repository to torproject/torbrowser-releases

[Tor Bug Tracker & Wiki]

#32977: Move GetTor github repository to torproject/torbrowser-releases
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Merged in `518c546738e`:
 
https://gitweb.torproject.org/gettor.git/commit/?id=518c546738ea2e160714ba91ff6c26bf4780c71b

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

Re: [tor-bugs] #32998 [Internal Services/Tor Sysadmin Team]: Upgrade metrics hosts to buster

[Tor Bug Tracker & Wiki]

#32998: Upgrade metrics hosts to buster
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Replying to [comment:3 anarcat]:
 > > Cool! How about tomorrow? If so, I'd make some backups and turn off
 the daily updater. Ideally, the upgrade would happen between 8:00 and
 12:00 UTC or between 13:00 UTC and 17:00 UTC.
 >
 > Tomorrow is a little rushed for me, but maybe I could squeeze that in.
 Could we coordinate on this tomorrow morning?

 Sure. I'll be on IRC starting at around 8:00 UTC.

 > This ticket mentions "metrics hosts", but in the description you talk
 only of meronense... are there other boxes you were thinking of?

 I was referring to the other hosts with services run by the metrics team:
 CollecTor on colchicifolium and corsicum, Onionoo on omeiense and oo-
 hetzner-03, and ExoneraTor on materculae. These are all unrelated to
 #30351, and we can do them one by one over the next weeks or months.

 In any case, there is just one host for the Metrics website, and that's
 meronense. That's the one I'd like to get upgraded first.

 > >  Sounds good. Having a heads-up of one or two workdays should be
 sufficient in most cases.
 >
 > Duly noted! (in https://help.torproject.org/tsa/howto/upgrades/ :))

 Thanks! :)

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

Re: [tor-bugs] #32998 [Internal Services/Tor Sysadmin Team]: Upgrade metrics hosts to buster

[Tor Bug Tracker & Wiki]

#32998: Upgrade metrics hosts to buster
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 > Cool! How about tomorrow? If so, I'd make some backups and turn off the
 daily updater. Ideally, the upgrade would happen between 8:00 and 12:00
 UTC or between 13:00 UTC and 17:00 UTC.

 Tomorrow is a little rushed for me, but maybe I could squeeze that in.
 Could we coordinate on this tomorrow morning?

 This ticket mentions "metrics hosts", but in the description you talk only
 of meronense... are there other boxes you were thinking of?

 >  Sounds good. Having a heads-up of one or two workdays should be
 sufficient in most cases.

 Duly noted! (in https://help.torproject.org/tsa/howto/upgrades/ :))

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

Re: [tor-bugs] #30351 [Metrics/Website]: Unknown error in prepare_* functions using the spread() function

[Tor Bug Tracker & Wiki]

#30351: Unknown error in prepare_* functions using the spread() function
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 No database involved here. And no, it's unrelated, as I can reproduce the
 issue in a local VM.

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

Re: [tor-bugs] #30351 [Metrics/Website]: Unknown error in prepare_* functions using the spread() function

[Tor Bug Tracker & Wiki]

#30351: Unknown error in prepare_* functions using the spread() function
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by anarcat):

 do you happen to know if this could be related to the weird database
 crashes I've seen recently in #32692?

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

Re: [tor-bugs] #32034 [Core Tor/Tor]: tor reads PT protocol messages from stderr

[Tor Bug Tracker & Wiki]

#32034: tor reads PT protocol messages from stderr
--+
 Reporter:  dcf   |  Owner:  neel
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.2-alpha
 Severity:  Normal| Resolution:  invalid
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

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


Comment:

 Replying to [comment:7 dcf]:
 > Could we rather close this ticket immediately and do the log level in a
 separate ticket?

 Let's do that. I'll create a new ticket for the lowering of the log level
 in a moment.

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

Re: [tor-bugs] #32034 [Core Tor/Tor]: tor reads PT protocol messages from stderr

[Tor Bug Tracker & Wiki]

#32034: tor reads PT protocol messages from stderr
--+
 Reporter:  dcf   |  Owner:  neel
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dcf):

 Replying to [comment:5 ahf]:
 > I think the example script have a bug: The `echo`'s in the subshell
 writes to standard out and you redirect all output from the subshell from
 standard error to standard out, where instead it should be redirect all
 output from the subshell's standard out to standard error, so `1>&2`
 instead of `2>&1`.

 You're absolutely right. It was my mistake. I apologize for the false
 report.

 > Tor's PT standard error handler does not send the standard error
 messages into the PT state machine handler and logs the errors with the
 warning log level. I do think that's a bit higher than what we want for
 this kind of event, so I'm submitting a patch in a moment that lowers the
 log level for PT standard error messages from warning to debug.

 Could we rather close this ticket immediately and do the log level in a
 separate ticket?

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

Re: [tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202002   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * priority:  Medium => High
 * keywords:  Android, tbb-mobile, jtorctl, TorBrowserTeam202001 => Android,
 tbb-mobile, jtorctl, TorBrowserTeam202002


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

Re: [tor-bugs] #32920 [Internal Services/Service - jenkins]: rebuild or replace scaleway boxes (scw-arm-*)

[Tor Bug Tracker & Wiki]

#32920: rebuild or replace scaleway boxes (scw-arm-*)
-+
 Reporter:  anarcat  |  Owner:  weasel
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by anarcat):

 i decomissioned scw-arm-ams-01 in #33001 and closed ticket WJVJ-9718-KIPG
 with scaleway. the other ticket is still open because scw-arm-par-01 still
 doesn't boot the right kernel, but it might be able to reboot unattended,
 unclear.

 in any case, we might want to shift all this away from this scaleway
 platform... but that will mean dropping the 32-bit ARM infrastructure, as
 scw-arm-par-01 is a `armv7l` which we don't have an equivalent for
 elsewhere right now. weasel was looking for an excuse to drop those
 anyways, but I'll leave him with that decision.

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

Re: [tor-bugs] #33001 [Internal Services/Service - jenkins]: decomission scw-arm-ams-01

[Tor Bug Tracker & Wiki]

#33001: decomission scw-arm-ams-01
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #32920   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 all done, this is just an old memory 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] #33001 [Internal Services/Service - jenkins]: decomission scw-arm-ams-01

[Tor Bug Tracker & Wiki]

#33001: decomission scw-arm-ams-01
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32920   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 backup removal scheduled:

 {{{
 root@bungei:/srv/backups/bacula# host=scw-arm-ams-01
 root@bungei:/srv/backups/bacula# mv $host.torproject.org $host.torproject
 .org-OLD
 root@bungei:/srv/backups/bacula# echo rm -rf
 /srv/backups/bacula/$host.torproject.org.OLD/ | at now + 30 days
 warning: commands will be executed using /bin/sh
 job 16 at Wed Feb 19 18:54:00 2020
 }}}

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

Re: [tor-bugs] #33001 [Internal Services/Service - jenkins]: decomission scw-arm-ams-01

[Tor Bug Tracker & Wiki]

#33001: decomission scw-arm-ams-01
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32920   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  assigned => accepted


Comment:

 following https://help.torproject.org/tsa/howto/retire-a-host/, in
 progress:

 1. N/A
 2. N/A
 3. N/A
 4. N/A
 5. removed from LDAP and group (lost the LDAP block, unfortunately, but
 its public IP was 51.15.115.17)
 6. not present in DNS
 7. removed from Puppet: `Submitted 'deactivate node' for scw-arm-
 ams-01.torproject.org.torproject.org with UUID 367f43ee-47b0-46fb-b66c-
 b9f3496bb24a`
 8. removed from puppet (0983e324)
 9. removed from tor-passwords (hardware creation date was 2015-05!)
 10. remove from trac wiki and spreadsheet
 11. remove from nagios
 12. schedule backup removal
 13. remove from lets'encrypt
 14. instance deleted from Scaleway's dashboard
 15. N/A

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33001 [Internal Services/Service - jenkins]: decomission scw-arm-ams-01

[Tor Bug Tracker & Wiki]

#33001: decomission scw-arm-ams-01
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Service -  |Version:
  jenkins|
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #32920
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 the scaleway box have been having various issues, defined in the parent
 ticket (#32920). after much messing around with upstream, they finally
 threw the towel:

 > Following further investigation, we did not notice any issue on our side
 that could explain your system booting on a different OS, nor Rescue mode.
 > All we can suggest is to create a new server if you are not able to
 access your personal environment anymore I'm afraid.

 In other words, the box (scw-arm-ams-01) is lost with all hands.

 Given this is a build box, I do not believe it is worth restoring and we
 should just complete the decomissionning process. It was running a
 `aarch64` architecture, according to Puppet facts, and we already have a
 replacement for his at Linaro.

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

Re: [tor-bugs] #32034 [Core Tor/Tor]: tor reads PT protocol messages from stderr

[Tor Bug Tracker & Wiki]

#32034: tor reads PT protocol messages from stderr
--+
 Reporter:  dcf   |  Owner:  neel
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 PR to lower the log level from warn to debug in
 https://github.com/torproject/tor/pull/1676 - let's see what CI says.

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

Re: [tor-bugs] #32034 [Core Tor/Tor]: tor reads PT protocol messages from stderr

[Tor Bug Tracker & Wiki]

#32034: tor reads PT protocol messages from stderr
--+
 Reporter:  dcf   |  Owner:  neel
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 I think the example script have a bug: The `echo`'s in the subshell writes
 to standard out and you redirect all output from the subshell from
 standard error to standard out, where instead it should be redirect all
 output from the subshell's standard out to standard error, so `1>&2`
 instead of `2>&1`.

 The example with `wc` also shows this, as the redirect to `/dev/null`
 should still show the three lines to standard error:

 {{{
 user@tor-dev:~$ ./test-fake-pt.sh > /dev/null | wc -l
 0
 VERSION 1
 SMETHOD testpt 127.0.0.1:
 SMETHODS DONE
 }}}

 Tor's PT standard error handler does not send the standard error messages
 into the PT state machine handler and logs the errors with the warning log
 level. I do think that's a bit higher than what we want for this kind of
 event, so I'm submitting a patch in a moment that lowers the log level for
 PT standard error messages from warning to debug.

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

Re: [tor-bugs] #32920 [Internal Services/Service - jenkins]: rebuild or replace scaleway boxes (scw-arm-*)

[Tor Bug Tracker & Wiki]

#32920: rebuild or replace scaleway boxes (scw-arm-*)
-+
 Reporter:  anarcat  |  Owner:  weasel
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - jenkins  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by anarcat):

 this just in: scw-arm-ams-01 is still down and scaleway says they can't
 recover it, and suggest reinstalling. i'll just decom the machine for now
 so that we at least save the costs here, but we should consider another
 place to host those VMs from here on, because that's really just
 unacceptable.

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

Re: [tor-bugs] #32977 [Applications/GetTor]: Move GetTor github repository to torproject/torbrowser-releases

[Tor Bug Tracker & Wiki]

#32977: Move GetTor github repository to torproject/torbrowser-releases
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by hiro):

 LGTM

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

Re: [tor-bugs] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

[Tor Bug Tracker & Wiki]

#32027: Bump version of Go to 1.13+
-+-
 Reporter:  cohosh   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tbb-rbm,  |  Actual Points:
  TorBrowserTeam202002   |
Parent ID:  #31688   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  snowflake, tbb-rbm, TorBrowserTeam202001 => snowflake, tbb-
 rbm, TorBrowserTeam202002


Comment:

 This can come after we solve supporting module.

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