Re: [tor-bugs] #22137 [Applications/Tor Browser]: Provide the same scrollbar size across different platforms

[Tor Bug Tracker & Wiki]

#22137: Provide the same scrollbar size across different platforms
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID:  #18283 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by Thorin):

 * Attachment "scrollbar-overlay.png" added.

 mouseover (top image) changes the transparency

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

Re: [tor-bugs] #22137 [Applications/Tor Browser]: Provide the same scrollbar size across different platforms

[Tor Bug Tracker & Wiki]

#22137: Provide the same scrollbar size across different platforms
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID:  #18283 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by Thorin):

 Replying to [comment:9 gk]:
 > I think what we need to figure out in this ticket first is the approach
 we want to take to solve this issue. I am not a huge fan of shipping some
 `userChrome.css` etc.

 Come ESR78, this solution won't even be available anymore as XBL/XUL is
 ripped out AFAIK

 > if we have the option to easily patch the browser ourselves (which we
 have) as patching seems less complex and error-prone to me and we want to
 upstream the fix to Firefox anyway. (That way everyone can benefit.) The
 easiest and sufficient solution might still be to just give a fixed value,
 say 17px, back for all platforms.

 I'd still pump for an overlay (but only code it for desktop I guess) -
 this way **all** platforms are the same.

 The `css` file binds the `xml` file, which in turn runs the `js` file:
 which is 90 lines long, including adding a menu option to turn it on and
 off (which is at least half of it). It isn't much - 30 lines of css (in
 the js file). I would add  tying the color to the theme
 (light/dark/default), choose our own thickness and transparency. And it
 works on all scrollbars: in elements (iframes, textareas), horizontal,
 vertical: and it's never caused me any issues in two years or so.

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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha, ff68-esr, ux-|  Actual Points:
  team, TorBrowserTeam201910R|
Parent ID:  #10760   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by pospeselr):

 I've since amended the tor-launcher review branch to include the required
 fixes (removing colons, migrating some existing strings from
 torlauncher.properties using the attached script:
 
https://trac.torproject.org/projects/tor/attachment/ticket/31286/31286_stringfix.sh
 )

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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha, ff68-esr, ux-|  Actual Points:
  team, TorBrowserTeam201910R|
Parent ID:  #10760   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by pospeselr):

 * Attachment "31286_stringfix.sh" 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] #27268 [Applications/Tor Browser]: preferences cleanup

[Tor Bug Tracker & Wiki]

#27268: preferences cleanup
-+-
 Reporter:  rzb  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201910R, |  Actual Points:
  GeorgKoppen201910  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:23 Thorin]:
 > Replying to [comment:22 gk]:
 > > > And I don't see a dom.netinfo.enabled in the tor button code
 > >
 > > Hrm. I am not sure yet what we should do. While we don't defend
 against os fingerprinting leaving the netinfo state the way it is seems a
 bit lame. I guess we should disable it everywhere?
 >
 > I agree. Lets not give away free entropy... make the bastards work for
 it. Ideally, upstream we should make RFP measures more robust and anti-
 tamperable (e.g.  from about:config tweakers)

 Actually, we had the discussion about what to do in #27257 already but
 lost track of it it seems...

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

Re: [tor-bugs] #19417 [Applications/Tor Browser]: asm.js files should be no linkability risk

[Tor Bug Tracker & Wiki]

#19417: asm.js files should be no linkability risk
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-linkability, |  Actual Points:  0.5
  GeorgKoppen201610R, ff68-esr,  |
  TorBrowserTeam201910R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 FWIW, the fix on the `tor-browser` side landed on `tor-
 browser-68.1.0esr-9.0-2` (5e45bc82579d4d712e0f34cb58ad62f1030127ca).

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

Re: [tor-bugs] #31786 [Internal Services/Tor Sysadmin Team]: move dictyotum off moly

[Tor Bug Tracker & Wiki]

#31786: move dictyotum off moly
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 it's unclear what happened, but i think restarting the director service
 solved it the emails were still coming in and the backups were not
 being recorded in `status director` in the bacula console. now that i
 restarted the director, backups seem to be queueing in from the scheduler
 and are being recorded in the `status director` output.

 let's see if this plane can fly for a day now.

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

Re: [tor-bugs] #31786 [Internal Services/Tor Sysadmin Team]: move dictyotum off moly

[Tor Bug Tracker & Wiki]

#31786: move dictyotum off moly
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 those are unrelated errors after all, and the tor-backup password changed
 because that password *is* in puppet so it was uniquely generated for the
 new director. i reset the password and started a base backup by hand,
 which seems to be working correctly now, and running in screen.

 documented in the wiki as well.

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

Re: [tor-bugs] #31786 [Internal Services/Tor Sysadmin Team]: move dictyotum off moly

[Tor Bug Tracker & Wiki]

#31786: move dictyotum off moly
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 the email email message was silenced by changing the cluster name in the
 `archive_command` in `/etc/postgresql/9.6/main/conf.d/tor.conf`.

 not sure about the former, it triggered again abuot 20 minutes ago which
 seems to correlate with the last email warning, so maybe that is fixed as
 well? undetermined - i don't understand why the tor-backup password would
 have chnaged here since it should be on the bungei side of things. i did
 not change that password in the deployment.

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

Re: [tor-bugs] #32048 [Core Tor/Tor]: Loading a high number of Onion V3 Descriptors trough Tor Control Port lead to sustained 100% CPU

[Tor Bug Tracker & Wiki]

#32048: Loading a high number of Onion V3 Descriptors trough Tor Control Port 
lead
to sustained 100% CPU
--+
 Reporter:  naif  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Do you think you could get an profile from 'perf' or 'oprofile'?  The set
 of library functions that ltrace is reporting suggests that might not be
 so hard to fix, but to do so, we'll need some way to figure out what place
 in Tor is spending so much of its time in string processing for this case.

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

Re: [tor-bugs] #32048 [- Select a component]: Loading a high number of Onion V3 Descriptors trough Tor Control Port lead to sustained 100% CPU

[Tor Bug Tracker & Wiki]

#32048: Loading a high number of Onion V3 Descriptors trough Tor Control Port 
lead
to sustained 100% CPU
--+
 Reporter:  naif  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #31786 [Internal Services/Tor Sysadmin Team]: move dictyotum off moly

[Tor Bug Tracker & Wiki]

#31786: move dictyotum off moly
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 more problems this morning:

 {{{
 2019-10-12 05:53:41.638 UTC [18889] tor-backup@[unknown] FATAL:  password
 authentication failed for user "tor-backup"
 2019-10-12 05:53:41.638 UTC [18889] tor-backup@[unknown] DETAIL:  Password
 does not match for user "tor-backup".
 Connection matched pg_hba.conf line 108: "hostssl replication
 tor-backup  2a01:4f9:2b:1a05::2/128 md5 "
 }}}

 and also:

 {{{
 From: bacula-serv...@torproject.org
 Subject: Bacula: Backup Fatal Error of mandos-01.torproject.org-fd
 Differential
 To: bacula-serv...@torproject.org
 Date: Sat, 12 Oct 2019 14:08:27 +

 12-Oct 14:05 bacula-director-01.torproject.org-dir JobId 0: Fatal error:
 bdb.h:142 bdb.h:142 query SELECT
 ClientId,Uname,AutoPrune,FileRetention,JobRetention FROM Client WHERE
 Name='mandos-01.torproject.org-fd' failed:
 no connection to the server

 12-Oct 14:06 bacula-director-01.torproject.org-dir JobId 0: Error:
 sql_create.c:524 Create DB Client record INSERT INTO Client
 (Name,Uname,AutoPrune,FileRetention,JobRetention) VALUES
 ('mandos-01.torproject.org-fd','',1,2592000,864) failed. ERR=no
 connection to the server

 12-Oct 14:07 bacula-director-01.torproject.org-dir JobId 0: Fatal error:
 Could not create Client record. ERR=Query failed: INSERT INTO Log (JobId,
 Time, LogText) VALUES (0,'2019-10-12 14:06:47','bacula-
 director-01.torproject.org-dir JobId 0: Error: sql_create.c:524 Create DB
 Client record INSERT INTO Client
 (Name,Uname,AutoPrune,FileRetention,JobRetention) VALUES
 (''mandos-01.torproject.org-fd'',,1,2592000,864) failed. ERR=no
 connection to the server

 '): ERR=no connection to the server


 weasel also pointed out that the `archive_command` that was set is
 incorrect as it points to the old cluster name (`bacula`), that was fixed
 in the config and the docs were updated to check that on deployment.

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

Re: [tor-bugs] #8560 [Applications/Tor Browser]: 100% CPU usage in Tor Browser?

[Tor Bug Tracker & Wiki]

#8560: 100% CPU usage in Tor Browser?
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:| Resolution:
 Keywords:  tbb-firefox-patch |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Anonymous75):

 for me in windows too like this with tor browser 8.5.5

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

[tor-bugs] #32048 [- Select a component]: Loading a high number of Onion V3 Descriptors trough Tor Control Port lead to sustained 100% CPU

[Tor Bug Tracker & Wiki]

#32048: Loading a high number of Onion V3 Descriptors trough Tor Control Port 
lead
to sustained 100% CPU
+--
 Reporter:  naif|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  - Select a component
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Loading a high number of Onion V3 Descriptors trough Tor Control Port lead
 to sustained 100% CPU.

   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+
 COMMAND
  1516 debian-+  20   0  136604 122136   8880 R 100.0   6.0  95:16.49 tor

 This is a GlobaLeaks system, try.globaleaks.org that have more than 1200
 evaluation whistleblowing sites.

 Trying profiling with strace and ltrace gives those data, if could be
 interesting to diagnose what's the issue:

 root@scw-nostalgic-stonebraker:/var/log# strace -f -c -p 1516
 strace: Process 1516 attached
 strace: [ Process PID=1516 runs in x32 mode. ]
 strace: [ Process PID=1516 runs in 64 bit mode. ]
 ^Cstrace: Process 1516 detached
 % time seconds  usecs/call callserrors syscall
 -- --- --- - - 
 100.000.008475  15   560   getpid
   0.000.00   036   read
   0.000.00   022   write
   0.000.00   0 1   close
   0.000.00   0 6   ioctl
   0.000.00   0 7   sendto
   0.000.00   0 6   getsockopt
   0.000.00   0 1   rename
   0.000.00   0 2   epoll_wait
   0.000.00   014   epoll_ctl
   0.000.00   0 1   openat
   0.000.00   064   getrandom
 -- --- --- - - 
 100.000.008475   720   total

 root@scw-nostalgic-stonebraker:/var/log# ltrace -c -f -p 1516
 ^C% time seconds  usecs/call calls  function
 -- --- --- - 
  25.292.614242 127 20496 strlen
  24.992.583754 126 20489 free
  24.932.577376 125 20496 memset
  24.702.553016 124 20485 strchr
   0.020.002249 17313 gettimeofday
   0.020.001980  9421 time
   0.010.001290  8615 __vsnprintf_chk
   0.010.000653 130 5 pthread_mutex_lock
   0.010.000642 128 5 pthread_mutex_unlock
   0.000.000494  82 6 strcasecmp
   0.000.000494  98 5 __vasprintf_chk
   0.000.000439  87 5 pthread_getspecific
   0.000.000423  84 5 event_active
   0.000.000420  84 5 malloc
 -- --- --- - 
 100.00   10.337472 82051 total

 Tor version 0.3.5.8-1 is stock on Ubuntu Bionic .

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

Re: [tor-bugs] #32004 [Circumvention]: Protect Against Blocking and Spying in Iran

[Tor Bug Tracker & Wiki]

#32004: Protect Against Blocking and Spying in Iran
---+--
 Reporter:  Anonymous75|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Circumvention  |Version:  Tor: 0.4.1.5
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by Anonymous75):

 Replying to [comment:1 cypherpunks]:
 > Can you try the `snowflake` pluggable transport? (It's available in all
 alpha builds of the Tor Browser, Windows is slow for now though)

 Can you give information about 'snowflake' pluggale transport please?

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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha, ff68-esr, ux-|  Actual Points:
  team, TorBrowserTeam201910R|
Parent ID:  #10760   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Awesome work! The changes in `bug_31286_review3` look reasonable to me.
 They still need a closer look, but I think we can use what we have for the
 alpha release.

 I merged `bug_31286_review3` to `tor-browser-68.1.0esr-9.0-2´ (commit
 bd4082f2f1db8a1f1c135d6d1689242f7c659a19).

 Some nits:

 1) You now have a `"strict;";` in your `BridgeDB.jsm`. (I fixed this in a
 fixup commit (109c1defa853ec6364c66a72b3554ea05304dd3f))
 2) You now have
 {{{
 // console.log(`${setting} : ${value}`);
 }}}
 in `TorProtocolService.jsm`. If we don't want to log don't comment the
 code just delete 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] #27268 [Applications/Tor Browser]: preferences cleanup

[Tor Bug Tracker & Wiki]

#27268: preferences cleanup
-+-
 Reporter:  rzb  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201910R, |  Actual Points:
  GeorgKoppen201910  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 Replying to [comment:22 gk]:
 > > And I don't see a dom.netinfo.enabled in the tor button code
 >
 > Hrm. I am not sure yet what we should do. While we don't defend against
 os fingerprinting leaving the netinfo state the way it is seems a bit
 lame. I guess we should disable it everywhere?

 I agree. Lets not give away free entropy... make the bastards work for it.
 Ideally, upstream we should make RFP measures more robust and anti-
 tamperable (e.g.  from about:config tweakers)

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