Re: [tor-bugs] #23999 [Internal Services/Service - trac]: New table format

[Tor Bug Tracker & Wiki]

#23999: New table format
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24191| Points:
 Reviewer:|Sponsor:
--+-

Comment (by qbi):

 Do you have the contents of the pastebin somewhere available?

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

Re: [tor-bugs] #25064 [Applications/Tor Browser]: Don't record update history on the Tor Browser

[Tor Bug Tracker & Wiki]

#25064: Don't record update history on the Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Yes, I think it should at least not be as detailed as it is right now. We
 should think about what exactly we want to retain from the update history
 and scrub the remaining things. I am actually not even sure we want to
 have the history available at all. As far as I can see we have never
 needed it so far to debug anything.

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

Re: [tor-bugs] #23999 [Internal Services/Service - trac]: New table format

[Tor Bug Tracker & Wiki]

#23999: New table format
--+-
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24191| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

 * owner:  (none) => qbi
 * component:  Webpages/Website => Internal Services/Service - trac


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

Re: [tor-bugs] #23999 [Webpages/Website]: New table format

[Tor Bug Tracker & Wiki]

#23999: New table format
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24191| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * parent:   => #24191


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

Re: [tor-bugs] #25042 [Archived/Torouter]: Connecting to tor cuts my connection to the internet.

[Tor Bug Tracker & Wiki]

#25042: Connecting to tor cuts my connection to the internet.
---+
 Reporter:  GGNderbomb |  Owner:  ioerror
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Archived/Torouter  |Version:  Tor: 0.3.1.8
 Severity:  Blocker| Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 I am not familiar with anonabox, but I'll give it a go.
 [[br]]
 > Advanced Configuration
 >> Virtual'''Addr'''Network 10.192.0.0/10
 >> Trans'''Port''' 9040
 >> TransListen'''Address''' 192.168.19.84
 >> DNS'''Port''' 9053
 >> DNSListen'''Address''' 192.168.19.84
 >> ClientTransportPlugin obfs2,obfs3,scramblesuit exec
 /usr/bin/'''obfsclient'''
 >> [...]
 >> ## Last updated 12 September '''2012''' for Tor 0.2.4.3-alpha
 >> ## (may or '''may not work for''' much older or '''much newer'''
 versions of Tor.)
 >> [...]
 >> ## Tor opens a socks proxy on port 9050 by default -- even if you
 >> ## configure one below. '''Set "SocksPort 0" if you plan to run Tor
 only'''
 >> ## '''as a relay, and not make any local application connections
 yourself.'''
 >> SocksPort 0

 I bolded some parts. Are the IPs beginning with 192. or the 10. with CIDR
 subnet and their ports the same as those that your devices are configured
 to connect through? Is SocksPort supposed to be 0 on anonabox, implying
 every device runs tor and thinks anonabox is a bridge? I don't see a
 [https://www.torproject.org/docs/bridges#RunningABridge BridgeRelay] line
 while SocksPort is 0. Does it not exist, or did you forget to attach a
 picture of it? Version 0.2.4.3 is extremely old, so you should start with
 a [https://gitweb.torproject.org/tor.git/tree/src/config/torrc.sample.in
 default torrc] for version 0.3.1.8 as a template and overwrite any line
 with the same variable as in yours with the value that yours is set to.
 New variables may have been introduced, deprecated, or removed altogether.
 Take the time to read the comments in the config file (lines starting with
 ##). Variables in the configuration file may be turned off or set to
 default by commenting-out their line (starting a line with a single # to
 make tor think it is a comment and ignore it).

 I cannot find the variables ''above'' the first comment line...
 > ## Configuration file for a typical Tor user
 ...in any versions of tor's torrc config file as far back as
 0.2.4.3-alpha, so those variables are probably used by anonabox and not by
 the tor binary executable. Copy those to your new configuration. While
 you're at it, look at the ClientTransportPlugin line. The Tor Project has
 deprecated obfsclient in favor of separate "pluggable transports" for
 bridge protocols. Check that obfsclient is updated or that obfs4proxy is
 installed and updated, and then consider changing...
 > ClientTransportPlugin '''obfs2,obfs3,scramblesuit''' exec
 /usr/bin/'''obfsclient'''
 to
 > ClientTransportPlugin '''obfs4,obfs3''' exec /usr/bin/'''obfs4proxy'''
 But be careful because other things in anonabox may not be designed for
 new versions of obfs4proxy.

 If you get it to work, send your procedure and a link to this ticket in a
 [https://www.chiark.greenend.org.uk/~sgtatham/bugs.html bug report] to the
 anonabox developers.

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

Re: [tor-bugs] #23968 [Applications/Tor Browser]: NoScript icon jumps to the right after update

[Tor Bug Tracker & Wiki]

#23968: NoScript icon jumps to the right after update
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 5.1.8.3 -> 5.1.8.4 without e10s.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25081 [Core Tor/Tor]: use get_uptime() consistently

[Tor Bug Tracker & Wiki]

#25081: use get_uptime() consistently
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We have this nice function get_uptime() that shields the global variable
 {{{stats_n_seconds_working}}} from the rest of the Tor files.

 But then we undermine that by saying
 {{{
 extern long stats_n_seconds_working;
 }}}
 in main.h and we just start using that variable directly all over.

 There are a few lonely users of get_uptime().

 We should move everybody over to using get_uptime, and get rid of the
 scary extern.

 (Also check out how we're *writing* to the extern variable, in
 hibernate.c. There's no way that could confuse anybody down the road!)

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

Re: [tor-bugs] #25072 [Applications/Tor Browser]: New Identity does not clear HTTPS Everywhere extension storage

[Tor Bug Tracker & Wiki]

#25072: New Identity does not clear HTTPS Everywhere extension storage
---+--
 Reporter:  kmodi  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-torbutton, tbb-newnym  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:2 cypherpunks]:
 > +1 from me.
 From who?

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

Re: [tor-bugs] #25080 [Internal Services/Service - git]: Grant website commit access to colin

[Tor Bug Tracker & Wiki]

#25080: Grant website commit access to colin
-+
 Reporter:  phoul|  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by arma):

 * owner:  tpa => tor-gitadm
 * component:  Internal Services/Tor Sysadmin Team => Internal
 Services/Service - git


Comment:

 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256


 Please let colin push to the webwml git repo.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJab/QhAAoJEMIYUlgZ94RR9agQAKxDQC1Y7bY2UjZjpwjcA4oq
 MdP8XlsWAobzXcHPL5PHveePmpdB/8Ye+dmifPRx1Z2+luVllS7FEqzgNxwbulXj
 SGzzLwNBafXJOFIK++oSnLeHAVkQSISqxxA+xEGHIztRe5jBR7dhiyZQ9e4bnUHu
 w9qlWw8iseAvXkqcZaI58qLWnpqB2IB92RA0N2YmPZHomalROQjxnhCnPkmpcnm8
 pibWW5Z6YxUnBs7qhS5WTR/ceGkVY4FI6cIdaHJsrdUuk4P0W83bhdsU4MExG8BK
 cZPkUEgo3BQoKfatvo2B6GpWqgSPvZq5dXR5aubf1cnKLuB93ZE5v5iaFKucFFVH
 rholENxAeskJNU5PTr4CPjxVQtXXEiegzRDgB+dGpJ8r8c9kHzXCqzm6R4+uYczS
 ve1ARNXYi2914i9RdAmpeMFxTYCUvHc2mp9kxPv8tomtREymrS3CK7H4I3gc1RNe
 Rk0cjOgZRU716MFY+4LPkgGjcdi1cSoCW4E/V7T90Tj/bPwRWKBjtfda8+4e+RN7
 sxqXqfO6QF+7MsY5+dgeNIIzhy0Y6xYoOEiBWPcM3sCXEl33QK0OQ8Z+jjNnAF5a
 rKLiznmv3f/w+vQPzNEy59oFlRsVbM9PBAdUTWJJrN8VCtVYprn51Z8nS2JZ8N+8
 65CNxRznbGgn5jijduzV
 =6MOq
 -END PGP SIGNATURE-
 }}}

 colin: in the future, the right way to do this is to get somebody who is
 already in the group to file a ticket asking for you to be added. This
 ticket was doing it backwards -- after all, how are the git admins
 supposed to know who ought to be added to something and who is a bad idea
 to add?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25080 [Internal Services/Tor Sysadmin Team]: Grant website commit access to colin

[Tor Bug Tracker & Wiki]

#25080: Grant website commit access to colin
-+-
 Reporter:  phoul|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hello,

 As mentioned at
 https://trac.torproject.org/projects/tor/ticket/25079#comment:2, I'd like
 to get commit access to the website.

 My username is "colin"

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

Re: [tor-bugs] #25079 [Webpages/Website]: Remove project from Volunteer page

[Tor Bug Tracker & Wiki]

#25079: Remove project from Volunteer page
--+
 Reporter:  phoul |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by phoul):

 Replying to [comment:2 atagar]:
 > Hi Colin. If you don't presently have website commit access then I'd
 suggest we grant you it. If we're accepted into the program you'll be
 making dozens of adjustments to both the project list and gsoc page.
 I dont believe I currently have access, will open a ticket for that.

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

Re: [tor-bugs] #25079 [Webpages/Website]: Remove project from Volunteer page

[Tor Bug Tracker & Wiki]

#25079: Remove project from Volunteer page
--+
 Reporter:  phoul |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by atagar):

 Hi Colin. If you don't presently have website commit access then I'd
 suggest we grant you it. If we're accepted into the program you'll be
 making dozens of adjustments to both the project list and gsoc page.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by arma):

 I pushed a commit to my {{{ticket24902_029_04-fixup}}} branch that you
 might like -- it cleans up the heartbeat messages a bit.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:48 dgoulet]:
 > > But it looks like the call to dos_should_refuse_single_hop_client()
 doesn't care whether public_server_mode().
 >
 > Agree. Fixup commit: `ab7b9581f3`

 (A) I think this one is missing a !.

 (B) Yes, an 0.3.3 branch would be good so we have something to actually
 merge.

 (C), it wants a changes file. Here's a start:
 {{{
   o Major features:
 - Give relays some defenses against the recent network overload. We
   start with three defenses (default parameters in parentheses).
   First: if a single client address makes too many connections
   (>100), hang up on further connections. Second: if a single client
   address makes circuits too quickly (more than 3 per second, with
   an allowed burst of 90) while also having too many connections open
   (3), refuse new create cells for the next while (1-2 hours). Third:
   if a client asks to establish a rendezvous point to you directly,
   ignore the request. These defenses can be manually controlled
   by new torrc options, but relays will also take guidance from
   consensus parameters, so there's no need to configure anything
   manually. Implements ticket 24902.
 }}}

 Looking good!

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

[tor-bugs] #25079 [Webpages/Website]: Remote project from Volunteer page

[Tor Bug Tracker & Wiki]

#25079: Remote project from Volunteer page
--+
 Reporter:  phoul |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tom Ritter has requested that "Make Tor Browser Faster" be removed from
 https://www.torproject.org/getinvolved/volunteer.html.en.

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

Re: [tor-bugs] #25079 [Webpages/Website]: Remove project from Volunteer page (was: Remote project from Volunteer page)

[Tor Bug Tracker & Wiki]

#25079: Remove project from Volunteer page
--+
 Reporter:  phoul |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #25078 [Applications/Tor Browser]: Change app.update.url to point to onion service

[Tor Bug Tracker & Wiki]

#25078: Change app.update.url to point to onion service
--+--
 Reporter:  cypherpunks   |  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 teor):

 Replying to [ticket:25078 cypherpunks]:
 > As of TBB 7.5, app.update.url points to https://aus1.torproject.org .
 Wouldn't it be more sensible for the Tor Project to point automatic
 updates of its software to services it operates ''inside'' of the Tor
 network that it maintains? Metrics could also benefit. The onion service
 of aus1 is listed on onion.torproject.org.

 Downloads would be slower, and put more load on the network, because the
 torproject onion services are not single onion services. Migration is
 blocked on #21117.

 Replying to [comment:1 cypherpunks]:
 > A next-generation v3 onion service would be preferable to the v2 one on
 onion.torproject.org.

 I think there is a ticket for torproject to run v3 onion services as well,
 but I can't find 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] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by isis):

 Wow, great work, David! Thanks! Let's make #19910 be the ticket for mcs's
 issue !#1 here.

 For issue !#2 I'll do some more testing and I might need to patch stuff a
 bit to add more verbose logging, because right now I'm not seeing anything
 that indicates why no bridges would be returned.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:50 teor]:
 > ...
 > The dos_*refuse_single_hop_client functions and variables are confusing.
 They only apply to v2 rendezvous, but they are named like they apply to
 all clients. Please add the word "rend".
 >
 > Should we implement this defence for v3 rendezvous as well?
 > (We have a separate ticket for single hop HSDir and intro.)

 Oops. Rend points are the same for v2 and v3. So the defence applies to
 both. Thanks arma!

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

Re: [tor-bugs] #25078 [Applications/Tor Browser]: Change app.update.url to point to onion service

[Tor Bug Tracker & Wiki]

#25078: Change app.update.url to point to onion service
--+--
 Reporter:  cypherpunks   |  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 cypherpunks):

 A next-generation v3 onion service would be preferable to the v2 one on
 onion.torproject.org.

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  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 arthuredelstein):

 Replying to [comment:13 arma]:

 > I think it would be worth exploring whether we can do the same behavior
 in a smarter way from the browser though -- the feature essentially
 removes a round-trip across the Tor network from page loads.

 Instead of implementing a patch in the browser, I wonder if we could patch
 the tor proxy instead with roughly the same speedup.

   1. The SOCKS client opens a TCP connection to the tor proxy
   2. The SOCKS client sends a SOCKS CONNECT command
   3. The proxy immediately returns a spoofed SOCKS CONNECTED notification
 to the SOCKS client, and the proxy also sends a BEGIN cell to the Exit.
   4. The SOCKS client sends some data to the OP (the GET request, for
 example).
   5. The OP sends a DATA cell to the Exit

 This arrangement doesn't require any modification to the browser's SOCKS
 implementation, but it means we don't wait for the Exit to respond with
 CONNECTED before asking the SOCKS client to send its first data. Basically
 we put the "optimism" in the proxy instead of the browser. That's nice
 because then (1) we will get a speedup to all ordinary SOCKS clients and
 (2) we're patching code controlled by Tor Project.

 Provided the round trip between the SOCKS client and proxy is very small
 compared to the round-trip through the Tor network, the performance should
 presumably be about the same as the existing patch in 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

[tor-bugs] #25078 [Applications/Tor Browser]: Change app.update.url to point to onion service

[Tor Bug Tracker & Wiki]

#25078: Change app.update.url to point to onion service
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 As of TBB 7.5, app.update.url points to https://aus1.torproject.org .
 Wouldn't it be more sensible for the Tor Project to point automatic
 updates of its software to services it operates ''inside'' of the Tor
 network that it maintains? Metrics could also benefit. The onion service
 of aus1 is listed on onion.torproject.org.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by teor):

 Code review:

 "dos.h" already exists in some Windows environments. We might want to pick
 another name.

 The dos_*refuse_single_hop_client functions and variables are confusing.
 They only apply to v2 rendezvous, but they are named like they apply to
 all clients. Please add the word "rend".

 Should we implement this defence for v3 rendezvous as well?
 (We have a separate ticket for single hop HSDir and intro.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25077 [Metrics/Relay Search]: Atlas onion service calls clearnet metrics.torproject.org

[Tor Bug Tracker & Wiki]

#25077: Atlas onion service calls clearnet metrics.torproject.org
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The onion service of atlas.torproject.org (52g5y5karruvc7bz.onion found on
 onion.torproject.org) now known as Relay Search contains hardcoded calls
 to images and javascript on the clearnet at metrics.torproject.org, not
 relative URL calls to its own onion service nor to the onion service of
 Metrics.

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  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 arthuredelstein):

 * cc: arthuredelstein@… (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] #21295 [Core Tor/Tor]: Allow mixed anonymous and non-anonymous onion services in the same tor instance

[Tor Bug Tracker & Wiki]

#21295: Allow mixed anonymous and non-anonymous onion services in the same tor
instance
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-hs, single-onion, prop224,   |  Actual Points:
  maybe-bad-idea |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:10 cypherpunks]:
 > Replying to [comment:9 teor]:
 > > If someone does want to give up their anonymity, they should run
 another tor instance, or restart their current instance in non-anonymous
 mode.
 > >
 > > Or we should develop a feature where controllers can set custom onion
 service paths.
 > Please cc `micahlee` so that he can know that. :)

 Some people don't like being cc'd to lots of tickets. Micah had the
 opportunity to cc himself when I sent the original list email, and chose
 not to.

 A more appropriate action is to respond to the original list thread:
 https://lists.torproject.org/pipermail/tor-dev/2018-January/012862.html

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

[tor-bugs] #25076 [Internal Services/Wiki]: wiki NextGenOnions: add link to contact asn for additions

[Tor Bug Tracker & Wiki]

#25076: wiki NextGenOnions: add link to contact asn for additions
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Wiki  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 On wiki:doc/NextGenOnions
 > [This page will remain read-only for the next few days. Please contact
 asn for any additions.]
 But there is no link to send messages. No user page is on Trac as on
 Wikipedia. Please add asn contact link or edit to say how.

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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by arma):

 Replying to [comment:21 mcs]:
 > Let's do it! Kathy and I wrestled with the SOCKS optimistic data patch
 once before. It just seems too fragile given the way the networking and
 TLS code is layered inside Firefox. The only thing I don't know is whether
 removing it will impact web page load times in a significant way.
 >
 > Another approach would be add an option to disable the SOCKS optimistic
 data feature on a per-connection basis, which would allow Tor Launcher to
 disable that option when it is using meek directly.

 I figure #19910 is a good place for discussion of whether to rip it out,
 impacts, and workarounds. So I added my thought there.

 (Good stuff 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] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  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 arma):

 See #24432 for an example of a situation where this optimistic data socks
 handshake patch surprisingly broke stuff.

 It's starting to look more like we're going to rip it out.

 I think it would be worth exploring whether we can do the same behavior in
 a smarter way from the browser though -- the feature essentially removes a
 round-trip across the Tor network from page loads.

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

Re: [tor-bugs] #24971 [- Select a component]: Tor browser not working

[Tor Bug Tracker & Wiki]

#24971: Tor browser not working
--+
 Reporter:  johnsmithjs   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 johnsmithjs, you should not post what you visit on tor when you are
 logging in from the clearnet, nor any bridge addresses either. **Edit your
 comment.** Do not post identifying information except if it 1. relevant
 and then 2. absolutely necessary. Optionally, you may login as the public
 account cypherpunks, password writecode.
 [[br]]
 > the tor browser hasn't been working properly for months
 Does it update itself? Did you try deleting the Tor Browser folder and
 downloading a clean copy from TorProject.org? Were you sure your
 connection to TorProject.org was secured with HTTPS and a (usually) green
 padlock icon or green text in your address bar? Did you verify the
 download using its signature (sig) file? After you installed it, were you
 sure you did not misconfigure it in the Tor Launcher window?
 [[br]]
 > whenever I try to log in or register a new username the internet
 continues to have errors
 Are the errors on your clearnet browser or on Tor Browser? If on Tor
 Browser, did you lower the slider in the onion icon Security Settings or
 edit NoScript?
 [[br]]
 > I'm going to download a programme that can report the log file
 Attach your Tor log to this ticket. Tor Launcher will display a button to
 copy the log when it fails, or a button may be found when Tor Browser is
 open in the onion icon, Tor Network Settings. It is not a good idea to run
 a general repair programme on the Tor Browser folder that may try to
 modify it or send its data over the clearnet that may identify you.
 [[br]]
 > Establishing a Tor circuit failed (missing pluggable transport -
 xxx.xxx.xxx.xxx:x)
 Did you configure Tor Launcher or the onion icon to use a tor bridge? Did
 you try to disable the setting and connect without the bridge? A bridge is
 optional, not required except if your internet provider blocks Tor. If you
 use one, sometimes relays and bridges shut down or change addresses. Did
 you try to get a new bridge from bridges.torproject.org? Were you sure
 your connection to bridges.torproject.org was secured with HTTPS and a
 (usually) green padlock icon or colored text in your address bar? Were you
 sure you pasted each full bridge line correctly into Tor Launcher or the
 onion icon?
 [[br]]
 > Failed to take control of Tor.
 Another tor.exe is running on your computer. Did you install the Expert
 Bundle and Tor Browser Bundle? Uninstall the Expert Bundle except when you
 know what you are doing. An old Tor Browser may also have bugs and not
 close correctly. Open Windows Task Manager, taskmgr.exe, to the Processes
 tab to find the running tor.exe and kill it. Before you kill it, see if
 you can show the column that shows the folder location of the tor.exe. See
 if it in Tor Browser folder or another place. Do not paste your computer
 username here.

 Other questions:
 Are you sure your computer system is secure? Do you run a updated virus
 scan on your system? Are your hard drives running OK? Do any programs
 return errors about corrupted files?

 **TL;DR**
 Edit your comment to remove identity information. Update Tor Browser.
 Check your bridge settings. Kill extra tor.exe Process in Task Manager.

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

Re: [tor-bugs] #20951 [Applications/Tor Browser]: Back out Unix domain socket related patches for Tor Browser 6.5

[Tor Bug Tracker & Wiki]

#20951: Back out Unix domain socket related patches for Tor Browser 6.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201701R,   |  Actual Points:
  GeorgKoppen201701  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Is there any ticket about putting the patches back? Or writing better
 ones? (I see #20775 but it's not clear whether that's the same.)

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

Re: [tor-bugs] #21295 [Core Tor/Tor]: Allow mixed anonymous and non-anonymous onion services in the same tor instance

[Tor Bug Tracker & Wiki]

#21295: Allow mixed anonymous and non-anonymous onion services in the same tor
instance
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-hs, single-onion, prop224,   |  Actual Points:
  maybe-bad-idea |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:9 teor]:
 > If someone does want to give up their anonymity, they should run another
 tor instance, or restart their current instance in non-anonymous mode.
 >
 > Or we should develop a feature where controllers can set custom onion
 service paths.
 Please cc `micahlee` so that he can know 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] #24854 [Core Tor/Tor]: Extract the authority list from config.c

[Tor Bug Tracker & Wiki]

#24854: Extract the authority list from config.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, 029-backport,  |  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24818   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by beastr0):

 Yeah, sure, I can take that one on. I know Python, C and Java so for
 future reference you guys can hit me up with any projects based on those
 languages.

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

Re: [tor-bugs] #24421 [Applications/Tor Browser]: "Temporarily allow all this page" and uploads get inherited when New Identity is chosen.

[Tor Bug Tracker & Wiki]

#24421: "Temporarily allow all this page" and uploads get inherited when New
Identity is chosen.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  tbb-newnym, TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Georg, did you test as well the upload issue?

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

Re: [tor-bugs] #25072 [Applications/Tor Browser]: New Identity does not clear HTTPS Everywhere extension storage

[Tor Bug Tracker & Wiki]

#25072: New Identity does not clear HTTPS Everywhere extension storage
---+--
 Reporter:  kmodi  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-torbutton, tbb-newnym  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 +1 from 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] #24851 [Core Tor/Fallback Scripts]: create a script that generates the authority format from the authorities in the current consensus

[Tor Bug Tracker & Wiki]

#24851: create a script that generates the authority format from the 
authorities in
the current consensus
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-dirauth|  Actual Points:
Parent ID:  #24818 | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:4 atagar]:
 > Hi Tim. Is this to generate tor's hardcoded list of authorities? If so
 then seems a little odd to check for the 'Authority' flag since this means
 that your script will omit authorities when they're down.
 >
 > For what it's worth Stem has a get_authorities() which references its
 own copy of the authority list...
 >
 >
 
https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.get_authorities
 >
 https://gitweb.torproject.org/stem.git/tree/stem/descriptor/remote.py#n823
 >
 > However, probably unhelpful due to the clear chicken-and-egg since part
 of the goal is to sync this listing with the document you generate.
 >
 > Maybe the best bet would be for your script to include a hardcoded
 listing of the authority fingerprints, then...
 >
 > * Fetch their descriptors to generate the rest of the doc (address,
 or/dirport, nickname, etc).
 > * If any of the hardcoded relays isn't present in the consensus then
 error.
 >
 > This way adding/removing authorities is as simple as changing the list
 of fingerprints and rerunning your script.

 I want to use the consensus to make sure that we only include valid IPv6
 addresses for authorities.
 When we start hard-coding ed25519 key fingerprints, we can use it to warn
 about incorrectly pinned ed25519 keys.
 (Key pinning is much less of a concern, but IPv6 addresses can be quite
 dynamic.)

 I don't think it matters whether the other fields are retrieved from the
 consensus or the descriptor.
 So your strategy sounds good.

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

Re: [tor-bugs] #25024 [Core Tor/Tor]: Add optional spell check to makefile to check for typos in tor source code.

[Tor Bug Tracker & Wiki]

#25024: Add optional spell check to makefile to check for typos in tor source 
code.
--+
 Reporter:  fristonio |  Owner:  alison
 Type:  enhancement   | Status:  needs_revision
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tor-comment   |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by fristonio):

 Sorry that I messed up a bit there, I updated the changes you told
 https://github.com/fristonio/tor/tree/ticket25024

 I also added `check-typos` to `make check` as it seems a test similar to
 `check-spaces`.

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

Re: [tor-bugs] #25064 [Applications/Tor Browser]: Don't record update history on the Tor Browser

[Tor Bug Tracker & Wiki]

#25064: Don't record update history on the Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 To remove the existing information, find the updates.xml file within your
 Tor Browser profile and delete it.

 Currently, there is no preference (visible or hidden) that we can use to
 disable writing of the update history. Having the information available
 can be useful, but I can also understand why, at least for some people, it
 may give away too much information. For example, the timestamps associated
 with the list of updates could be used to determine that Tor Browser was
 likely in use on certain days and at certain times.

 Georg, do you think that recording this info violates the disk avoidance
 aspect of the Tor Browser design?

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

Re: [tor-bugs] #25075 [Core Tor/Stem]: Constants are included in sphinx output

[Tor Bug Tracker & Wiki]

#25075: Constants are included in sphinx output
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  website, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Oops! Shame on me - thanks Roger.

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

Re: [tor-bugs] #25075 [Core Tor/Stem]: Constants are included in sphinx output

[Tor Bug Tracker & Wiki]

#25075: Constants are included in sphinx output
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  | Resolution:
 Keywords:  website, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by arma):

 * owner:  (none) => atagar
 * component:  - Select a component => Core Tor/Stem


Comment:

 (taking a guess at an appropriate component)

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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by mcs):

 Replying to [comment:20 gk]:
 > Wow, thanks a lot for this analysis. Let me skip over it to jump to your
 conclusions part...

 Indeed, thanks! David, you are my hero.

 > Given that the analysis shows that at least part of the problem is due
 to the patch itself and how it interacts with the other Firefox networking
 code I think we should back it out and rewrite it if we want to keep it.
 We actually have #19910 for that and I think the OP describes a scenario
 that is compatible with the one you are seeing.

 Let's do it! Kathy and I wrestled with the SOCKS optimistic data patch
 once before. It just seems too fragile given the way the networking and
 TLS code is layered inside Firefox. The only thing I don't know is whether
 removing it will impact web page load times in a significant way.

 Another approach would be add an option to disable the SOCKS optimistic
 data feature on a per-connection basis, which would allow Tor Launcher to
 disable that option when it is using meek directly.

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

Re: [tor-bugs] #25065 [Obfuscation/Pluggable transport]: goptlib doesn't allow optimistic SOCKS data

[Tor Bug Tracker & Wiki]

#25065: goptlib doesn't allow optimistic SOCKS data
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Minor| Resolution:
 Keywords:  goptlib  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 Of course if the Tor Browser team decides to stop using the optimistic
 SOCKS data patch (see #19910), then there will be no need for this ticket.

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

Re: [tor-bugs] #24851 [Core Tor/Fallback Scripts]: create a script that generates the authority format from the authorities in the current consensus

[Tor Bug Tracker & Wiki]

#24851: create a script that generates the authority format from the 
authorities in
the current consensus
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-dirauth|  Actual Points:
Parent ID:  #24818 | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by atagar):

 Hi Tim. Is this to generate tor's hardcoded list of authorities? If so
 then seems a little odd to check for the 'Authority' flag since this means
 that your script will omit authorities when they're down.

 For what it's worth Stem has a get_authorities() which references its own
 copy of the authority list...

 
https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.get_authorities
 https://gitweb.torproject.org/stem.git/tree/stem/descriptor/remote.py#n823

 However, probably unhelpful due to the clear chicken-and-egg since part of
 the goal is to sync this listing with the document you generate.

 Maybe the best bet would be for your script to include a hardcoded listing
 of the authority fingerprints, then...

 * Fetch their descriptors to generate the rest of the doc (address,
 or/dirport, nickname, etc).
 * If any of the hardcoded relays isn't present in the consensus then
 error.

 This way adding/removing authorities is as simple as changing the list of
 fingerprints and rerunning your script.

 Cheers! -Damian

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

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
--+
 Reporter:  mttp  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

 * cc: boklm (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] #25046 [Core Tor/Stem]: reveal_count incorrect in stem

[Tor Bug Tracker & Wiki]

#25046: reveal_count incorrect in stem
---+
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


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

Re: [tor-bugs] #25046 [Core Tor/Stem]: reveal_count incorrect in stem

[Tor Bug Tracker & Wiki]

#25046: reveal_count incorrect in stem
---+--
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Thanks Tim, nice catch. I expect that's a long standing documentation bug
 (not spotting a way that it could be related to this particular fix). Good
 thing to address though none the less.

 Moved to #25075.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25075 [- Select a component]: Constants are included in sphinx output

[Tor Bug Tracker & Wiki]

#25075: Constants are included in sphinx output
--+---
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Minor |   Keywords:  website, easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 As pointed out by Tim at the end of #25046 Sphinx is including our
 internal parser constants in its generated api docs...

 
https://stem.torproject.org/api/descriptor/networkstatus.html#stem.descriptor.networkstatus.NetworkStatusDocumentV3.content

 {{{
 HEADER_PARSER_FOR_LINE = {'valid-after': , ...
 }}}

 Marking this with the 'easy' keyword since it's a good one for newcomers
 to bite off. I suspect that if we mark these constants as private with a
 leading underscore Sphinx might skip it. If not we'll need to investigate
 Sphinx a little more to figure out how to exclude these.

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

Re: [tor-bugs] #14952 [Applications/Tor Browser]: Audit HTTP/2 and SPDY if needed

[Tor Bug Tracker & Wiki]

#14952: Audit HTTP/2 and SPDY if needed
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, tbb-usability-  |  Actual Points:
  website, tbb-performance, ff60-esr |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 And this document: https://gitweb.torproject.org/tor-browser-
 spec.git/plain/position-papers/HTTP3/HTTP3.pdf

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (added)
 * reviewer:  gk, sysrqb, mcs, arthuredelstein => gk, sysrqb, 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] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs, arthuredelstein  |Sponsor:
--+
Changes (by arthuredelstein):

 * reviewer:  gk, sysrqb, mcs => gk, sysrqb, mcs, arthuredelstein


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

Re: [tor-bugs] #24851 [Core Tor/Fallback Scripts]: create a script that generates the authority format from the authorities in the current consensus

[Tor Bug Tracker & Wiki]

#24851: create a script that generates the authority format from the 
authorities in
the current consensus
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-dirauth|  Actual Points:
Parent ID:  #24818 | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 You can start with the Stem example here:
 https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html
 #where-can-i-get-the-current-descriptors

 Then modify it to only print the authorities, by matching on the
 "Authority" flag:
 
https://stem.torproject.org/api/descriptor/router_status_entry.html#stem.descriptor.router_status_entry.RouterStatusEntry

 And add the other fields that are in the existing document:
 
https://stem.torproject.org/api/descriptor/router_status_entry.html#stem.descriptor.router_status_entry.RouterStatusEntryV3

 You might find that this spec helps, or there might be way too much
 detail:
 https://github.com/teor2345/torspec/blob/dir-list/dir-list-spec.txt#L252

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

Re: [tor-bugs] #24854 [Core Tor/Tor]: Extract the authority list from config.c

[Tor Bug Tracker & Wiki]

#24854: Extract the authority list from config.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, 029-backport,  |  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24818   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:13 beastr0]:
 > Do you need any help with those tasks? or do you have any other specific
 tickets that you would like me to work on?

 Ticket #24851 is the next step: we want to generate the auth_dirs.inc file
 using a script.
 That way, we can update it automatically when authority details change.
 If you know python, or you're willing to learn, it's a good ticket.

 Otherwise, I'm not actively working on anything in C at the moment, but
 I'll let you know. Or you can look for tickets.

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

Re: [tor-bugs] #6119 [Applications/Quality Assurance and Testing]: Create our own instance of Panopticlick

[Tor Bug Tracker & Wiki]

#6119: Create our own instance of Panopticlick
-+-
 Reporter:  mikeperry|  Owner:  boklm
 Type:  project  | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  TorBrowserTeam201801   |
Parent ID:  #5292| Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by boklm):

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


Comment:

 I added a section about FPCentral on the TorBrowser/Hacking page:
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#FPCentral

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

Re: [tor-bugs] #21862 [Applications/Tor Browser]: Make rust code in ESR 52 proxy safe

[Tor Bug Tracker & Wiki]

#21862: Make rust code in ESR 52 proxy safe
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201706R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-7.0-must, TorBrowserTeam201706R, tbb-no-uplift
 => ff52-esr, tbb-7.0-must, TorBrowserTeam201706R


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

Re: [tor-bugs] #22587 [Applications/Quality Assurance and Testing]: Add an FPCentral test to our test suite

[Tor Bug Tracker & Wiki]

#22587: Add an FPCentral test to our test suite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201801 |  Actual Points:
Parent ID:  #6119| Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by boklm):

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


Comment:

 The test was added with commit 90692b7c14541aa1394439f763b2bf693a827ea8,
 and commit 7b77372af15a893434e40e895ca022b4beb63c88 changed the URL to use
 https://fpcentral.tbb.torproject.org/fp?automated_test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25074 [Core Tor/Tor]: TROVE-2018-001

[Tor Bug Tracker & Wiki]

#25074: TROVE-2018-001
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 For details, see:
 https://trac.torproject.org/projects/tor/wiki/TROVE

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

Re: [tor-bugs] #25072 [Applications/Tor Browser]: New Identity does not clear HTTPS Everywhere extension storage (was: New Identity does not clear extension storage)

[Tor Bug Tracker & Wiki]

#25072: New Identity does not clear HTTPS Everywhere extension storage
---+--
 Reporter:  kmodi  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-torbutton, tbb-newnym  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => tbb-torbutton, tbb-newnym
 * owner:  jsha => tbb-team
 * component:  HTTPS Everywhere/EFF-HTTPS Everywhere => Applications/Tor
 Browser


Comment:

 We might need an HTTPS-Everywhere patch, not sure yet, but for now we
 could try looking into patch Torbutton where the `New Identity` code lives
 and do maybe a similar thing to what we do when clearing NoScript's
 permissions.

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

Re: [tor-bugs] #14970 [Applications/Tor Browser]: Don't allow third parties to block our own Tor Browser extensions

[Tor Bug Tracker & Wiki]

#14970: Don't allow third parties to block our own Tor Browser extensions
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff45-esr, tbb-security, tbb-6.0a5,   |  Actual Points:
  TorBrowserTeam201604R, GeorgKoppen201604,  |
  tbb-no-uplift  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:
 ff45-esr, tbb-security, tbb-6.0a5, TorBrowserTeam201604R,
 GeorgKoppen201604
 =>
 ff45-esr, tbb-security, tbb-6.0a5, TorBrowserTeam201604R,
 GeorgKoppen201604, tbb-no-uplift


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

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s, TorBrowserTeam201712R,   |
  tbb-no-uplift  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:
 AffectsTails, tbb-7.0-issues, tbb-regression, tbb-e10s,
 TorBrowserTeam201712R
 =>
 AffectsTails, tbb-7.0-issues, tbb-regression, tbb-e10s,
 TorBrowserTeam201712R, tbb-no-uplift


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

Re: [tor-bugs] #21907 [Applications/Tor Browser]: Tor Browser nightly (based on ESR52) is not running on CentOS 6

[Tor Bug Tracker & Wiki]

#21907: Tor Browser nightly (based on ESR52) is not running on CentOS 6
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, TorBrowserTeam201704R, |  Actual Points:
  tbb-7.0-must-alpha, tbb-no-uplift  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, TorBrowserTeam201704R, tbb-7.0-must-alpha =>
 ff52-esr, TorBrowserTeam201704R, tbb-7.0-must-alpha, tbb-no-uplift


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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-

Comment (by dgoulet):

 Because we'll merge this in 033 before backporting, I'm happy to provide
 an 033 branch if needed, the merge has some conflicts (trivial but some).
 Let me know.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:   => arma


Comment:

 First, I had to do a fixup unrelated to the review: `9d2699cad0`

 Replying to [comment:43 arma]:
 > Should we use END_CIRC_REASON_RESOURCELIMIT instead?

 Good point. Fixup commit `2d9b285f98`.

 > But it looks like the call to dos_should_refuse_single_hop_client()
 doesn't care whether public_server_mode().

 Agree. Fixup commit: `ab7b9581f3`

 > get_circuit_rate_per_second() still isn't doing what I think you wanted.

 Yah so thanks to Hello71 on IRC, I realized that there was an issue indeed
 and all your "Edit:" were indeed discussed and proposed by Hello71 :).

 I kind of think dropping the "tenths" would be good because, as you said,
 at best we can fill the bucket every second (approx_time()). So everything
 is rounded off to the second anyway. And a considerable time gap between
 CREATE cell will make a small difference which probably won't matter at
 that point.

 Thus, going to a number of circuit per second instead of "tenths" seems
 the improvement to do.

 What about this commit? `2106a5eaa8`

 > (a) should be "Number of allocated circuits remaining for this address",
 i.e. it's not a rate, it's a size.

 Fixup commit: `c7099765b4`

 > (b) What's this about "plus a bit of random"? :)

 Don't know what you are talking about, I can't find this string in the
 code :S ...

 > In the future, I plan to advocate for merging dos_cc_new_create_cell()
 and dos_cc_get_defense_type() into a single function, which notes the
 existence of the new create cell and also tells us whether to apply a
 defense. And I plan to advocate for a second cc defense, which returns
 DOS_CC_DEFENSE_REFUSE_CELL simply when stats->cc_stats.circuit_bucket ==
 0, without any marking or checking of stats->concurrent_count. I think I
 will want to instrument a real relay to see how often it would trigger
 that new defense, though, and I am happy to delay my future plans so we
 can get this patch out the door.

 Agree on both! Once we get this merged, lets open tickets for that!

 Final fixup on the man page (thanks to Hello71!): `1b8835fccd`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25073 [Webpages/Blog]: create blog account for antonela

[Tor Bug Tracker & Wiki]

#25073: create blog account for antonela
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--


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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Maybe, also use the valid after timestamp for the value in file
 `out/update` or remove the 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] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:41 arma]:
 > I would think that for DoS info, like circuit info, the thing I most
 want to know is "very recently, what happened"? So I personally would
 prefer the "since last time" data. But I can totally see this going either
 way.

 I implemented that before but then I switched because I wanted to have a
 big picture of the DoS where stats every heartbeat gives you an idea of
 the "right now" situation.

 I do think both would be useful tbh because for instance the "marked
 address" will go to some number then at some point will be 0 all the time
 because your tor marked all the addresses so that could be a bit
 confusing. Wouldn't be complicated to have both counts, a long term one
 and a "since last heartbeat" ?

 > Speaking of heartbeat, "40 marked address" doesn't tell me how many
 addresses are being rejected *right now*. In fact, this could be a single
 address that got marked 40 times since startup of my relay? (I guess not
 quite because I have 36 hours of uptime and there were 40 marked
 addresses, but it's close.)

 You can "double mark" an address only if it is marked once then removed
 from the geoip cache and then it comes back and marked again. In that
 case, the counter will do a ++ twice for the same address.

 Once the `marked_until_ts` is set, it is never put back to 0 so it can't
 be counted twice unless the entry is removed from the geoip cache.

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

[tor-bugs] #25072 [HTTPS Everywhere/EFF-HTTPS Everywhere]: New Identity does not clear extension storage

[Tor Bug Tracker & Wiki]

#25072: New Identity does not clear extension storage
---+--
 Reporter:  kmodi  |  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 When "New Identity" button is pressed, the information stored by
 extensions like HTTPS Everywhere is not cleared.

 This might contain information, like domains which the user added as an
 exception.
 Because, this persists on disk and is not cleared on Tor shoutdown or
 manually clicking "New Identity", it leaves traces of users browsing
 habits.

 Steps to reproduce:
 1. Visit a website like cnn.com.
 2. Click on HTTPS Everywhere Icon, and uncheck CNN.COM.
 3. Restart Tor or Click on New Identity,
 4. Visit the same site again, the setting is remembered by extension.

 Data on disk:
 ~/Library/Application\ Support/TorBrowser-Data/Browser/profile/browser-
 extension-data/https-everywhere-
 e...@eff.org/storage.js:{"ruleActiveStates":{"CNN.com
 (partial)":false},"migration_version":1}

 Ideally, extensions should be careful while saving data to disks. But may
 be Tor can also clear the storage on New Identity.

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

Re: [tor-bugs] #25068 [Core Tor/Tor]: Make HSIntro consistent with rend_service_descriptor_t.protocols

[Tor Bug Tracker & Wiki]

#25068: Make HSIntro consistent with rend_service_descriptor_t.protocols
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, doc?  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 I think that this was part of the idea of removing v0 and v1 support as
 well from the code which we wanted to do when prop224 came out so we do
 ONE big change for hidden services at once. Else, this creates a version
 leak.

 But that never happened... #15621

 Either we keep it in until we actually phase out v2 entirely (years to
 come) or we just do it and consider that "well yeah the HS tor version can
 leak but maybe that ain't a big deal?".

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

Re: [tor-bugs] #25070 [Core Tor/Tor]: protover_get_supported_protocols() should include Link=5 as of 0.3.1.1-alpha

[Tor Bug Tracker & Wiki]

#25070: protover_get_supported_protocols() should include Link=5 as of
0.3.1.1-alpha
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  protover, rust, 031-backport,|  Actual Points:  0.3
  032-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 Please see my branches on https://github.com/teor2345/tor.git :
 * bug25070: branch on master with C protover, Rust protover, unit tests,
 and changes file
 * bug25070_031: branch on maint-0.3.1 with C protover and changes file

 (The unit tests won't backport, because they depend on some 0.3.2 and
 0.3.3 features. And Rust was introduced in 0.3.3.1-alpha.)

 Do I need to increment the crate version in src/rust/protover/Cargo.toml?

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

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Lines like `0.0.0.0 - - [22/Jan/2018:00:00:00 +] "GET
 /collector/archive HTTP/1.1" 301 -` should be valid (cf. comments 50, 51
 on #22428).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25071 [Core Tor/Tor]: Add a test-rust make target to the Makefile

[Tor Bug Tracker & Wiki]

#25071: Add a test-rust make target to the Makefile
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 I can't quite work out how to run src/test/test_rust.sh by itself. It
 would be handy to have a target that runs it.

 I tried, but I can't work out how to do that easily.

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

Re: [tor-bugs] #25069 [Core Tor/Tor]: Improve supported protocols unit test by exposing supported protocols in headers

[Tor Bug Tracker & Wiki]

#25069: Improve supported protocols unit test by exposing supported protocols in
headers
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by teor):

 This is a follow-up to #25070.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25070 [Core Tor/Tor]: protover_get_supported_protocols() should include Link=5 as of 0.3.1.1-alpha

[Tor Bug Tracker & Wiki]

#25070: protover_get_supported_protocols() should include Link=5 as of
0.3.1.1-alpha
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:  Tor: 0.3.1.1-alpha
  Tor/Tor|   Keywords:  protover, rust, 031-backport,
 Severity:  Normal   |  032-backport
Actual Points:  0.3  |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+-
 Fortunately, link version negotiation does not rely on protover.
 But I added some unit tests to make sure we check for new Link versions.

 This isn't easy, because most protovers don't expose supported versions in
 headers. And those that do, don't expose a list or a maximum version. I
 opened #25069 to refactor the code so it's easier to test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25069 [Core Tor/Tor]: Improve supported protocols unit test by exposing supported protocols in headers

[Tor Bug Tracker & Wiki]

#25069: Improve supported protocols unit test by exposing supported protocols in
headers
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy, refactor
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 Currently, we hard-code a lot of supported protocols in the supported
 protocols unit test.

 Instead, we should expose a list of supported protocols in each header,
 and check those. Or, we can expose a maximum supported protocol.

 This allows us to write unit tests like the LinkAuth tests.

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

Re: [tor-bugs] #24979 [Core Tor/Torsocks]: torsocks could support ptrace sandboxing

[Tor Bug Tracker & Wiki]

#24979: torsocks could support ptrace sandboxing
---+-
 Reporter:  Hello71|  Owner:  dgoulet
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by Hello71):

 seccomp is Linux-specific. ptrace works everywhere. (or, I guess you have
 used ptrace, doesn't really work anywhere...)

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

Re: [tor-bugs] #24037 [Core Tor/Torsocks]: Use syscall blacklist rather than whitelist for torsocks

[Tor Bug Tracker & Wiki]

#24037: Use syscall blacklist rather than whitelist for torsocks
---+--
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by Hello71):

 consider that file descriptors can be transferred between processes as
 well. we assume that torsocks applications are not actively malicious, but
 perhaps there is some scenario involving dbus where a torsocks application
 can be tricked into using a un-torified socket opened somewhere else.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25068 [Core Tor/Tor]: Make HSIntro consistent with rend_service_descriptor_t.protocols

[Tor Bug Tracker & Wiki]

#25068: Make HSIntro consistent with rend_service_descriptor_t.protocols
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.3-alpha
 Severity:  Normal|   Keywords:  tor-hs, doc?
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 HSIntro supports protocol versions 3 and 4:
 {{{
The "HSIntro" protocol handles introduction points.

"3" -- supports authentication as of proposal 121 in Tor
   0.2.1.6-alpha.

"4" -- support ed25519 authentication keys which is defined by the HS
 v3
   protocol as part of proposal 224 in Tor 0.3.0.4-alpha.
 }}}

 But rend_service_update_descriptor() says "intro protocols 2 and 3":
 {{{
   /* Support intro protocols 2 and 3. */
   d->protocols = (1 << 2) + (1 << 3);
 }}}
 I think we need to delete "2" here.

 And rend_service_descriptor_t says "introduce/rendezvous" 0-3:
 {{{
   /** Bitmask: which introduce/rendezvous protocols are supported?
* (We allow bits '0', '1', '2' and '3' to be set.) */
   unsigned protocols : REND_PROTOCOL_VERSION_BITMASK_WIDTH;
 }}}
 I think we need to delete "/rendezvous" and 0-2 here.

 This seems to be a bug in 496fe68 in 0.2.5.3-alpha.

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

Re: [tor-bugs] #24854 [Core Tor/Tor]: Extract the authority list from config.c

[Tor Bug Tracker & Wiki]

#24854: Extract the authority list from config.c
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, 029-backport,  |  Actual Points:
  031-backport, 032-backport |
Parent ID:  #24818   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by beastr0):

 Do you need any help with those tasks? or do you have any other specific
 tickets that you would like me to work 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

Re: [tor-bugs] #24030 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#24030: Wrap types in protover.rs
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * 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] #24849 [Core Tor/Tor]: Added -1 signatures to consensus

[Tor Bug Tracker & Wiki]

#24849: Added -1 signatures to consensus
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sr, tor-ddos, 032-backport,  |  Actual Points:
  logs, review-group-31  |
Parent ID:  #24815   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

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

Re: [tor-bugs] #25067 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#25067: Wrap types in protover.rs
--+--
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => rust
 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #24030 [Core Tor/Tor]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#24030: Wrap types in protover.rs
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 #25067 it 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] #25067 [- Select a component]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#25067: Wrap types in protover.rs
--+--
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by frewsxcv):

 * status:  new => needs_review
 * cc: coreyf+tor@… (added)


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

[tor-bugs] #25067 [- Select a component]: Wrap types in protover.rs

[Tor Bug Tracker & Wiki]

#25067: Wrap types in protover.rs
--+
 Reporter:  frewsxcv  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Introduce new wrapper types:

 - `SupportedProtocols`
 - `Versions`

 Introduce a type alias:

 - `Version` (`u32`)

 git branch: https://github.com/frewsxcv/tor/compare/master...frewsxcv-
 protover

 Patch for https://trac.torproject.org/projects/tor/ticket/24030

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

Re: [tor-bugs] #24639 [Core Tor/Tor]: After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errors

[Tor Bug Tracker & Wiki]

#24639: After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn
errors
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25061 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:  #24902 => #25061


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

Re: [tor-bugs] #25050 [Metrics/Relay Search]: add sum row at the bottom of the search results

[Tor Bug Tracker & Wiki]

#25050: add sum row at the bottom of the search results
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 stumbled on a bug while doing so, the following says: "0 distinct
 autonomous systems":
 
https://atlas.torproject.org/#aggregate/all/family:92A6085EABAADD928B6F8E871540A1A41CBC08BA

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

Re: [tor-bugs] #25050 [Metrics/Relay Search]: add sum row at the bottom of the search results

[Tor Bug Tracker & Wiki]

#25050: add sum row at the bottom of the search results
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Actually, you can aggregate arbitrary things.

 https://atlas.torproject.org/#aggregate/all/version:0.3.0.%20running:true

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

Re: [tor-bugs] #24639 [Core Tor/Tor]: After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errors

[Tor Bug Tracker & Wiki]

#24639: After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn
errors
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24902 | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 I think this is #25061.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25066 [Core Tor/Tor]: Rendezvous points should return signed proof of the established rend point

[Tor Bug Tracker & Wiki]

#25066: Rendezvous points should return signed proof of the established rend 
point
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  needs-proposal
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Right now our protocol has a vulnerability where you can send an introduce
 attempt without actually establishing the rendezvous point that you send
 the onion service toward.

 If the establish_rendezvous attempt sent back a signed acknowledgment from
 the relay, then you could include that signed acknowledgment in your
 introduce attempt, and the onion service could use it to decide whether to
 answer.

 In the short term, when most people aren't including it, onion services
 would want to answer even when it's missing. But under load, or in the
 future where most people should be sending them, onion services could opt
 to discard introduction attempts that are missing a proof-of-rendezvous-
 point (or that provide a proof from a relay that the onion service doesn't
 know about).

 This idea needs some crypto design where we want to choose a compact
 efficient-to-compute thing that the relay can return. And also we want to
 figure out which key should be signing it. And we probably want some sort
 of timestamp in the blob so onion services can discard really old ones.

 Note that there's some flexibility for how we accomplish this goal, for
 example, if it helps we could change things so the relay tells the client
 what rendezvous cookie it can use.

 (When I say efficient, I'll note that my relay right now is receiving
 about 160 establish-rendezvous attempts per second, sustained -- and
 that's after discarding the ones from tor2web clients.)

 I am also open to other smart ideas on how best to resolve the protocol
 flaw. :)

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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor2
--+

Comment (by arma):

 For those who want to try the patch, here is what I'm running currently:

 {{{
 diff --git a/src/or/connection_or.c b/src/or/connection_or.c
 index dadfdc4..ecc1ae4 100644
 --- a/src/or/connection_or.c
 +++ b/src/or/connection_or.c
 @@ -603,6 +603,9 @@ connection_or_flushed_some(or_connection_t *conn)
  {
size_t datalen;

 +  /* Update the channel's active timestamp */
 +  channel_timestamp_active(TLS_CHAN_TO_BASE(conn->chan));
 +
/* The channel will want to update its estimated queue size */
channel_update_xmit_queue_size(TLS_CHAN_TO_BASE(conn->chan));

 }}}
 It is alas a rare log message for me, so it's hard to easily tell if I
 have resolved the issue. Maybe somebody who is getting the log message
 more often than I am can try it too?

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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by gk):

 Replying to [comment:19 dcf]:
 > Replying to [comment:10 mcs]:
 > > '''Problem 1:''' The meek tunnel does not work reliably for us.
 Specifically, if we use curl as the SOCKS client it seems to always work
 and if we use Tor Browser it does not. When we test with our own meek-
 server + BridgeDB, things also work fine. I am having trouble debugging
 the meek-client code, probably due to my lack of golang knowledge, but I
 wonder if there is an incompatibility between the meek-client we are
 running and the meek-server that you are running. What version of meek-
 server are you using at tor-bridges-hyphae-channel.appspot.com? Kathy and
 I are using a meek-client that was built from dcf's bug24642 branch (and I
 don't know of any recent changes to meek that would cause this kind of
 communication problem).
 > >
 > > Another data point: if I insert an socat pipe between the meek-client
 SOCKS port and Tor Browser, it started working. Maybe there is a data
 buffering issue at work here. All of our client side testing so far has
 been on macOS.
 >
 > I was debugging this problem today and I traced the cause to Tor
 Browser's [https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.6.0esr-8.0-2&id=6d594cc227f153364b91e8310d59a07d7d6ce5f6
 optimistic SOCKS data patch] (#3875), which allows the browser to start
 sending application data right after sending its SOCKS request, before the
 proxy has sent back a reply saying that the connection was successful.

 Wow, thanks a lot for this analysis. Let me skip over it to jump to your
 conclusions part...

 > So a short-term workaround is to add an artificial delay into meek-
 client to prevent it from sending back the SOCKS response immediately. The
 delay has to go [https://gitweb.torproject.org/pluggable-
 transports/meek.git/tree/meek-client/meek-
 client.go?h=bug24642&id=8c0e2c8601e87687a2f147a875753ac298b52a2e#n278 just
 before conn.Grant] in meek-client.go. I think that's the reason why it
 worked with a socat shim--the extra process tweaked the timing just
 enough.

 Given that the analysis shows that at least part of the problem is due to
 the patch itself and how it interacts with the other Firefox networking
 code I think we should back it out and rewrite it if we want to keep it.
 We actually have #19910 for that and I think the OP describes a scenario
 that is compatible with the one you are seeing.

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

Re: [tor-bugs] #25012 [Applications/Tor Browser]: Tor Browser 7.5 doesn't have a Browser/TorBrowser/Docs/sources/versions file

[Tor Bug Tracker & Wiki]

#25012: Tor Browser 7.5 doesn't have a Browser/TorBrowser/Docs/sources/versions
file
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:15 gk]:
 >
 > They were available in alpha releases weeks and months before to test
 different configurations and patches. Yet no one came up and filed a bug
 about torbrowser-launcher being broken. The reasons for that might
 manifold but, yes, I think torbrowser-launcher being barely maintained is
 at least one of them and not being any communication about what
 torbrowser-launcher needs and uses is another.

 By the way, if someone wants to add an option to torbrowser-launcher to be
 able to select the alpha channel instead of the stable one, I think this
 would help to detect this kind of issues 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] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, review-group-31  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

 Should we let this ticket open until someone hits this issue with the
 debugging patch?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25065 [Obfuscation/Pluggable transport]: goptlib doesn't allow optimistic SOCKS data

[Tor Bug Tracker & Wiki]

#25065: goptlib doesn't allow optimistic SOCKS data
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Minor|   Keywords:  goptlib
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 goptlib [https://gitweb.torproject.org/pluggable-
 
transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n203
 wraps its socket] in a [https://golang.org/pkg/bufio/#ReadWriter
 bufio.ReadWriter] while processing the SOCKS handshake. Before returning
 the socket back to the application, [https://gitweb.torproject.org
 /pluggable-
 
transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n437
 it makes sure] there is no unread data sitting in the buffer (which would
 otherwise be lost).

 In #24432, we're trying to have Tor Browser use meek-client as a proxy
 directly, not going through Tor. The problem (comment:19:ticket:24432) is
 that Tor Browser has a special optimistic data SOCKS patch that causes it
 to send data exactly where goptlib checks to make sure there isn't any.

 A mild rewrite of goptlib's SOCKS code could eliminate the internal buffer
 and enable Tor Browser's optimistic data.

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

Re: [tor-bugs] #25012 [Applications/Tor Browser]: Tor Browser 7.5 doesn't have a Browser/TorBrowser/Docs/sources/versions file

[Tor Bug Tracker & Wiki]

#25012: Tor Browser 7.5 doesn't have a Browser/TorBrowser/Docs/sources/versions
file
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:10 cypherpunks]:
 > Replying to [comment:2 gk]:
 > > I am not convinced yet this is a Tor Browser bug. If we don't need a
 versions file (which we apparently don't do) then just adding one because
 torbrowser-launcher depends on it does not make much sense to me.
 Especially as it is barely maintained anymore. I think the much better
 solution would be to get this fixed on torbrowser-launcher's end.
 >
 > With all due respect, gk (and much is due!), the very fact that TBL ever
 needed to be written (and the fact that many people still use it) is
 itself an egregiously longstanding Tor Browser bug.
 >
 > How many Debian developers have worked for Tor over the years without
 getting this fixed? I can think of at least five, but there are probably
 more. Why is it still not possible to apt-get install Tor Browser??! How
 many times has a Tor Browser non-bug broken Micah's hacky solution to
 Tor's failure to package Tor Browser for Debian/Ubuntu/etc? WTH?

 Let me add some thoughts to this comment:

 1) I did not mean to imply that we don't care about a broken Tor Browser
 shipped by torbrowser-launcher, especially if we could have prevented
 that. Quite to the contrary, I am sorry for that. But I think that we
 learned from the versions file being necessary for torbrowser-launcher
 basically with this bug report is at least part of the problem. IIRC all
 of the broken things that we caused for torbrowser-launcher in the past
 did not come over night. They were available in alpha releases weeks and
 months before to test different configurations and patches. Yet no one
 came up and filed a bug about torbrowser-launcher being broken. The
 reasons for that might manifold but, yes, I think torbrowser-launcher
 being barely maintained is at least one of them and not being any
 communication about what torbrowser-launcher needs and uses is another.

 2) Regarding the missing Tor Browser packaging let me add that I'd be
 happy to review and merge (sets) of patches that would make this easier or
 possible at all in the first place. But someone other than us has to step
 up to do the work as we won't do it. What we want to do is getting rid of
 Tor Browser as a Firefox fork: we should *not* be needed to develop such a
 fork in the first place. Getting their privacy stuff right should be the
 priority of browser developers/manufacturers. And, look, we get there
 https://medium.com/read-write-participate/leveraging-tor-technology-in-
 firefox-3e40288995c8 albeit slowly and it took us years with all the
 effort we could manage. But, finally, there is light at the end of the
 tunnel. So, yes, if someone wants to have Tor Browser in Debian, please
 stand up and grab that project, but we will continue to put our efforts
 into making our fork obsolete instead.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 And thus ends my review. Looking good!

 I've been trying to figure out if I would want to set the consensus params
 with these defaults -- "if 100 concurrent conns, ones after that are
 refused" and "90 circuits, refilled 3 per second" -- and I think yes I am
 comfortable with those.

 In the future, I plan to advocate for merging dos_cc_new_create_cell() and
 dos_cc_get_defense_type() into a single function, which notes the
 existence of the new create cell and also tells us whether to apply a
 defense. And I plan to advocate for a second cc defense, which returns
 DOS_CC_DEFENSE_REFUSE_CELL simply when stats->cc_stats.circuit_bucket ==
 0, without any marking or checking of stats->concurrent_count. I think I
 will want to instrument a real relay to see how often it would trigger
 that new defense, though, and I am happy to delay my future plans so we
 can get this patch out the door.

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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--
Changes (by dcf):

 * Attachment "demo-socks5.go" 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] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by dcf):

 Replying to [comment:10 mcs]:
 > '''Problem 1:''' The meek tunnel does not work reliably for us.
 Specifically, if we use curl as the SOCKS client it seems to always work
 and if we use Tor Browser it does not. When we test with our own meek-
 server + BridgeDB, things also work fine. I am having trouble debugging
 the meek-client code, probably due to my lack of golang knowledge, but I
 wonder if there is an incompatibility between the meek-client we are
 running and the meek-server that you are running. What version of meek-
 server are you using at tor-bridges-hyphae-channel.appspot.com? Kathy and
 I are using a meek-client that was built from dcf's bug24642 branch (and I
 don't know of any recent changes to meek that would cause this kind of
 communication problem).
 >
 > Another data point: if I insert an socat pipe between the meek-client
 SOCKS port and Tor Browser, it started working. Maybe there is a data
 buffering issue at work here. All of our client side testing so far has
 been on macOS.

 I was debugging this problem today and I traced the cause to Tor Browser's
 [https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.6.0esr-8.0-2&id=6d594cc227f153364b91e8310d59a07d7d6ce5f6
 optimistic SOCKS data patch] (#3875), which allows the browser to start
 sending application data right after sending its SOCKS request, before the
 proxy has sent back a reply saying that the connection was successful.
 There are two ways that optimistic data causes problem when using meek-
 client as a SOCKS proxy.

  1. The first is that the SOCKS code in goptlib expects not to get any
 optimistic data: [https://gitweb.torproject.org/pluggable-
 
transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n363
 socksReadCommand] finishes by calling [https://gitweb.torproject.org
 /pluggable-
 
transports/goptlib.git/tree/socks.go?id=a3ad5df6c9e7dc8117f55958b4ce99bf1e0fe291#n472
 socksFlushBuffers], which raises an error if there is any data left in the
 read buffer (because otherwise the data would be silently lost when the
 SOCKS code passes the unbuffered socket back to the application). This
 doesn't happen always; it depends on the timing of how fast Firefox sends
 its application data. This issue doesn't seem very serious: we can modify
 the SOCKS code not to use an internal buffer and be tolerant of optimistic
 data. But on its own that is not enough, because
  2. Tor Browser has a race condition when the SOCKS proxy sends back its
 its reply immediately after receiving a request, as meek-client does. The
 SOCKS reply looks like `"\x05\x00\x00\x01\x00\x00\x00\x00\x00\x00"`; when
 it comes back too soon, Tor Browser reads the SOCKS response as if it were
 application data. Trying to parse SOCKS as TLS is what results in the
 connection failure. You can see this by going to
 [https://developer.mozilla.org/en-
 US/docs/Mozilla/Debugging/HTTP_logging#Using_aboutnetworking
 about:networking] and setting the Log Modules
 `timestamp,nsSocketTransport:5,SOCKS:5`. Follow the instructions in
 comment:11, and you will see this in the log:
 {{{
 D/SOCKS socks: DoHandshake(), state = 7
 D/SOCKS socks: ReadFromSocket(), have 2 bytes total
 D/SOCKS socks5: checking auth method reply
 D/SOCKS socks5: server allows connection without authentication
 D/SOCKS socks5: sending connection request (socks5 resolve? yes)
 D/SOCKS socks: DoHandshake(), state = 10
 D/nsSocketTransport   advancing to STATE_TRANSFERRING
 ...
 D/nsSocketTransport nsSocketTransport::OnSocketReady [this=7f2d4c2cbc00
 outFlags=1]
 D/SOCKS socks: DoHandshake(), state = 11
 D/SOCKS socks: ReadFromSocket(), have 5 bytes total
 D/SOCKS socks5: checking connection reply
 E/SOCKS socks5: unexpected version in the reply
 }}}
 "unexpected version in the reply" comes from
 [https://gitweb.torproject.org/tor-
 browser.git/tree/netwerk/socket/nsSOCKSIOLayer.cpp?h=tor-
 browser-52.6.0esr-8.0-2&id=5e2ac8aed83692c340c8ce219eaa116cf1da2654#n988
 ReadV5ConnectResponseTop]. It's because the application layer and the
 SOCKS layer are fighting over who gets to read data from the socket.
 `state = 10` is [https://gitweb.torproject.org/tor-
 browser.git/tree/netwerk/socket/nsSOCKSIOLayer.cpp?h=tor-
 browser-52.6.0esr-8.0-2&id=5e2ac8aed83692c340c8ce219eaa116cf1da2654#n55
 SOCKS5_WRITE_CONNECT_REQUEST] 

Re: [tor-bugs] #25051 [Applications/Tor Check]: https://check.torproject.org/?lang=en_US Offline

[Tor Bug Tracker & Wiki]

#25051: https://check.torproject.org/?lang=en_US Offline
+-
 Reporter:  Sleepy-Penguin  |  Owner:  arlolra
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Major   | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by gk):

 * owner:  tbb-team => arlolra
 * resolution:   => fixed
 * status:  new => closed
 * component:  Applications/Tor Browser => Applications/Tor Check
 * version:  Tor: unspecified =>


Comment:

 We are done here I think.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 {{{
   /* Number of allowed circuit rate that is this value is refilled at a
 rate
* defined by the consensus plus a bit of random. It is decremented
 every
* time a new circuit is seen for this client address and if the count
 goes
* to 0, we have a positive detection. */
   uint32_t circuit_bucket;
 }}}

 (a) should be "Number of allocated circuits remaining for this address",
 i.e. it's not a rate, it's a size.

 (b) What's this about "plus a bit of random"? :)

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

Re: [tor-bugs] #25056 [Applications/Tor Browser]: Tor browser sometimes hangup for a few seconds

[Tor Bug Tracker & Wiki]

#25056: Tor browser sometimes hangup for a few seconds
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 OP here.

 It's really happening randomly. I've monitored Browser Console but there's
 no useful info.
 Happened when I clicked this textarea(Add Comment), or clicked a link, or
 just scrolling, etc.

 So I did some research and I think I fixed the problem.

 
https://www.reddit.com/r/firefox/comments/5r7emp/firefox_very_low_performance_on_youtube_videos/

 media.webm.enabled = false

 Really worked.

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