Re: [tor-bugs] #31130 [Applications/Tor Browser]: Use Debian 10 for our Android container images

[Tor Bug Tracker & Wiki]

#31130: Use Debian 10 for our Android container images
+--
 Reporter:  gk  |  Owner:  sisbell
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201911R  |  Actual Points:
Parent ID:  #31127  | Points:  0.5
 Reviewer:  |Sponsor:
+--
Changes (by sisbell):

 * keywords:  tbb-rbm, TorBrowserTeam201911 => tbb-rbm,
   TorBrowserTeam201911R


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

Re: [tor-bugs] #32516 [Applications/Tor Browser]: Make Write Methods Clearer in TorConfigBuilder

[Tor Bug Tracker & Wiki]

#32516: Make Write Methods Clearer in TorConfigBuilder
--+
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:  .25
 Reviewer:|Sponsor:
--+

Comment (by sisbell):

 Replying to [comment:3 sysrqb]:
 > {{{
 >  public TorConfigBuilder makeNonExitRelay(String dnsFile, int
 orPort, String nickname) {
 > -buffer.append("ServerDNSResolvConfFile
 ").append(dnsFile).append('\n');
 > -buffer.append("ORPort ").append(orPort).append('\n');
 > -buffer.append("Nickname ").append(nickname).append('\n');
 > -buffer.append("ExitPolicy reject *:*").append('\n');
 > -return this;
 > +writeLine("ServerDNSResolvConfFile", dnsFile);
 > +writeLine("ORPort", String.valueOf(orPort));
 > }}}
 > nit: ORPort should take an address, as well, and `writeAddress` seems
 more explicit. But don't worry about that right now, we can come back to
 this later.
 Good catch, I missed that one. WriteAddress with all the host support will
 come in another commit. Its a minor breaking change as we will need to
 change the field params for each host/port pair.

 >
 > {{{
 > public TorConfigBuilder proxyOnAllInterfaces() {
 > -buffer.append("SocksListenAddress 0.0.0.0").append('\n');
 > -return this;
 > +return writeLine("SocksListenAddress 0.0.0.0");
 >  }
 > }}}
 > nit: This could use `writeAddress("SocksListenAddress", "0.0.0.0", null,
 null)` instead
 >
 > {{{
 >  public TorConfigBuilder transportPluginObfs(String clientPath) {
 > -buffer.append("ClientTransportPlugin obfs3 exec
 ").append(clientPath).append('\n');
 > -buffer.append("ClientTransportPlugin obfs4 exec
 ").append(clientPath).append('\n');
 > -return this;
 > +return writeLine("ClientTransportPlugin obfs3 exec",
 clientPath)
 > +.writeLine("ClientTransportPlugin obfs4 exec",
 clientPath);
 >  }
 > }}}
 > This can be simplified to `ClientTransportPlugin obfs3,obfs4 exec`. Or,
 if we take this two steps further, combine this method and
 `transportPluginMeek` into a single `transportPlugin` and use
 `ClientTransportPlugin meek_lite,obfs2,obfs3,obfs4,scramblesuit exec`
 Yes that will look cleaner.
 >
 >
 > `writeAddress`
 > {{{
 > +if (port != null) {
 > +buffer.append(port <= 0 ? "auto" : port);
 > +} else {
 > +buffer.append("auto");
 > +}
 > }}}
 > I'm still not sure we should change `port <= 0` into `auto`. `*Port 0`
 is already defined as disabling that type of port. Do we need two ways of
 setting `auto`?

 I believe you made this comment before, so I put in the following fix. Its
 in the commit link at top, just under the issue description.
 {{{
 if (port != null && port >= 0) {
 buffer.append(port);
 } else {
 buffer.append("auto");
 }
 }}}


 > {{{
 > +public TorConfigBuilder writeLine(String value, String value2) {
 > +return writeLine(value + " " + value2);
 > +}
 > }}}
 > This seems like a surprising overload. I'm not opposed to having it, but
 it doesn't seem helpful and it is more confusing (less readable) than
 simply passing the string concatenation directly into `writeLine(String)`.
 This was a bit of a shortcut on my part. I think the correct solution
 would be to take varargs on the writeLine and just loop the append. I'll
 get that 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] #32476 [Applications/Tor Browser]: Support Launching TorService Using JNI

[Tor Bug Tracker & Wiki]

#32476: Support Launching TorService Using JNI
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, |  Actual Points:
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Desktop TBB is not using TOPL.  I think its fine targeting Android for the
 JNI work, as that is the primary platform we are interested in. We can
 just stick with your implementation of the unix socket for the control
 port.

 As we break apart everything, we can pick and choose which components it
 makes sense to share between the projects. I'm still interested in
 creating pure Java components where we can, as this would be more useful
 to the general community.

 The Android specific pieces deal mostly around broadcasts and shared
 preferences so those can be abstracted out without complicating the code.
 Orbot already has abstractions for the data so its just a matter of
 standardizing all of that similar to what we are talking about with
 jtorctl.

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

Re: [tor-bugs] #31130 [Applications/Tor Browser]: Use Debian 10 for our Android container images

[Tor Bug Tracker & Wiki]

#31130: Use Debian 10 for our Android container images
---+--
 Reporter:  gk |  Owner:  sisbell
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201911  |  Actual Points:
Parent ID:  #31127 | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 Looks like we just need one additional dependency installed for the JDK
 headless installation. I verified a full build.

 https://github.com/sisbell/tor-browser-
 build/commit/005b6651ba42737c7e1bd177f01286294355c02f

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

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by amiableclarity2011):

 Thank you so much for your help again.

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

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by amiableclarity2011):

 China's Internet Police also can get the data on the servers which locate
 in Hong Kong and in Macao. China's Internet Police may also get the data
 on the servers which locate in the countries that have good relationship
 with China, for example, Pakistan and Cuba.

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

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by amiableclarity2011):

 In my torrc-defaults file, I didn't replace stun.ekiga.net with
 stun.gotye.com.cn

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

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by amiableclarity2011):

 Today, I didn't replace stun.ekiga.net with stun.gotye.com.cn

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

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by amiableclarity2011):

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by amiableclarity2011):

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by amiableclarity2011):

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

[Tor Bug Tracker & Wiki]

#32597: Hello, currently, in China, Tor Browser 9.5a2 still can't connect to Tor
network through snowflake bridge
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by amiableclarity2011):

 Today, in China, I still can't connect to Tor network through snowflake
 bridge.
 Below are Tor log messages.
 11/27/19, 04:35:48.891 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/27/19, 04:35:54.970 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/27/19, 04:35:54.970 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/27/19, 04:35:54.970 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/27/19, 04:35:54.970 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 11/27/19, 04:35:54.970 [NOTICE] Opened Socks listener on 127.0.0.1:9150
 11/27/19, 04:35:55.770 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to
 pluggable transport
 11/27/19, 04:35:55.772 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected
 to pluggable transport
 11/27/19, 04:36:04.205 [NOTICE] Bootstrapped 10% (conn_done): Connected to
 a relay
 11/27/19, 04:36:34.351 [WARN] Problem bootstrapping. Stuck at 10%
 (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation
 warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
 11/27/19, 04:36:34.351 [WARN] 1 connections have failed:
 11/27/19, 04:36:34.351 [WARN] 1 connections died in state handshaking
 (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
 11/27/19, 04:36:34.377 [NOTICE] Closing no-longer-configured Socks
 listener on 127.0.0.1:9150
 11/27/19, 04:36:34.377 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/27/19, 04:36:34.378 [WARN] Pluggable Transport process terminated with
 status code 0

 I upload my state file.
 Thank you very much for your help. I really appreciate 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] #32398 [Core Tor/Stem]: Stem str/bytes confusion on error

[Tor Bug Tracker & Wiki]

#32398: Stem str/bytes confusion on error
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by ltbringer):

 How can one reproduce this? I tried running the tests on stem and I don't
 see this particular test failing.

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

Re: [tor-bugs] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nDe15o):

 It would be really great to have it earlier :)
 Thank you.

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

Re: [tor-bugs] #32626 [Core Tor/Tor]: Remove extra space in #define in ed25519-donna-portable-identify.h

[Tor Bug Tracker & Wiki]

#32626: Remove extra space in #define in ed25519-donna-portable-identify.h
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review
 * keywords:   => easy
 * component:  - Select a component => Core Tor/Tor


Comment:

 PR: https://github.com/torproject/tor/pull/1572

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32626 [- Select a component]: Remove extra space in #define in ed25519-donna-portable-identify.h

[Tor Bug Tracker & Wiki]

#32626: Remove extra space in #define in ed25519-donna-portable-identify.h
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This line:

 {{{
 #if defined(__amd64__) || defined(__amd64) || defined(__x86_64__ ) ||
 defined(_M_X64)
 }}}

 should be:

 {{{
 #if defined(__amd64__) || defined(__amd64) || defined(__x86_64__) ||
 defined(_M_X64)
 }}}

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

Re: [tor-bugs] #32536 [Applications/Tor Browser]: Security level set to "Safest" but JavaScript still Enabled.

[Tor Bug Tracker & Wiki]

#32536: Security level set to "Safest" but JavaScript still Enabled.
--+--
 Reporter:  tor70001  |  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:
--+--

Comment (by cypherpunks):

 Just refreshed https://blog.torproject.org/ after hibernation and got
 again:
 {{{
 [11-27 04:03:27] Torbutton INFO: tor SOCKS: https://255.255.255.255/moz-
 extension://[NS
 
UUID]%2Chttps%3A%2F%2Fblog.torproject.org%2F&url=https%3A%2F%2Fblog.torproject.org%2F&top=true&suspend=true
 via
torproject.org:bd3c437faec67f5a4d99a05f1db64101
 [11-27 04:03:27] Torbutton INFO: controlPort >> 650 STREAM 468 NEW 0
 255.255.255.255:443 SOURCE_ADDR=127.0.0.1:52645 PURPOSE=USER
 [11-27 04:03:27] Torbutton INFO: controlPort >> 650 STREAM 468 SENTCONNECT
 81 255.255.255.255:443
 Error: Could not establish connection. Receiving end does not exist.
 SyncMessage.js:193:25
 [11-27 04:03:28] Torbutton INFO: controlPort >> 650 STREAM 468 DETACHED 81
 255.255.255.255:443 REASON=END REMOTE_REASON=NOROUTE
 ...
 }}}

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

Re: [tor-bugs] #28280 [Core Tor/Tor]: control: Add a key to GETINFO to get the DoS subsystem stats

[Tor Bug Tracker & Wiki]

#28280: control: Add a key to GETINFO to get the DoS subsystem stats
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Low|  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec, needs-spec  |  Actual Points:  0.1
Parent ID: | Points:
 Reviewer:  teor, dgoulet  |Sponsor:
---+---

Comment (by moonsikpark):

 I agree that changing control-spec first is the way to go.

 I'll wait for dgoulet's comment on how this should be done.

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

Re: [tor-bugs] #32614 [Core Tor/Tor]: hs-v3: Consider flagging an intro point as bad if rendezvous fails multiple times

[Tor Bug Tracker & Wiki]

#32614: hs-v3: Consider flagging an intro point as bad if rendezvous fails 
multiple
times
-+--
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, tor-hs  |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:  Sponsor27-can
-+--
Changes (by neel):

 * keywords:  tor-circuit, -tor-hs => tor-circuit, tor-hs


Comment:

 Fix keywords.

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

Re: [tor-bugs] #32625 [Core Tor/Tor]: If statements to getresuid() and getresgid() in setuid.c shouldn't have an extra space.

[Tor Bug Tracker & Wiki]

#32625: If statements to getresuid() and getresgid() in setuid.c shouldn't have 
an
extra space.
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => closed
 * resolution:   => fixed
 * milestone:   => Tor: 0.4.3.x-final


Comment:

 Thanks, looks good, merged to 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] #32500 [Core Tor/Tor]: consider clang -std=gnu99 in Travis for better C99 portability

[Tor Bug Tracker & Wiki]

#32500: consider clang -std=gnu99 in Travis for better C99 portability
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  portability, tor-ci, 029-backport,   |  Actual Points:  0.3
  035-backport, 040-backport, 041-backport,  |
  042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-

Comment (by teor):

 Thanks for helping diagnose that. I merged the two env lists, and re-
 merged all the branches.

 (I couldn't find another matrix entry, most of the rest of them disable
 large amounts of code.)

 Here are the PRs for review:
 * 0.2.9: ​​https://github.com/torproject/tor/pull/1539
 * 0.3.5: ​​https://github.com/torproject/tor/pull/1540

 Test branches are here:
 * ​https://travis-ci.org/teor2345/tor/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] #31531 [Core Tor/Tor]: Make control_event_conf_changed() take a smartlist of config_line_t

[Tor Bug Tracker & Wiki]

#31531: Make control_event_conf_changed() take a smartlist of config_line_t
+
 Reporter:  teor|  Owner:  neel
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  catalyst|Sponsor:  Sponsor31-can
+
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 Fixed 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] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

[Tor Bug Tracker & Wiki]

#32579: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case
statements
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Here's a working reference:
 
https://releases.llvm.org/9.0.0/tools/clang/docs/AttributeReference.html#fallthrough

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

Re: [tor-bugs] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

[Tor Bug Tracker & Wiki]

#32579: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case
statements
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 If we are doing it, we're doing it wrong, here's a fallthrough that should
 require the fallthrough attribute:
 {{{
 src/core/proto/proto_socks.c-  case SOCKS_RESULT_TRUNCATED:
 src/core/proto/proto_socks.c-if (datalen == n_pullup)
 src/core/proto/proto_socks.c-  return 0;
 src/core/proto/proto_socks.c-/* FALLTHRU */
 src/core/proto/proto_socks.c-  case SOCKS_RESULT_MORE_EXPECTED:
 src/core/proto/proto_socks.c-res = 0;
 src/core/proto/proto_socks.c-break;
 }}}

 I don't think comments count, and even if they do, I can't imagine this
 spelling being supported :-)

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

Re: [tor-bugs] #32625 [Core Tor/Tor]: If statements to getresuid() and getresgid() in setuid.c shouldn't have an extra space.

[Tor Bug Tracker & Wiki]

#32625: If statements to getresuid() and getresgid() in setuid.c shouldn't have 
an
extra space.
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PR: https://github.com/torproject/tor/pull/1571

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32625 [Core Tor/Tor]: If statements to getresuid() and getresgid() in setuid.c shouldn't have an extra space.

[Tor Bug Tracker & Wiki]

#32625: If statements to getresuid() and getresgid() in setuid.c shouldn't have 
an
extra space.
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In `setuid.c`:

 {{{
 src/lib/process/setuid.c:  if (getresuid(&ruid, &euid, &suid) != 0 ) {
 src/lib/process/setuid.c:  if (getresgid(&rgid, &egid, &sgid) != 0 ) {
 }}}

 These if statements to `getresuid()` and `getresgid()` shouldn't have an
 extra space.

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

Re: [tor-bugs] #32581 [Core Tor/Tor]: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors

[Tor Bug Tracker & Wiki]

#32581: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I looked for it, but I must have been looking in the wrong file.

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

Re: [tor-bugs] #32614 [Core Tor/Tor]: hs-v3: Consider flagging an intro point as bad if rendezvous fails multiple times

[Tor Bug Tracker & Wiki]

#32614: hs-v3: Consider flagging an intro point as bad if rendezvous fails 
multiple
times
--+--
 Reporter:  dgoulet   |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit, -tor-hs  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:  Sponsor27-can
--+--
Changes (by neel):

 * status:  new => assigned
 * cc: neel (added)
 * owner:  (none) => neel


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

Re: [tor-bugs] #32613 [Core Tor/Tor]: Simple tests for checkSpaces.pl

[Tor Bug Tracker & Wiki]

#32613: Simple tests for checkSpaces.pl
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:  #32522| Points:  .1
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:1 nickm]:
 > I have a test as ticket32613 with PR at
 https://github.com/torproject/tor/pull/1569

 Looks fine, please fix a typo in a function name.

 > This isn't automated, since we only need to run it when we change our
 checkSpace.pl script.

 I think we should run it in "make check" (CI), and the commit hook for
 these reasons:
 * it's fast
 * if the CI environment breaks, it's important to have known-good tests
 for diagnostics
 * CI helps us make sure that any changes work on Linux and macOS, across a
 variety of environments
 * we're going to change this script at least three times in the next few
 months, in #32610, #29226 (perhaps multiple times), and when we replace it
 with python
 * developers don't usually remember to run extra tests :-)

 And skipping Windows is easy, we have plenty of scripts that do that.

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

Re: [tor-bugs] #31531 [Core Tor/Tor]: Make control_event_conf_changed() take a smartlist of config_line_t

[Tor Bug Tracker & Wiki]

#31531: Make control_event_conf_changed() take a smartlist of config_line_t
+
 Reporter:  teor|  Owner:  neel
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  catalyst|Sponsor:  Sponsor31-can
+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:6 neel]:
 > New PR using `config_line_t`:
 https://github.com/torproject/tor/pull/1570
 Thanks! That looks simpler. I made some comments on that pull request,
 mostly about minor things. Note that currently the pull request fails
 Travis due to a memory leak that I describe in the comments.

 Please feel free to force-push this pull request with your updates.

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

Re: [tor-bugs] #32613 [Core Tor/Tor]: Simple tests for checkSpaces.pl

[Tor Bug Tracker & Wiki]

#32613: Simple tests for checkSpaces.pl
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:  #32522| Points:  .1
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * parent:   => #32522


Comment:

 Seems somewhat related to #32522, and possibly conflicting with #32610.

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

Re: [tor-bugs] #32610 [Core Tor/Tor]: Add macro spacing checks to "make check-spaces"

[Tor Bug Tracker & Wiki]

#32610: Add macro spacing checks to "make check-spaces"
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  0.4
Parent ID:  #32522 | Points:  0.2
 Reviewer:  nickm  |Sponsor:  Sponsor31-can
---+---

Comment (by teor):

 Possibly conflicting with #32613.

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

Re: [tor-bugs] #28280 [Core Tor/Tor]: control: Add a key to GETINFO to get the DoS subsystem stats

[Tor Bug Tracker & Wiki]

#28280: control: Add a key to GETINFO to get the DoS subsystem stats
---+---
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Low|  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec, needs-spec  |  Actual Points:  0.1
Parent ID: | Points:
 Reviewer:  teor, dgoulet  |Sponsor:
---+---
Changes (by teor):

 * keywords:  tor-control, tor-spec => tor-control, tor-spec, needs-spec
 * reviewer:   => teor, dgoulet
 * milestone:  Tor: unspecified => Tor: 0.4.3.x-final
 * actualpoints:   => 0.1


Comment:

 Thanks for this code!

 > I'd like to make changes to control-spec.txt after, not before this PR's
 review, if that's OK.

 I think it would be best if we agreed on a design first? Having a spec is
 a good way to agree on a design.

 A few design notes:
 1. We might want a `dos` GETINFO category, with subcategories for each
 type of DoS.
 2. I don't know if we will want individual keys in each subcategory.
 3. We can do rollups of each sub-category and category, if we want.
 4. We should list all DoS variables as keys, including the `*_enabled`
 variables

 A few formatting notes:
 1. All the names should be in a consistent format.
 2. We probably want to use the existing lowercase-hyphen format.
 3. Most of our controller names aren't plural.
 4. All values should be numeric (not `False`)
 5. We probably want values separated by newlines, to match existing
 GETINFOs. See `downloads/` for an example.
 https://github.com/torproject/torspec/blob/master/control-spec.txt#L1008

 A few implementation notes:
 1. The code will be easier to maintain if you use smartlist_add_asprintf()
 for each key=value, and smartlist_join_strings() at the end.
 2. The code will be even easier to maintain if you write a function that
 checks `*_enabled`, formats the key=value, and returns a newly allocated
 string. Then you can just pass the key name, the `*_enabled` variable, and
 the actual variable to the function.

 There are also some minor issues with the code, I added comments on the
 pull request.

 I'd like to check this advice with the developer who wrote the DoS code,
 so I'm assigning this ticket to them for 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] #31531 [Core Tor/Tor]: Make control_event_conf_changed() take a smartlist of config_line_t

[Tor Bug Tracker & Wiki]

#31531: Make control_event_conf_changed() take a smartlist of config_line_t
+
 Reporter:  teor|  Owner:  neel
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  catalyst|Sponsor:  Sponsor31-can
+
Changes (by neel):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #31531 [Core Tor/Tor]: Make control_event_conf_changed() take a smartlist of config_line_t

[Tor Bug Tracker & Wiki]

#31531: Make control_event_conf_changed() take a smartlist of config_line_t
+
 Reporter:  teor|  Owner:  neel
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  catalyst|Sponsor:  Sponsor31-can
+

Comment (by neel):

 New PR using `config_line_t`: https://github.com/torproject/tor/pull/1570

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

Re: [tor-bugs] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 FYI: testing in TB 8.5.5, the same issue exists: i.e `test 1` (2 tabs),
 and obviously next_gen doesn't exist in ESR60. It's not a regression, LSNG
 is an enhancement, and people have been living with this "bug" in TB and
 Firefox for a long, long time. IMO, the only question is when does TB get
 LSNG: next ESR or 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] #32331 [Applications/Tor Browser]: Tor Browser 9 on Lineage OS 14.1 stalls during start-up

[Tor Bug Tracker & Wiki]

#32331: Tor Browser 9 on Lineage OS 14.1 stalls during start-up
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-issues, tbb-regression,  |  Actual Points:
  tbb-9.1.0-can, TorBrowserTeam201912|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:2 sisbell]:
 > Replying to [comment:1 sysrqb]:
 > > There's a new orbot release candidate upgrading the tor version to
 `0.4.1.6` with the hope this fixes it. We can try picking this up, too.
 >
 > Are we looking at adding this to tor-android-service as a binary or
 using the newest build for Android tor in the browser build?
 I meant updating TOPL's dependency on tor-android-binary.

 I'm not sure how I should interpret the below orbot bug report, because
 I'm not sure if the new update (16.1.3) resolved the problem or if
 downgrading and then upgrading somehow resolved it. We should still bump
 the tor version, in any case.

 https://github.com/guardianproject/orbot/issues/263#issuecomment-551192492

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

Re: [tor-bugs] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Thorin):

 * priority:  Very High => Medium
 * severity:  Critical => 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] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 This is not a TB only issue

 Test page: use
 https://ghacksuserjs.github.io/TorZillaPrint/sanitizing.html

 **STR**
 - `test 1`: new identity, open in two different tabs
 - `test 2`: new identity, open in one tab and hit F5 (refresh) .. and
 after that result hit F5 again ... etc
 - `test 3`: new identity, open in one tab and hit Ctrl-F5 (hard refresh)
 .. keep testing it
 - `test 4`: new identity, open in one tab and hit re-run, or hit F5
 (refresh)

 ** RESULTS**
 - `test 1`: 2 tabs: localStorage key and value is not found
 - `test 2`: 1 tab + F5: intermittent results
 - `test 3`: 1 tab + ctrl-F5: intermittent results
 - `test 4`: 1 tab + re-rerun button: localStorage key and value is found

 I had this issue with sanitizing (in Firefox, portable) that started in
 FF62 (from memory, but I never picked up on it until FF68) and tested FF62
 thru to current, literally a thousand plus tests over time especially in
 FF68+ (and I still test every day when I flick open various FF versions
 for other tests), and had quite a bit of an email thread with Johann
 Hofmann about it.

 long story short: localStorage is a bit wonky, and the fix that solved it
 all was to move to LSNG (dom.storage.next_gen)

 ---

 aand... just to confirm it... doing test 1 (2 tabs)

 Firefox (nightly)
 - LSNG = false, new pb window, LS **does not** persist across tabs
 - LSNG = true (default), new pb window, LS **does** persist across tabs


 TB
 - LSNG = false (default), new id, LS **does not** persist across tabs
 - LSNG = true, new id, LS **does** persist across tabs
 - **don't forget to change LSNG back to default**

 The thing is next_gen was not flipped on until FF70, and then they flipped
 it back in 70.0.1 due to issues that AFAIK shouldn't affect TB since it
 doesn't have persistent data.

 I don't think LSNG = true would necessarily be ready for ESR68, but might
 be perfectly fine given TB's setup (PB mode etc). I'll ping Johann

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

Re: [tor-bugs] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nDe15o):

 I've found this issue https://bugzilla.mozilla.org/show_bug.cgi?id=1453699
 https://bugzilla.mozilla.org/show_bug.cgi?id=1453699#c11
 I tried to set `dom.storage.next_gen` to `true` in `about:config` and
 restarted Tor Browser. Now everything is ok.
 Please add this to the default config of 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] #32616 [Applications/Tor Browser]: disable GetSecureOutputDirectoryPath() functionality

[Tor Bug Tracker & Wiki]

#32616: disable GetSecureOutputDirectoryPath() functionality
--+
 Reporter:  mcs   |  Owner:  mcs
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update,TorBrowserTeam201911R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by mcs:

Old description:

> Even though the code paths that end in `GetSecureOutputDirectoryPath()`
> should not be taken in Tor Browser, want to avoid any chance that the
> updater will create files under `C:\Program Files (x86)` or a similar
> location. Therefore we will stub out the body of
> `GetSecureOutputDirectoryPath()` and have it return an error.

New description:

 Even though the code paths that end in `GetSecureOutputDirectoryPath()`
 should not be taken in Tor Browser, we want to avoid any chance that the
 updater will create files under `C:\Program Files (x86)` or a similar
 location. Therefore we will stub out the body of
 `GetSecureOutputDirectoryPath()` and have it return an error.

--

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

Re: [tor-bugs] #32609 [Core Tor/Tor]: Improve practracker unit tests, and run them in "make check" and pre-commit

[Tor Bug Tracker & Wiki]

#32609: Improve practracker unit tests, and run them in "make check" and 
pre-commit
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  test, network-team-roadmap-november  |  Actual Points:  0.4
Parent ID:  #32522   | Points:  0.4
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-can
-+-

Comment (by teor):

 Replying to [comment:3 nickm]:
 > > This isn't quite the fix I wanted, so I'd like your advice.
 >
 > The commits themselves look okay to me.  Is the issue the one that you
 mention here?

 Yes, the `#include "feature/dircache/dirserv.c"` in test_controller.c.

 > > Is there a way we can restrict includes to ".h" and ".inc"?
 > > Perhaps with some custom code in practracker includes.py?
 >
 > We could add a .may_include to all directories, starting with "*.h" and
 "*.inc".  Then practracker would start looking at them.  Does that do what
 you want?

 No, because practracker just logs a warning, which most people ignore.
 (And CI doesn't fail.) We really do need to fail on weird include patterns
 like this.

 > Right now it looks like there are some places where we include .c files
 intentionally.  And arguably we should rename ".i" to ".inc"
 >
 > {{{
 > [1424]$ git grep '#include' src/ |grep -v '.\(h\|inc\)[>"]'
 > src/ext/ed25519/donna/ed25519_tor.c:#include "test-internals.c"
 > src/ext/ed25519/donna/fuzz/ed25519-donna-sse2.c:#include "../ed25519.c"
 > src/ext/ed25519/donna/fuzz/ed25519-donna.c:#include "../ed25519.c"
 > src/ext/timeouts/bench/bench-wheel.c:#include "timeout.c"
 > src/ext/timeouts/lua/timeout-lua.c:#include "timeout.c"
 > src/ext/timeouts/timeout.c:#include "ext/timeouts/timeout-bitops.c"
 > src/lib/evloop/timers.c:#include "ext/timeouts/timeout.c"
 > src/lib/fs/files.c:#include "ext/getdelim.c"
 > src/lib/string/compat_string.c:#include "ext/strlcpy.c"
 > src/lib/string/compat_string.c:#include "ext/strlcat.c"
 > src/lib/version/git_revision.c:#include "micro-revision.i"
 > src/lib/version/git_revision.c:#include "micro-revision.i"
 > }}}

 If we:
 * ignore "ext" (including and being included), and
 * rename micro-revision.i to micro-revision.inc,
 then we can restrict includes to ".h" and ".inc".

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

Re: [tor-bugs] #32517 [Core Tor/Tor]: make check Message After Testsuite Summary

[Tor Bug Tracker & Wiki]

#32517: make check Message After Testsuite Summary
--+
 Reporter:  werd  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.4-rc
 Severity:  Normal| Resolution:  not a bug
 Keywords:  practracker   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * priority:  High => Medium
 * status:  new => closed
 * resolution:   => not a bug
 * keywords:   => practracker
 * milestone:   => Tor: 0.4.2.x-final


Comment:

 Thanks for letting us know. These warnings are internal checks that tell
 us where our code quality is getting worse. You shouldn't need to worry
 about 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] #32463 [Core Tor/Tor]: TypeError in practracker "includes.py" script

[Tor Bug Tracker & Wiki]

#32463: TypeError in practracker "includes.py" script
---+
 Reporter:  opara  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:  fixed
 Keywords:  BugSmashFund?  |  Actual Points:  0.1
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  new => closed
 * keywords:   => BugSmashFund?
 * resolution:   => fixed
 * actualpoints:   => 0.1


Comment:

 Thanks, I fixed this in ab70c315bdd72ee7578b8b8ee4077172e0181f36 and
 merged it to 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] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nDe15o):

 But if I close the second tab and open the page in another tab again,
 there's again no value in this new tab.

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

Re: [tor-bugs] #32249 [Core Tor/Tor]: Speed up practracker, by passing it a list of modified file names

[Tor Bug Tracker & Wiki]

#32249: Speed up practracker, by passing it a list of modified file names
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can   |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:  Sponsor31-can
--+

Old description:

> After #31919, the git hooks will know which files have been modified in
> the commit/push. We should pass those files to practracker.

New description:

 After #31919, the git hooks will know which files have been modified in
 the commit/push. We should pass those files to practracker.py and
 practracker/includes.py.

--

Comment (by teor):

 This fix will also resolve a spurious practracker/includes.py warning:
 {{{
 Unusual pattern permitted.h in ./scripts/maint/practracker/testdata
 }}}

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

Re: [tor-bugs] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
--+--
 Reporter:  nDe15o|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nDe15o):

 It's strange: if after step 5 I do `localStorage['test']=2` in the second
 tab, the value also changes in the first tab to "2".

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

Re: [tor-bugs] #32610 [Core Tor/Tor]: Add macro spacing checks to "make check-spaces"

[Tor Bug Tracker & Wiki]

#32610: Add macro spacing checks to "make check-spaces"
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-team-roadmap-november  |  Actual Points:  0.4
Parent ID:  #32522 | Points:  0.2
 Reviewer:  nickm  |Sponsor:  Sponsor31-can
---+---
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 I fixed the patch so all 4 lists of Tor C files are consistent.

 Replying to [comment:4 nickm]:
 > (Before we spend too much time on this, let's also make sure it's
 something that our code autoformatter won't take care of for us, so that
 the effort isn't redundant)

 I think we're still some time away from automated C formatting. We should
 trial `make autostyle` first, see #31713. I think I finally fixed the last
 few instances of #31891 on Monday.

 I discovered these issues during #32522, I don't expect to spend any more
 time on check-spaces. It is an improvement, and it shouldn't take much
 time to review.

 I suggest we merge now, and then remove redundant (or conflicting) parts
 of check-spaces when we implement C autoformatting?

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

Re: [tor-bugs] #32574 [Internal Services/Service - github tpo]: set up mirror repo on GitHub torproject/jtorctl

[Tor Bug Tracker & Wiki]

#32574: set up mirror repo on GitHub torproject/jtorctl
-+-
 Reporter:  eighthave|  Owner:  hiro
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - github   |Version:
  tpo|
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32534   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 eighthave]:
 > Thanks Hiro!  It seems that the sync is not pushing commits from
 https://gitweb.torproject.org/jtorctl to GitHub, because the GitHub
 project is still blank.

 The pusher requires write permissions to the repository to do a sync. I
 added the `pushers` group with the correct permissions. The next commit
 should trigger a sync.

 If anyone wants to be able to handle pull requests or CI for the
 repository, they'll also need write permissions. Please let us know which
 GitHub users need write permissions, and we'll put them in the jtorctl-
 maintainers team on GitHub. (It has write permissions, but there's no-one
 in it.)

 In the meantime, I turned off a bunch of optional features, like wikis and
 issues, to avoid spam. Let us know if you need them turned back on.

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

[tor-bugs] #32624 [Applications/Tor Browser]: localStorage is not shared between tabs

[Tor Bug Tracker & Wiki]

#32624: localStorage is not shared between tabs
---+--
 Reporter:  nDe15o |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Very High  |  Component:  Applications/Tor Browser
  Version: |   Severity:  Critical
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Steps to reproduce:
 1. open some web site
 2. open the same page in another tab
 3. open Web Console in both tabs
 4. set `localStorage['test']=1` in the first tab
 4. try to get the value of `localStorage['test']` in the second tab.

 Result:
 The value is undefined.

 Expected result:
 The value is 1.

 Tor Browser 9.0.1. Tested on onion sites with enabled js.

 Please, please fix this, it is very important, I've developed an app that
 relies on this functionality and I didn't expect that there will such
 problems with localStorage. Please don't tell me that this behavior is
 intentional. It shouldn't be for the same origin.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32623 [- Select a component]: Tor Browser should support ENS

[Tor Bug Tracker & Wiki]

#32623: Tor Browser should support ENS
-+--
 Reporter:  bryguy   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 **New Feature Proposal**

 Tor Browser should recognize, process and follow ENS (see
 [https://docs.ens.domains]) links formatted as such:

   `ens://name.eth`

 or simply:

   `name.eth`

 Note that `name` is a sequence of one or more labels internally separated
 by a period.

 ENS enables anyone with access to Internet to interact with Ethereum
 blockchain and register a name to end in `.eth`. Anyone can remain
 anonymous if they take care of their Ethereum address/es.

 ENS has a text record type. An owner might provide a `.onion` URL for
 this. Tor Browser could automatically resolve an ENS name and lookup its
 text record - if that ends in `.onion` then Tor Browser could follow the
 link.

 Registration is an open and fair process. Names are inexpensive: ~ $5/yr
 for a name of 5 characters and up.

 Any name owner can make subdomains and register new names therein.

 Such a capability would enable Tor users to optionally enjoy DNS-like
 convenience of using `.eth` names instead of
 `.onion` strings.

 **Suggested Scope**

  * Add a new protocol handler that recognizes `ens://` and `.eth` urls,
 similar to the way an existing protocol handler recognizes `http://`
 today.

  * Enable the user to specify a number of `.onion`s known to provide
 RESTful ENS-to-onion lookup service. Tor Browser should use a random-
 round-robin approach to select one such `.onion` for each query. The
 implementation ''might'' occasionally cross-check the results of any query
 from multiple `.onion`s as a public service to expose miscreant `.onion`
 operators.

  * Tor project should publish a new standard syntax for ENS name-to-onion
 and name-search RESTful queries.

  * Tor project should implement one such ENS nameserver. We suggest that
 `eff.org` and perhaps other privacy-supportive organizations may wish to
 do the same.

  * Tor project should buy an ENS name and renew it yearly for a minimum of
 five years. We suggest `torproject.eth`

  * Tor project could set up a custom Registrar smart contract and sell
 subdomains under `.torproject.eth` to offset costs of running the ENS
 nameserver.

  * Tor project could subdomain and sell names to raise donations for
 specific projects and initiatives. For example, Tor project might register
 `killcaptchas.torproject.eth` and enable donors to purchase names under
 that if they wish to support such an initiative.

  * Tor Browser should support an ENS-search capability that scans the
 blockchain for all names within a user-specified `.eth` domain.

 **Motivations**

  * Improve Tor Browser and network user-experience by providing "anonymous
 names" capability

  * Support a Tor-search capability without requiring centralized
 `.onion`s. An ENS-to-onion nameserver might implement an additional query
 to return all registered names within a given subdomain.

  * Disrupt IANA's monopoly on Internet names

  * Support anonymous Internet usage

  * Save internet users the significant costs of registering and renewing
 DNS names. A tld might require a $200k fee to IANA just to process a
 proposal. A country domain can cost $50/yr and a web-commerce certificate
 can cost $100's to obtain and similar to renew each year.


 **Challenges and Risks**

 * This proposal changes Tor Browser code. Although plugins and extensions
 are well-understood, this incurs some risk and potential future expense
 for maintenance and support.

 * ENS might not become popular enough. It caters to a small set of users
 who are comfortable with Tor ''and'' Ethereum.

 * The price of Ethereum may increase and make ENS too expensive to use.

 * The owner of `.eth` may increase the cost of renewal. While the
 community would migrate away to a similar service, this would again
 require Tor Browser to update.

 * Few users may hear about `ens://` urls and accept that they work with
 the same level of anonymity granted by Tor.

 * Ethereum may disappear someday (unlikely, but you never know)

 * Blockchain tech invites attention from governments and other
 organizations that feel threatened by 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] #31834 [Circumvention]: Make obfs4 Docker image more usable

[Tor Bug Tracker & Wiki]

#31834: Make obfs4 Docker image more usable
---+---
 Reporter:  phw|  Owner:  phw
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  docker, s30-o24a2  |  Actual Points:  1.1
Parent ID:  #31281 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by phw):

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


Comment:

 Replying to [comment:18 thymbahutymba]:
 > env is the name of the file where the configuration is located.
 [[br]]
 You are right, I missed that.

 After giving this some more thought, I decided to move forward with a
 tradeoff. I agree with thymbahutymba that the bridge information should be
 stored in a file; otherwise operators will have to dig up their ports each
 time they're upgrading the image. Our
 [https://community.torproject.org/relay/setup/bridge/docker/ improved
 instructions] now suggest to write your bridge configuration to a separate
 file, which is sourced before invoking the Makefile. This makes it
 possible to run multiple bridges (by having several bridge config files)
 while at the same time making it easy to upgrade to new image versions.
 Also note that running multiple bridges per machine is an edge case that
 we don't encourage.

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

Re: [tor-bugs] #32580 [Core Tor/Tor]: Use clang's enum_extensibility attribute to check enum values

[Tor Bug Tracker & Wiki]

#32580: Use clang's enum_extensibility attribute to check enum values
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:2 nickm]:
 > That first link (https://clang.llvm.org/docs/AttributeReference.html
 #enum-extensibility) gives me an empty page. Is there a better place to
 find out what this is?

 That's really weird, I see that too. But it worked a few days ago. And
 some search engines still have it indexed :-)

 Here's the version from clang 9.0.0, the latest release:
 https://releases.llvm.org/9.0.0/tools/clang/docs/AttributeReference.html
 #enum-extensibility

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32622 [Core Tor/Tor]: Fix misleading STATUS_CLIENT warning message

[Tor Bug Tracker & Wiki]

#32622: Fix misleading STATUS_CLIENT warning message
--+
 Reporter:  phw   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 After Tor 0.4.3.0-alpha-dev successfully established a TCP connection with
 a bridge but failed to finish its handshake, it sends the following
 `STATUS_CLIENT` message to the controller:
 {{{
 650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TAG=handshake_dir
 SUMMARY="Finishing handshake with directory server" WARNING="DONE"
 REASON=DONE COUNT=1 RECOMMENDATION=warn
 HOSTID="" HOSTADDR="[scrubbed]"
 }}}

 One can reproduce this by using torproject.org's web server as a bridge:
 95.216.163.36:80. The substring `WARNING="DONE"` is misleading and should
 – if I'm interpreting [https://gitweb.torproject.org/torspec.git/tree
 /control-spec.txt#n2682 control-spec.txt] correctly – contain a human-
 readable description of what went wrong.  Other `STATUS_CLIENT` messages
 do a better job; for example:
 {{{
 650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir
 SUMMARY="Connecting to directory server" WARNING="Connection refused"
 REASON=CONNECTREFUSED COUNT=1 RECOMMENDATION=warn
 HOSTID="" HOSTADDR="[scrubbed]"
 }}}
 Here, the substring `WARNING="Connection refused"` gives me a good idea of
 what's going on.

 I suggest to fix the warning in this particular error 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] #31531 [Core Tor/Tor]: Make control_event_conf_changed() take a smartlist of config_line_t

[Tor Bug Tracker & Wiki]

#31531: Make control_event_conf_changed() take a smartlist of config_line_t
+
 Reporter:  teor|  Owner:  neel
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  catalyst|Sponsor:  Sponsor31-can
+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:2 neel]:
 > PR: https://github.com/torproject/tor/pull/1558
 Thanks! This mostly looks good.

 `config_line_t` is already a linked list; why not pass that linked list to
 `control_event_conf_changed()` instead of repackaging it into a smartlist?
 That seems to me like it would be simpler.

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

Re: [tor-bugs] #32615 [Applications/Tor Browser]: New Fennec onboarding and activitystream conflicts

[Tor Bug Tracker & Wiki]

#32615: New Fennec onboarding and activitystream conflicts
--+--
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202001  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * keywords:   => TorBrowserTeam202001
 * priority:  High => Medium


Comment:

 Resolving the merge conflicts is actually relatively easy. We'll come back
 to this early next year.

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

Re: [tor-bugs] #32580 [Core Tor/Tor]: Use clang's enum_extensibility attribute to check enum values

[Tor Bug Tracker & Wiki]

#32580: Use clang's enum_extensibility attribute to check enum values
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 That first link (https://clang.llvm.org/docs/AttributeReference.html#enum-
 extensibility) gives me an empty page. Is there a better place to find out
 what this is?

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

Re: [tor-bugs] #4310 [Core Tor/Tor]: alphabetize torrc options within sections

[Tor Bug Tracker & Wiki]

#4310: alphabetize torrc options within sections
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:10 teor]:
 > I think this is a good first step, but I'd like to suggest some useful
 next steps:
 > * put some options into smaller categories, or sub-categories, so
 related options are near each other, and
 > * add automated checks to make sure the options stay in alphabetical
 order (within categories)
 >
 > These might be tasks for other tickets, or long-term tasks. That's ok.

 I opened #32620 and #32621 for these tasks.

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

[tor-bugs] #32621 [Core Tor/Tor]: Add automated checks to make sure man page options stay in alphabetical order

[Tor Bug Tracker & Wiki]

#32621: Add automated checks to make sure man page options stay in alphabetical
order
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  documentation tor-client manpage
 Severity:  Normal   |  easy
Actual Points:   |  Parent ID:  #4310
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 We should add automated checks or automated tooling that makes sure that
 the man page options are in alphabetical order (within sections).

 These tools will help us not regress #4310.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32620 [Core Tor/Tor]: Put man page options in smaller sections

[Tor Bug Tracker & Wiki]

#32620: Put man page options in smaller sections
+--
 Reporter:  teor|  Owner:  (none)
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core|Version:
  Tor/Tor   |
 Severity:  Normal  |   Keywords:  documentation tor-client manpage
Actual Points:  |  Parent ID:  #4310
   Points:  |   Reviewer:
  Sponsor:  |
+--
 After we sort alphabetically in #4310, some related options won't be near
 each other. We can fix this issue by having smaller man page sections.

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

Re: [tor-bugs] #4310 [Core Tor/Tor]: alphabetize torrc options within sections

[Tor Bug Tracker & Wiki]

#4310: alphabetize torrc options within sections
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


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

Re: [tor-bugs] #4310 [Core Tor/Tor]: alphabetize torrc options within sections

[Tor Bug Tracker & Wiki]

#4310: alphabetize torrc options within sections
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Hi swati,

 Replying to [comment:5 nickm]:
 > If you want to submit a patch, please make sure that it does '''nothing
 else''' besides reorder the manpage entries; otherwise, it will be hard to
 review.

 This patch re-orders manpage entries, but it also makes whitespace
 changes, for example:
 https://github.com/torproject/tor/pull/1567/files#diff-
 53a84e5af0d074614e6d722a25038cb7R277

 Some of these whitespace changes appear to be incorrect:
 https://github.com/torproject/tor/pull/1567/files#diff-
 53a84e5af0d074614e6d722a25038cb7R283

 Please make a pull request that only re-orders manpage option entries, and
 doesn't make any other changes.

 If you are using git, all the changes should be highlighted as "moved"
 with `git diff --color-moved`.

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

Re: [tor-bugs] #32500 [Core Tor/Tor]: consider clang -std=gnu99 in Travis for better C99 portability

[Tor Bug Tracker & Wiki]

#32500: consider clang -std=gnu99 in Travis for better C99 portability
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  portability, tor-ci, 029-backport,   |  Actual Points:  0.3
  035-backport, 040-backport, 041-backport,  |
  042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Further investigation reveals that `check-cocci` probably hasn't ever
 worked on Trusty because of an older version of coccinelle that has a
 harder time parsing our files.

 It looks like the setting of `env: C_DIALECT_OPTIONS="-std=gnu99"` in
 `.travis.yml` overrode the the existing `env: CHUTNEY="yes"
 CHUTNEY_ALLOW_FAILURES="2" SKIP_MAKE_CHECK="yes"` in that matrix entry,
 which likely caused `make check-cocci` to run for the first time on
 Trusty, unmasking a latent failure. (See https://travis-
 ci.org/tlyu/tor/builds/617437732 for a diagnostic.) The other Linux matrix
 entries run on Bionic.

 So we should probably attach the `gcc -std=gnu99` variant to a different
 matrix entry.

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

Re: [tor-bugs] #32619 [Core Tor]: fix syntax errors in torspec documents

[Tor Bug Tracker & Wiki]

#32619: fix syntax errors in torspec documents
---+
 Reporter:  eighthave  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  torspec|  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+
Changes (by nickm):

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


Comment:

 The output looks good, and the input changes look modest.  Merging to
 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] #32325 [Applications/Tor Browser]: Allow Letterboxing opt-in/out

[Tor Bug Tracker & Wiki]

#32325: Allow Letterboxing opt-in/out
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:9 pospeselr]:
 > Replying to [comment:8 antonela]:
 > > @pospesler, do you think we should explore another option for enabling
 it?
 >
 > This proposal as-is (pending final textual content) makes sense to me.
 >
 > @tom, do you think this is something that would be potentially uplifted
 to mozilla-central?

 I'm skeptical we could expose this on the preferences page. Especially
 without more work making it friendly and more understandable. But Arthur
 would be the person to ask, not 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] #32619 [Core Tor]: fix syntax errors in torspec documents

[Tor Bug Tracker & Wiki]

#32619: fix syntax errors in torspec documents
---+
 Reporter:  eighthave  |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torspec|  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+
Changes (by nickm):

 * status:  new => needs_review
 * reviewer:   => nickm
 * milestone:   => Tor: 0.4.3.x-final


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

[tor-bugs] #32619 [Core Tor]: fix syntax errors in torspec documents

[Tor Bug Tracker & Wiki]

#32619: fix syntax errors in torspec documents
---+--
 Reporter:  eighthave  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor
  Version: |   Severity:  Normal
 Keywords:  torspec|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 https://github.com/torproject/torspec/pull/95 fixes a handful of errors in
 the syntax of things like the title line and the section names.  That
 makes these files much more machine readable.  All of the changes here are
 trivial.

 With these changes, then a script can convert these files to a nice
 collection of HTML pages in a CI job that takes less than a minute to run:
 * https://gitlab.com/eighthave/torspec/-/jobs/362125193
 * https://eighthave.gitlab.io/torspec/

 This provides nice features like links to sections based on the section
 name:
 * https://eighthave.gitlab.io/torspec/control-spec.html#hsfetch
 * https://eighthave.gitlab.io/torspec/control-spec.html#circuit-status-
 changed
 * https://eighthave.gitlab.io/torspec/tor-spec.html#tls-security-
 considerations

 Using GitLab CI, this could easily rsync the result to any webserver.

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

Re: [tor-bugs] #32325 [Applications/Tor Browser]: Allow Letterboxing opt-in/out

[Tor Bug Tracker & Wiki]

#32325: Allow Letterboxing opt-in/out
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Replying to [comment:8 antonela]:
 > @pospesler, do you think we should explore another option for enabling
 it?

 This proposal as-is (pending final textual content) makes sense to me.

 @tom, do you think this is something that would be potentially uplifted to
 mozilla-central?

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

Re: [tor-bugs] #25101 [Applications/Tor Browser]: Generate incremental mar files for nightly builds

[Tor Bug Tracker & Wiki]

#25101: Generate incremental mar files for nightly builds
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:
  TorBrowserTeam201911R  |
Parent ID:  #18867   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks! Merged to `master` (commit
 d4460a92659808f8d29547197e23cb6defcf2f35).

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

Re: [tor-bugs] #32579 [Core Tor/Tor]: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements

[Tor Bug Tracker & Wiki]

#32579: Use clang's -Wimplicit-fallthrough and fallthrough attribute on case
statements
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 I believe we already enable that -- see configure.ac, and see
 "warning_flags" when building with clang.

 Please reopen if I'm wrong.

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

Re: [tor-bugs] #32581 [Core Tor/Tor]: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors

[Tor Bug Tracker & Wiki]

#32581: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 Please reopen if I am wrong 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] #32581 [Core Tor/Tor]: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors

[Tor Bug Tracker & Wiki]

#32581: Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  code-correctness  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 We have this already in our list of warnings that we enable if they are
 present:
 {{{
  -Wtentative-definition-incomplete-type
  -Wtrampolines
  -Wtype-safety
  -Wtypedef-redefinition
 }}}

 When I build with clang, it's in my warning_flags file:
 {{{
 ...-Wtentative-definition-incomplete-type -Wtype-safety -Wtypedef-
 redefinition -Wtypename-missing...
 }}}

 I think we already do 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] #32394 [Applications/Tor Browser]: Update Progress Bar doesn't use translations

[Tor Bug Tracker & Wiki]

#32394: Update Progress Bar doesn't use translations
--+--
 Reporter:  Zarko_Gjurov  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update, TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Zarko_Gjurov):

 I have said that because Mozilla from unknown reasons didn't include it
 in, even the string is translated more than 3 years ago. That was the
 strange thing.

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

Re: [tor-bugs] #32500 [Core Tor/Tor]: consider clang -std=gnu99 in Travis for better C99 portability

[Tor Bug Tracker & Wiki]

#32500: consider clang -std=gnu99 in Travis for better C99 portability
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  portability, tor-ci, 029-backport,   |  Actual Points:  0.3
  035-backport, 040-backport, 041-backport,  |
  042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-

Comment (by catalyst):

 Replying to [comment:9 teor]:
 > There's definitely something weird going on here.
 >
 > The -std=gnu99 flag shouldn't affect coccinelle, but maybe it's reading
 the contents of $CC, and interpreting them differently?
 > It's also weird that the gcc/trusty build fails, but the clang/macOS
 build passes.
 Yeah those inconsistencies bother me as well.

 Also I think coccinelle will see `CC=gcc` in its environment. (We pass
 `CC="$CC -std=gnu99"` to `./configure`, but that shouldn't change the `CC`
 environment variable.

 For what it's worth, I'm not able to reproduce this failure on Xenial.

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

Re: [tor-bugs] #25101 [Applications/Tor Browser]: Generate incremental mar files for nightly builds

[Tor Bug Tracker & Wiki]

#25101: Generate incremental mar files for nightly builds
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:
  TorBrowserTeam201911R  |
Parent ID:  #18867   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_revision => needs_review
 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam201911 => tbb-rbm, tbb-
 update, TorBrowserTeam201911R


Comment:

 Replying to [comment:9 gk]:
 > Just one nit:
 > {{{
 >   cd [% shell_quote(path(dest_dir)) %]/[%  c("version") %]
 > }}}
 > One whitespace too much between `%` and `c`.

 I fixed that in branch `bug_25101_v5`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25101_v5&id=d4460a92659808f8d29547197e23cb6defcf2f35

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

Re: [tor-bugs] #32618 [Applications/Tor Browser]: Backport 1467970 and 1590526

[Tor Bug Tracker & Wiki]

#32618: Backport 1467970 and 1590526
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by sysrqb):

 * keywords:   => TorBrowserTeam201911


Comment:

 We can try squeezing this into the 9.5a3.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32618 [Applications/Tor Browser]: Backport 1467970 and 1590526

[Tor Bug Tracker & Wiki]

#32618: Backport 1467970 and 1590526
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Mozilla landed a defense-in-depth security improvement, but they aren't
 planning on backporting it for esr68.

 1467970 is the original patch and 1590526 corrects some regressions.

 1467970: https://hg.mozilla.org/mozilla-central/rev/c8a2c27a1128


 1590526 (uplift on 71 beta): https://hg.mozilla.org/releases/mozilla-
 beta/rev/1542e80327c2

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

Re: [tor-bugs] #32616 [Applications/Tor Browser]: disable GetSecureOutputDirectoryPath() functionality

[Tor Bug Tracker & Wiki]

#32616: disable GetSecureOutputDirectoryPath() functionality
--+
 Reporter:  mcs   |  Owner:  mcs
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-update,TorBrowserTeam201911R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * keywords:  tbb-update,TorBrowserTeam201911 => tbb-
 update,TorBrowserTeam201911R
 * status:  assigned => needs_review


Comment:

 Here is a patch for review:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug32616-01&id=eaca94a2abaa4f185be1daf003886fe5872f9281

 Note that we did not do a Windows build.

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

Re: [tor-bugs] #31244 [Internal Services/Tor Sysadmin Team]: long term prometheus metrics

[Tor Bug Tracker & Wiki]

#31244: long term prometheus metrics
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i grew the server to 80GB, which resolves this for a year at least. we'll
 see how it goes from 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] #32616 [Applications/Tor Browser]: disable GetSecureOutputDirectoryPath() functionality

[Tor Bug Tracker & Wiki]

#32616: disable GetSecureOutputDirectoryPath() functionality
-+--
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-update,TorBrowserTeam201911  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mcs):

 * cc: tbb-team (added)
 * status:  new => assigned
 * owner:  tbb-team => mcs


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

Re: [tor-bugs] #32617 [Core Tor/Tor]: spec: Merge prop305 into rend-spec-v3.txt

[Tor Bug Tracker & Wiki]

#32617: spec: Merge prop305 into rend-spec-v3.txt
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop305, tor-spec  |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer:  asn|Sponsor:  Sponsor27-must
---+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Branch: `ticket32617_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] #32583 [Applications/Tor Browser]: No sound "failed to init cubeb"

[Tor Bug Tracker & Wiki]

#32583: No sound "failed to init cubeb"
--+--
 Reporter:  perceptron|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:  no_sound cubeb|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by perceptron):

 Ok, I've managed to get sound running in Tor-Browser.
 It works ok if Pulseaudio is started in system mode.

 Also I've found more precise problem analysis and its bypass in defect
 [https://trac.torproject.org/projects/tor/ticket/29360/ 29360].

 Pulseaudio in user mode prevents connection from Tor-Browser as its have
 wrong auth-cookie.
 Copying or creating a symlink to the proper ".esd_auth" from user's $HOME
 allows Browser to use sound server.

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

Re: [tor-bugs] #32603 [Internal Services/Service - cache]: cache servers do not reboot properly

[Tor Bug Tracker & Wiki]

#32603: cache servers do not reboot properly
---+-
 Reporter:  anarcat|  Owner:  anarcat
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - cache  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by anarcat):

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


Comment:

 reported in debian:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945551

 workaround deployed in puppet, tested with a reboot on cache01.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32617 [Core Tor/Tor]: spec: Merge prop305 into rend-spec-v3.txt

[Tor Bug Tracker & Wiki]

#32617: spec: Merge prop305 into rend-spec-v3.txt
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  prop305, tor-spec
Actual Points:  |  Parent ID:
   Points:  0.2 |   Reviewer:  asn
  Sponsor:  Sponsor27-must  |
+
 Now that #30924 was merged, we need to close prop305 and merge it in
 `rend-spec-v3.txt.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32616 [Applications/Tor Browser]: disable GetSecureOutputDirectoryPath() functionality

[Tor Bug Tracker & Wiki]

#32616: disable GetSecureOutputDirectoryPath() functionality
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-
 Severity:  Normal   |  update,TorBrowserTeam201911
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Even though the code paths that end in `GetSecureOutputDirectoryPath()`
 should not be taken in Tor Browser, want to avoid any chance that the
 updater will create files under `C:\Program Files (x86)` or a similar
 location. Therefore we will stub out the body of
 `GetSecureOutputDirectoryPath()` and have it return an error.

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

Re: [tor-bugs] #32613 [Core Tor/Tor]: Simple tests for checkSpaces.pl

[Tor Bug Tracker & Wiki]

#32613: Simple tests for checkSpaces.pl
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:  teor  |Sponsor:
--+
Changes (by nickm):

 * reviewer:   => teor


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

Re: [tor-bugs] #32613 [Core Tor/Tor]: Simple tests for checkSpaces.pl

[Tor Bug Tracker & Wiki]

#32613: Simple tests for checkSpaces.pl
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .1
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * actualpoints:   => .1


Comment:

 I have a test as ticket32613 with PR at
 https://github.com/torproject/tor/pull/1569

 This isn't automated, since we only need to run it when we change our
 checkSpace.pl script.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32615 [Applications/Tor Browser]: New Fennec onboarding and activitystream conflicts

[Tor Bug Tracker & Wiki]

#32615: New Fennec onboarding and activitystream conflicts
--+--
 Reporter:  sysrqb|  Owner:  sysrqb
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #32097, we reverted some changes in Fennec's Onboarding and
 activitystream UI. It seems like this isn't sustainable. Mozilla made more
 changes with 68.3.0. Let's take a different approach.

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

Re: [tor-bugs] #28280 [Core Tor/Tor]: control: Add a key to GETINFO to get the DoS subsystem stats

[Tor Bug Tracker & Wiki]

#28280: control: Add a key to GETINFO to get the DoS subsystem stats
---+--
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * status:  new => needs_review


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

Re: [tor-bugs] #28280 [Core Tor/Tor]: control: Add a key to GETINFO to get the DoS subsystem stats

[Tor Bug Tracker & Wiki]

#28280: control: Add a key to GETINFO to get the DoS subsystem stats
---+--
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by moonsikpark):

 PR: https://github.com/torproject/tor/pull/1568

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

Re: [tor-bugs] #30878 [Circumvention/Snowflake]: Set up snowbox to simulate censorship

[Tor Bug Tracker & Wiki]

#30878: Set up snowbox to simulate censorship
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-october  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by cohosh):

 * parent:  #29259 =>


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

Re: [tor-bugs] #32556 [Applications/Tor Browser]: Keep track of Mozilla's entitlements files

[Tor Bug Tracker & Wiki]

#32556: Keep track of Mozilla's entitlements files
+
 Reporter:  gk  |  Owner:  gk
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  TorBrowserTeam201911, tbb-sign  |  Actual Points:  0.2
Parent ID:  #32173  | Points:  0.2
 Reviewer:  |Sponsor:
+
Changes (by gk):

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


Comment:

 Okay, boklm seems to be good with putting the files under `tor-browser-
 build/tools/signing`. I added a bunch of script templates we are currently
 using for signing as well, as a first start. There is room for
 improvement, though. :)

 `master` has the changes (boklm looked over them): commit
 f1cc6bc762c337d9cbc7187d2958dcb54007f9ff.

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

Re: [tor-bugs] #32542 [Core Tor/Tor]: hs-v3: Add the 2 missing SOCKS extended errors from prop304

[Tor Bug Tracker & Wiki]

#32542: hs-v3: Add the 2 missing SOCKS extended errors from prop304
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #14389| Points:  1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+

Comment (by dgoulet):

 Discussion with asn on this:

 * We'll send back the `X'F2'` code if we get a NACK from every IP in the
 descriptor.

 * We'll send back the `X'F3'` code when the RP circuit _times out_. We'll
 need a spec clarification.

 * We'll send a *new* error code when all IP circuit timed out. Basically,
 if we try all IPs in the descriptor and they all gave us a circuit time
 out, we'll send back that code.

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

Re: [tor-bugs] #31632 [Core Tor/Tor]: hs-v3: Service doesn't re-upload descriptor on circuit failure

[Tor Bug Tracker & Wiki]

#31632: hs-v3: Service doesn't re-upload descriptor on circuit failure
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, 042-deferred-20190918  |  Actual Points:
Parent ID:  #30200 | Points:  0.5
 Reviewer:  asn|Sponsor:
   |  Sponsor27-must
---+---

Comment (by dgoulet):

 Need for #32020 to be merged upstream before I can fix 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] #25101 [Applications/Tor Browser]: Generate incremental mar files for nightly builds

[Tor Bug Tracker & Wiki]

#25101: Generate incremental mar files for nightly builds
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-update, |  Actual Points:
  TorBrowserTeam201911   |
Parent ID:  #18867   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, tbb-update, TorBrowserTeam201911R => tbb-rbm, tbb-
 update, TorBrowserTeam201911
 * status:  needs_review => needs_revision


Comment:

 Just one nit:
 {{{
   cd [% shell_quote(path(dest_dir)) %]/[%  c("version") %]
 }}}
 One whitespace too much between `%` and `c`.

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

Re: [tor-bugs] #31561 [Core Tor/Tor]: hs-v3: Service can keep unused intro points in its list

[Tor Bug Tracker & Wiki]

#31561: hs-v3: Service can keep unused intro points in its list
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, hv-v3   |  Actual Points:  0.1
Parent ID:  #30200  | Points:  0.2
 Reviewer:  asn, mikeperry  |Sponsor:  Sponsor27-must
+--

Comment (by dgoulet):

 Need for #32020 to be merged upstream before I can fix 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] #27842 [Core Tor/Tor]: Consider end-to-end introduction ACKs

[Tor Bug Tracker & Wiki]

#27842: Consider end-to-end introduction ACKs
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 034-deferred-20180602|  Actual Points:
  035-removed reachability   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

 * parent:  #25882 =>


Comment:

 Removing Parent ID to close parent.

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

Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, reachability, network-team-  |  Actual Points:
  roadmap-september  |
Parent ID:  #30200   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

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


Comment:

 S we've done lots of fixes in the HS subsystem lately regarding
 circuit timeouts.

 Specifically, I think client side, these two tickets will prevent the
 client to open dozens of intro circuit that is not working: #31541 and
 #32020.

 We did a series of fixes also service side: #32094, #31652, #31632

 As of the long term solution, I believe "Proposal A" from above: #27842

 Now there seems to be a final point in this ticket about making a client
 to claim that an IP failed if the RP never connected as in handle the
 `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED` purpose when cleaning up a
 circuit. I think that we could do a counter here and at least allow the
 client to retry to the IP with another RP and if after like 2 or 3 times
 the circuit always fail in state
 `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED`, considering the IP bad seems
 legitimate since either the service is not connecting properly or the IP
 is not relaying.

 I have created #32614 for this one ^.

 I believe we have tickets for each action items in this ticket so I'm
 going to close it. Please point out anything missing, ideally with a fresh
 ticket clearly explaining what is the issue and possible solutions if any.

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

Re: [tor-bugs] #21621 [Core Tor/Tor]: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO

[Tor Bug Tracker & Wiki]

#21621: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:  not a
 Keywords:  tor-hs, teor-was-assigned,   |  bug
  034-triage-20180328, 034-removed-20180328  |  Actual Points:
Parent ID:  #25882   | Points:  3
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

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


Comment:

 I do not think this is an issue in HSv3 because a service intro circuit
 that never establishes ultimately get removed by
 `circuit_building_expire()` and the HS subsystem notices it at that point
 which results in opening a new one.

 No descriptors are published without all IP established.

 As for v2, I believe it should also behave like that but uncertain. In any
 case, not sure we'll fix this in v2 unless major stability or reachability
 issue arise?

 Please re-open if I'm wrong but in the end, I think
 `circuit_building_expire()` does its job properly.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32614 [Core Tor/Tor]: hs-v3: Consider flagging an intro point as bad if rendezvous fails multiple times

[Tor Bug Tracker & Wiki]

#32614: hs-v3: Consider flagging an intro point as bad if rendezvous fails 
multiple
times
---+--
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-circuit, -tor-hs
Actual Points: |  Parent ID:
   Points:  0.2|   Reviewer:
  Sponsor:  Sponsor27-can  |
---+--
 This comes from #25882.

 Should a client claim that an IP is failing if the RP never connected? In
 other words, handling the `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED`
 purpose when cleaning up a circuit.

 I would think that having a maximum amount of retries let say
 (arbitrarily) after 2 times that you introduce, the IP sends back the ACK
 but then you end up timing out the RP circuit, we would flag the IP in the
 failure cache and move on to a new IP.

 This would not be a "catch all" issues with connectivity but would at
 least zone out buggy or malicious IP that do not relay the introduction.

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