Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
---+---
 Reporter:  catalyst   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by iry):

 * cc: iry (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] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
---+-
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201709  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+-
Changes (by iry):

 * cc: iry (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] #23605 [Core Tor/Tor]: BOOTSTRAP PROGRESS=80 is a lie

[Tor Bug Tracker & Wiki]

#23605: BOOTSTRAP PROGRESS=80 is a lie
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew tor-guard   |  Actual Points:
  usability ux   |
Parent ID:  #22266   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by iry):

 * cc: iry (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] #22719 [Core Tor/Tor]: Bug: src/common/compress.c:576: tor_compress_process:

[Tor Bug Tracker & Wiki]

#22719: Bug: src/common/compress.c:576: tor_compress_process:
--+
 Reporter:  toralf|  Owner:  nickm
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * status:  closed => reopened
 * version:  Tor: unspecified => Tor: 0.3.1.7
 * resolution:  fixed =>


Comment:

 I am hitting this assertion now in the released stable on Arch Linux.

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

Re: [tor-bugs] #15618 [Core Tor/Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs needs-insight needs-  |  Actual Points:
  diagnosis  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Update: Tor `0.3.2.0-alpha-dev (git-209bfe715cc8c1c5)`, log file start
 02-Sept-2017 - end 30-Sept-2017:
 {{{
 root@server1:~ # cat /var/log/tor | grep "Tried to establish rendezvous on
 non-OR circuit with purpose Acting as rendevous (pending)" | wc -l
  334
 }}}

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+--
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * Attachment "0001-Bug-13398-at-startup-browser-gleans-user-FULL-
 NAME-r.patch" added.

 Properly formatted patch, no code changes

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

Re: [tor-bugs] #20898 [Internal Services/Service - trac]: Trac has overly restrictive filters for updating the wiki

[Tor Bug Tracker & Wiki]

#20898: Trac has overly restrictive filters for updating the wiki
--+
 Reporter:  heartsucker   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 When I look at the last 1000 spam attempts, 760 used a blacklisted pattern
 (most of them the `http:` thing). However trac has now some improved spam
 catching mechanisms. So in most of the cases the blacklisted `http:` was
 not really needed. So I decided to delete this listing and will watch what
 happens. If there is too much spam, I'll re-enable 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] #23405 [Internal Services/Service - trac]: My trac password was reset: is this a trac bug?

[Tor Bug Tracker & Wiki]

#23405: My trac password was reset: is this a trac bug?
--+
 Reporter:  teor  |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 We had a very high number of people who tried to create spammer accounts.
 This seemed to cause problem with the accountmanager plugin. Since I
 implemented some anti-spam measures the number of successful logins
 decreased and the `trac.users` file was not mangled. So i assume this
 behaviour is gone and thus close the bug.

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, tor-sched, easy, |  Actual Points:
  0.3.2.2-alpha-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merged

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

Re: [tor-bugs] #20736 [Internal Services/Service - trac]: IndexError: pop from empty list

[Tor Bug Tracker & Wiki]

#20736: IndexError: pop from empty list
--+
 Reporter:  michaelsonntag|  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 It seems people can add attachments without problems. So closing this bug
 report.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Yeah pdf gets saved to ~/Tor\ Browser successfully on both en-us and fr
 skus

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

Re: [tor-bugs] #20771 [Internal Services/Service - trac]: support multiple componenet owners

[Tor Bug Tracker & Wiki]

#20771: support multiple componenet owners
--+-
 Reporter:  mrphs |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by qbi):

 As far as I see it the only way we have is to make a "virtual user" in
 trac and set a email alias or use a mailing list.

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy, |  Actual Points:
  0.3.2.2-alpha-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 Replying to [comment:10 nickm]:
 > This seems okay to me. I'll merge it once isis/ahf say "go"

 go

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance 031-backport 030-backport  |
  029-backport   |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-relay logging needs-analysis harmless? annoyance =>
 tor-relay logging needs-analysis harmless? annoyance 031-backport
 030-backport 029-backport
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 Okay. I've merged bug8185_diagnostic_032 and bug8185_031 into master.
 I'll mark the latter for possible backport.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:16 pospeselr]:
 > Replying to [comment:15 gk]:
 > > Replying to [comment:14 pospeselr]:
 > > > Ok, so I've gotten some similar behaviour as expressed in this bug.
 In latest Tails when attempting to save to the tor-browser folder (
 /usr/local/lib/tor-browser ) the print to file functionality seems to fail
 silently, which makes sense as the amnesia user doesn't have write
 permissions there.  However, the UI does not provide any indication of
 file write failure.  As expected, the multiprocessing option also has no
 effect in this scenario.
 > >
 > > What happens if you choose a writable path?
 > >
 > > > Does this error happen for y'all on 64 or 32-bit?  I've been doing
 all my testing on 64-bit so far.
 > >
 > > 64-bit.
 >
 > So, interestingly enough on Tails Tor Browser  (version 7.0.6) only
 seems to be able to write to /home/amnesia/Tor\ Browser.  Other valid
 paths (~, ~/Documents, ~/media/amnesia/Disk) are not writable and any
 attempt to do so fails silently (including saving an image, saving a web-
 page, printing).  File browser also refuses to even read contents of any
 folder except for /home/amnesia/Tor\ Browser and Tor Browser's
 installation directory.
 >
 > The browser.tabs.remote.autostart.2 has no effect one way or the other.
 >
 > Tor Browser (version 7.0.6) does not exhibit this behaviour on my local
 install (Ubuntu 17.04), ie I can pretty much read/write anywhere that's
 consistent with folder permissions.  Is Tor Browser in Tails more
 restricted somehow?

 Yes, I think so. Did you get anything printed to /home/amnesia/Tor\
 Browser? If so, is it working with, say, Tails in French 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] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-

Comment (by isis):

 Replying to [comment:50 ahf]:
 > I think both the diagnostic patch and the proposed fix looks good.
 >
 > Isis: do you think this should go into 0.3.2.2-alpha? I think this could
 be marked as merge ready.

 Yeah, this should go in, especially the diagnostics. I'm not ''wholly''
 convinced the fix will actually fix this bug, since (in my experience) I
 believe I was hitting this bug while in the process of constructing a
 (loose-source) circuit, but nonetheless it's a good theory and the fix is
 a logical thing to do even if it doesn't end up fixing this bug entirely.

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

Re: [tor-bugs] #18807 [Internal Services/Service - trac]: Trac Error: OSError: [Errno 12] Cannot allocate memory

[Tor Bug Tracker & Wiki]

#18807: Trac Error: OSError: [Errno 12] Cannot allocate memory
--+
 Reporter:  bugzilla  |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 I couldn't reproduce this behaviour. So I close this bug for now. Maybe it
 was an temporary error.

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

Re: [tor-bugs] #17547 [Internal Services/Service - trac]: Cypherpunks account can be deleted and cannot be easily recreated.

[Tor Bug Tracker & Wiki]

#17547: Cypherpunks account can be deleted and cannot be easily recreated.
--+---
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  cypherpunks, account, trac|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by qbi):

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


Comment:

 Dupe of #13629

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

Re: [tor-bugs] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 merged to master!  Is this ready to close?

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

Re: [tor-bugs] #23207 [Internal Services/Service - trac]: Registration on trac seems to be counterintuitive

[Tor Bug Tracker & Wiki]

#23207: Registration on trac seems to be counterintuitive
--+
 Reporter:  mail@…|  Owner:  qbi
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


Comment:

 It seems the line
 {{{
 verify_email = disabled
 }}}
 did the trick.
 After I set this option I couldn't reproduce the behaviour above. So a
 login with a longer username is possible (In most cases people will have
 to solve a CAPTCHA.).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Replying to [comment:15 gk]:
 > Replying to [comment:14 pospeselr]:
 > > Ok, so I've gotten some similar behaviour as expressed in this bug.
 In latest Tails when attempting to save to the tor-browser folder (
 /usr/local/lib/tor-browser ) the print to file functionality seems to fail
 silently, which makes sense as the amnesia user doesn't have write
 permissions there.  However, the UI does not provide any indication of
 file write failure.  As expected, the multiprocessing option also has no
 effect in this scenario.
 >
 > What happens if you choose a writable path?
 >
 > > Does this error happen for y'all on 64 or 32-bit?  I've been doing all
 my testing on 64-bit so far.
 >
 > 64-bit.

 So, interestingly enough on Tails Tor Browser  (version 7.0.6) only seems
 to be able to write to /home/amnesia/Tor\ Browser.  Other valid paths (~,
 ~/Documents, ~/media/amnesia/Disk) are not writable and any attempt to do
 so fails silently (including saving an image, saving a web-page,
 printing).  File browser also refuses to even read contents of any folder
 except for /home/amnesia/Tor\ Browser and tor's installation directory.

 The browser.tabs.remote.autostart.2 has no effect one way or the other.

 Tor Browser (version 7.0.6) does not exhibit this behaviour on my local
 install (Ubuntu 17.04), ie I can pretty much read/write anywhere that's
 consistent with folder permissions.  Is Tor Browser in Tails more
 restricted somehow?

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

Re: [tor-bugs] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 I also reviewed dgoulet's `bug23676_032_03`, and I agree that it should be
 merged for the alpha so that we can further diagnose the other possible
 issues/causes.

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23714 [Core Tor/Tor]: stop casting small integers to (void *)

[Tor Bug Tracker & Wiki]

#23714: stop casting small integers to (void *)
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  portability technical-debt
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Recently someone on IRC seemed confused about some `(void *)` variables
 holding the value `(void *)1`.  Converting integers to pointers is
 implementation defined, and could create invalid pointers.  (Any use of an
 invalid pointer, including assignment or comparison, is undefined
 behavior.)  In addition, it's confusing to people who are less familiar
 with C.

 Many of these uses seem to involve container types that treat a null
 pointer as an absence of an entry, but in situations there's no meaningful
 object to point to if the entry is present.  Storing the addresses of
 small statically allocated objects might be better.

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy, |  Actual Points:
  0.3.2.2-alpha-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This seems okay to me. I'll merge it once isis/ahf say "go"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:14 pospeselr]:
 > Ok, so I've gotten some similar behaviour as expressed in this bug.  In
 latest Tails when attempting to save to the tor-browser folder (
 /usr/local/lib/tor-browser ) the print to file functionality seems to fail
 silently, which makes sense as the amnesia user doesn't have write
 permissions there.  However, the UI does not provide any indication of
 file write failure.  As expected, the multiprocessing option also has no
 effect in this scenario.

 What happens if you choose a writable path?

 > Does this error happen for y'all on 64 or 32-bit?  I've been doing all
 my testing on 64-bit so far.

 64-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] #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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Ok, so I've gotten some similar behaviour as expressed in this bug.  In
 latest Tails when attempting to save to the tor-browser folder (
 /usr/local/lib/tor-browser ) the print to file functionality seems to fail
 silently, which makes sense as the amnesia user doesn't have write
 permissions there.  However, the UI does not provide any indication of
 file write failure.  As expected, the multiprocessing option also has no
 effect in this scenario.

 Does this error happen for y'all on 64 or 32-bit?  I've been doing all my
 testing on 64-bit so far.

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

Re: [tor-bugs] #23263 [Applications/Tor Browser]: Rip out startup GfxSanityTest entirely

[Tor Bug Tracker & Wiki]

#23263: Rip out startup GfxSanityTest entirely
--+--
 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):

 {{{
 +// Only test gfx features if firefox has updated, or if the user has
 a new
 +// gpu or drivers.
 }}}
 https://hg.mozilla.org/mozilla-central/rev/a53b5cee6b6f#l3.108

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

Re: [tor-bugs] #23678 [Core Tor/Tor]: Tor kinda _is_ an http proxy now...

[Tor Bug Tracker & Wiki]

#23678: Tor kinda _is_ an http proxy now...
-+
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy tor-doc ux  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by catalyst):

 * keywords:   => easy tor-doc ux


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

Re: [tor-bugs] #23695 [Core Tor/Tor]: Add resource on writing Rust FFI to doc/HACKING/GettingStartedRust.md

[Tor Bug Tracker & Wiki]

#23695: Add resource on writing Rust FFI to doc/HACKING/GettingStartedRust.md
-+
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust-pilot, tor-doc  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy, |  Actual Points:
  0.3.2.2-alpha-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 See branch: `ticket23696_032_01`.

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

[tor-bugs] #23713 [Metrics/Onionoo]: Add as_name parameter

[Tor Bug Tracker & Wiki]

#23713: Add as_name parameter
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Currently one can search for relays in a specific AS with the as
 parameter,
 but you can not search for all relays with a given as_name (big
 organizations have multiple ASes).

 background:
 I'd like to make the entries in this table clickable atlas URLs
 https://nusenu.github.io/OrNetStats/#top-10-autonomous-system-names-by-cw-
 fraction

 Note: as_names usually contain 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] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


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

Re: [tor-bugs] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pastly):

 Replying to [comment:20 dgoulet]:
 > Would be nice if pastly ACK it before any merge.

 Consider it ACKed.

 Looked at it. It compiles. It passes all tests. Yes there's more issues
 (that have probably existed for a long time in some cases) but this is a
 good bandaid for this 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] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:19 nickm]:
 > Looks plausible. Did the debug message come up while you were testing
 this, so you know it's working?

 It does come up. It was info level before and I downgraded it to debug
 because it does happen regularly.  I've opened many tickets that could
 cause this but for the next alpha, this is the best we got for now
 (#23709, #23710, #23711, #23712).

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

Re: [tor-bugs] #23708 [Applications/Tor Browser]: Menu Bar and Bookmark Toolbar privacy consequences

[Tor Bug Tracker & Wiki]

#23708: Menu Bar and Bookmark Toolbar privacy consequences
--+---
 Reporter:  NavigaTor@…   |  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:
--+---
Changes (by cypherpunks):

 * status:  new => needs_information


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

Re: [tor-bugs] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Looks plausible. Did the debug message come up while you were testing
 this, so you know it's working?

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy, |  Actual Points:
  0.3.2.2-alpha-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:  tor-client, tor-sched, easy => tor-client, tor-sched, easy,
 0.3.2.2-alpha-must


Comment:

 I'm arguing that this MUST be in the next alpha. Trivial fix and would be
 good to avoid warnings for another 2 or 3 weeks ;).

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:6 pastly]:
 > nickm says we should just init `scheduler_last_run` in the scheduler
 init function, and init it to `now`.
 >
 > My only protest is that we didn't just run and will have to wait 10ms in
 order to actually do so for the first time, but that probably doesn't
 really matter.

 Yeah impact should be very minimal but the other option is now - 1 ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23712 [Core Tor/Tor]: sched: DESTROY cell on a circuit bypasses the scheduler

[Tor Bug Tracker & Wiki]

#23712: sched: DESTROY cell on a circuit bypasses the scheduler
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 If you look at `circuitmux_append_destroy_cell()`, it is the one appending
 a DESTROY cell to the cmux queue and then calls
 `channel_flush_from_first_active_circuit()` if no writes are pending that
 is if the outbuf is empty (also looks at the out queue but that is always
 empty #23709).

 In the case the flush is triggered, the cell is immediately put in the
 outbuf and written to kernel by libevent which completely bypasses the
 scheduler. Maybe it is what we want that is go as fast as we can in
 destroying a circuit? Don't know but it has this effect on the scheduler
 where the channel is scheduled with a "wants_to_write" event from the
 connection subsystem and ultimately the channel gets scheduled with
 nothing in the queue because it is already on the outbuf. For KIST, this
 is not ideal because KIST should control the flow of data to the kernel.

 It seems there are two places we queue cells into a cmux queue:
 `circuitmux_append_destroy_cell()` and `append_cell_to_circuit_queue()`.
 The latter triggers a "has waiting cells" for the scheduler which is what
 we want but the former just bypasses it.

 I think it should simply trigger that notify to the scheduler instead of
 flushing it by itself.

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

Re: [tor-bugs] #23697 [Webpages/Website]: List frontdesk, not execdir, on the contact page

[Tor Bug Tracker & Wiki]

#23697: List frontdesk, not execdir, on the contact page
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by alison):

 Wait, I'm confused about the purpose of frontdesk@. Originally, we created
 it in order to field support requests. Now according to this language, it
 is not for that. What is it for? And if it's going to be the email address
 for all the things, we need more than just me and Phoul answering it. Even
 if it were only support, 5-10 more emails a day is a lot for just two
 people to be managing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23711 [Core Tor/Tor]: sched: KIST writes to kernel and get a "wants to write" notification right after

[Tor Bug Tracker & Wiki]

#23711: sched: KIST writes to kernel and get a "wants to write" notification 
right
after
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 KIST scheduler does call a write to kernel contrary to the vanilla
 scheduler. This is done through `channel_write_to_kernel()` which calls
 `connection_handle_write()`.

 That last function will ultimately call `connection_or_flushed_some()`
 which triggers a `scheduler_channel_wants_writes()` because of this
 condition:

 {{{
   datalen = connection_get_outbuf_len(TO_CONN(conn));
   if (datalen < OR_CONN_LOWWATER) {
 scheduler_channel_wants_writes(TLS_CHAN_TO_BASE(conn->chan));
 }}}

 That is OK if `datalen > 0` but useless if `datalen == 0`. For KIST, it
 makes the channel go back in pending state and scheduled because it wants
 to write. But then if the outbuf or the cmux queue is empty, we end up
 scheduling a channel that actually does NOT need to write at all.

 Could be the fix here is probably simple as:

 {{{
   if (datalen > 0 && datalen < OR_CONN_LOWWATER) {
 }}}

 I suspect with KIST, the datalen will always be 0 because KIST in theory
 controls exactly what goes in the outbuf and what can be written to the
 kernel so when it triggers a connection write(), the entire outbuf should
 be drained (in theory). So the effect of this is that every write to the
 kernel from KIST triggers a useless "wants to write" event rescheduling
 the channel. Note that this only happens if the channel is in
 `SCHED_CHAN_WAITING_TO_WRITE` state.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23710 [Core Tor/Tor]: sched: channel_more_to_flush() is probably looking at the wrong queue

[Tor Bug Tracker & Wiki]

#23710: sched: channel_more_to_flush() is probably looking at the wrong queue
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In the scheduler (both vanilla and kist), we do flush cells from the
 `outgoing_queue` to the outbuf using `channel_flush_some_cells()`.

 However, once we are done and to know what state the channel should be in,
 we use `channel_more_to_flush()` that looks at two things, the
 `incoming_queue` and the number of cells in the `cmux`.

 It seems from my investigation that tor doesn't have this concept of
 "flushing cells from the incoming queue" so it doesn't make sense to look
 at it when we are trying to flush cells from the `outgoing_queue` to the
 outbuf so we can actually send() them.

 Thus, this function should look at the `outgoing_queue` in my opinion
 although if I'm right in #23709, all this could change.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23709 [Core Tor/Tor]: channel: `outgoing_queue` and `incoming_queue` are always empty

[Tor Bug Tracker & Wiki]

#23709: channel: `outgoing_queue` and `incoming_queue` are always empty
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 1. Let's start with the `incoming_queue` of a channel_t:

 The `channel_queue_(var)cell()` function is the one taking a single cell
 and putting it in the in queue.

  If the queue is empty, it processes the cell immediately.
  If the queue is NOT empty, it puts the cell in the queue and processes
 the cell immediately if we have cell handlers which is currently always
 the case.

 The "process cell" function is in charge of removing the cell from the
 queue. So I think you can clearly see the problem with this code flow ;).

 2. Now `outgoing_queue` of a channel_t:

 Inserting a cell in that queue is with `channel_write_cell_queue_entry()`
 which does it IFF the `outgoing_queue` is not empty and channel is open.
 If the queue is empty, the cell is processed immediately with the
 `write_cell` handler.

 If the cell was for whatever reason not able to be sent by the write
 handler, the cell is then put in the `outgoing_queue`. However, the only
 possible handler we have right now is `channel_tls_write_cell_method()`
 (and packed/var friends) that always return 1 if the `tlschan->conn`
 exists. Empirical test shows that it is really ALWAYS the case that a conn
 exists on the tls channel.

 ---

 Bottom line, those queues are as good as local to a function but we do
 consider them everywhere in the code such as in
 `channel_flush_some_cells()` or `channel_more_to_flush()`.

 We should either get rid of them or use them properly. For KIST, this is a
 big deal though to have them work properly because once data goes from a
 cmux queue to the outbuf of the connection, libevent will kick in to
 send() the data from the outbuf of a connection. KIST needs to have this
 steps where once it puts the data in the outbuf it then knows it has to
 write to kernel. If it can NOT write to kernel, the data needs to stay in
 the out queue else libevent will write the data from the outbuf to kernel
 without the scheduler knowing about it.

 But because those queues are basically not usable outside their functions,
 everytime we queue a cell, it is put immediately in the outbuf.
 Fortunately, KIST does control a bit of it by doing the flush from the
 cmux to the outbuf (`channel_flush_some_cells()`) and then tries to write
 to kernel what has been flushed. But is seems that tor can put cells in
 the outbuf in other places which is not ideal...

 If we can make the scheduler the *only* one capable of flushing the cmux
 to the out buf, we could get rid of those queues and only use the cmux
 queue. The scheduler does NOT care about the incoming_queue at all.

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

Re: [tor-bugs] #23708 [Applications/Tor Browser]: Menu Bar and Bookmark Toolbar privacy consequences

[Tor Bug Tracker & Wiki]

#23708: Menu Bar and Bookmark Toolbar privacy consequences
--+--
 Reporter:  NavigaTor@…   |  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):

 When you enable the bookmark bar did you choose `New Identity`? Since then
 your screen resolution will be adjusted conveniently.

 Also to solve the problem with fonts just re-install the Tor Browser from
 scratch.

 In any case, if this is exclusively about bookmar/menu bar and screen
 resolution then I'm sure it's a duplicate.

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

Re: [tor-bugs] #23708 [Applications/Tor Browser]: Menu Bar and Bookmark Toolbar privacy consequences

[Tor Bug Tracker & Wiki]

#23708: Menu Bar and Bookmark Toolbar privacy consequences
--+--
 Reporter:  NavigaTor@…   |  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 cypherpunks):

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


Comment:

 It's not recommended as resizing windows and disabled by default.

 The main concern is
 {{{
 System Fonts
 15.29 bits

 38728.55
 unique
 }}}
  (with medium)

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

Re: [tor-bugs] #23687 [Core Tor/Tor]: kist: Channel in waiting_to_write goes missing until a destroy cell

[Tor Bug Tracker & Wiki]

#23687: kist: Channel in waiting_to_write goes missing until a destroy cell
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  not a bug
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 This has been fixed by #23676 afterall. The proposed patch had an issue
 that was triggering this issue.

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

Re: [tor-bugs] #23676 [Core Tor/Tor]: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush a conn that's closed

[Tor Bug Tracker & Wiki]

#23676: kist on 0.3.2.1-alpha-dev beats its head against a wall trying to flush 
a
conn that's closed
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, cpu, tor-sched, 0.3.2.2  |  Actual Points:
  -alpha-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 See branch: `bug23676_032_03`.

 Because we move the channel back to waiting_for_cells, we don't need to
 re-add it to the pending channels so I removed the offending commit that
 introduce `add_chan_to_readd_list()`.

 You'll also notice in the commit message and code that I explicitly state
 that there is probably a deeper problem with this flush_result = 0 and I
 want us to be aware and have a trace on why we did this fix.

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

Re: [tor-bugs] #21694 [- Select a component]: Tor source tarball signed with sha1

[Tor Bug Tracker & Wiki]

#21694: Tor source tarball signed with sha1
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  - Select a component  |Version:  Tor: 0.3.1.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * status:  closed => reopened
 * version:   => Tor: 0.3.1.7
 * resolution:  fixed =>
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.1.x-final


Comment:

 Nothing fixed, tor-0.3.1.7.tar.gz signed with SHA1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23708 [- Select a component]: Menu Bar and Bookmark Toolbar privacy consequences

[Tor Bug Tracker & Wiki]

#23708: Menu Bar and Bookmark Toolbar privacy consequences
--+
 Reporter:  NavigaTor@…   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 With the panoptickick test (https://panopticlick.eff.org/) and:

  * tor-browser: GNU/Linux 32bit, English, 7.0.6
  * Medium or low Security Settings
  * Menu Bar and Bookmark Toolbar enabled

 I get the report that my browser configuration is unique (with medium) or
 nearly unique (with low).

 || Configuration || bits || summary ||
 || medium || 9.9 || ||
 || medium + Bookmarks Bar || 16.2 || ||
 || medium + Menu Bar || 18.37 || ||
 || medium + Menu Bar + Bookmarks Bar || 19.37 || Unique ||

 And with low:
 || Configuration || bits || summary ||
 || low || 9.89 ||  ||
 || low + Bookmarks Bar || 16.05 || nearly unique ||
 || low + Menu Bar || 17.79 || nearly unique ||
 || low + Menu Bar + Bookmarks Bar || 17.79 || nearly unique ||

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-

Comment (by ahf):

 I think both the diagnostic patch and the proposed fix looks good.

 Isis: do you think this should go into 0.3.2.2-alpha? I think this could
 be marked as merge ready.

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

Re: [tor-bugs] #23690 [Core Tor/Tor]: [err] buffers.c:651: buf_flush_to_socket

[Tor Bug Tracker & Wiki]

#23690: [err] buffers.c:651: buf_flush_to_socket
-+-
 Reporter:  Felixix  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-backport 029-backport|  Actual Points:
  030-backport 031-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  0.3.2.2-alpha-must => 028-backport 029-backport 030-backport
 031-backport
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 Merged them in master. Marking `bug23690_028` for possible backport to
 earlier versions if we don't find any breakage.

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * keywords:  tor-client, tor-sched => tor-client, tor-sched, easy


Comment:

 nickm says we should just init `scheduler_last_run` in the scheduler init
 function, and init it to `now`.

 My only protest is that we didn't just run and will have to wait 10ms in
 order to actually do so for the first time, but that probably doesn't
 really matter.

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

Re: [tor-bugs] #23690 [Core Tor/Tor]: [err] buffers.c:651: buf_flush_to_socket

[Tor Bug Tracker & Wiki]

#23690: [err] buffers.c:651: buf_flush_to_socket
+
 Reporter:  Felixix |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  0.3.2.2-alpha-must  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Both patches looks good to me. Would be nice to get these merged to
 master.

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

Re: [tor-bugs] #23690 [Core Tor/Tor]: [err] buffers.c:651: buf_flush_to_socket

[Tor Bug Tracker & Wiki]

#23690: [err] buffers.c:651: buf_flush_to_socket
+
 Reporter:  Felixix |  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  0.3.2.2-alpha-must  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  accepted => 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] #23690 [Core Tor/Tor]: [err] buffers.c:651: buf_flush_to_socket

[Tor Bug Tracker & Wiki]

#23690: [err] buffers.c:651: buf_flush_to_socket
+
 Reporter:  Felixix |  Owner:  nickm
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  0.3.2.2-alpha-must  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


Comment:

 Fix in branch `bug23690_028`.

 Additional prevention in `bug23690_additional_032`.

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

Re: [tor-bugs] #23690 [Core Tor/Tor]: [err] buffers.c:651: buf_flush_to_socket

[Tor Bug Tracker & Wiki]

#23690: [err] buffers.c:651: buf_flush_to_socket
+
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  0.3.2.2-alpha-must  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 Replying to [comment:4 arma]:
 > I suspect #23149.

 I'm not 100% sure there.  Looking at a diff between buffers.c in 0.3.1 and
 0.3.2, I see no changes to flush_chunk() (except changing the name of a
 function that it calls), and no changes to flush_buf() (except renaming
 it).  I've looked for any changes in the call-sites, and I don't see any
 (except the rename as mentioned above).

 Oh, wait! I think I see it!  Single_conn_free_bytes!

 One sec; writing a 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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Two branches in my public git repository:
   * `bug8185_diagnostic_032` logs more information if this bug triggers.
   * `bug8185_025` has a fix, assuming my theory above is right.
   * `bug8185_031` is the fix, merged forward to 0.3.1, with merge conflict
 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] #23664 [Applications/Tor Browser]: Deal with UUID for content sandbox temp folder on Windows and Mac (was: Deal with GUID for content sandbox temp folder on Windows)

[Tor Bug Tracker & Wiki]

#23664: Deal with UUID for content sandbox temp folder on Windows and Mac
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-disk-leak  |  Actual Points:
Parent ID:  #23658   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 We need to redirect `NS_OS_TEMP_DIR` to `\Tor
 Browser\Browser\TorBrowser\Data\Browser\Caches\profile.default` or
 something similar. And it is overridden by
 `NS_APP_CONTENT_PROCESS_TEMP_DIR` https://hg.mozilla.org/mozilla-
 central/rev/5136dcccfe4a#l4.13
 Temp directory suffix can be set via pref https://hg.mozilla.org/mozilla-
 central/rev/5136dcccfe4a#l2.145
 on Mac too https://dxr.mozilla.org/mozilla-
 esr52/source/browser/app/profile/firefox.js#1019

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


Comment:

 Interesting.  It looks like the callstack here is:
   * circuit_package_relay_cell()
   * relay_send_command_from_edge_()
   * relay_send_command_from_edge()
   * connection_edge_package_raw_inbuf()
   * connection_edge_process_inbuf()

 What else do we know?
   * This is an entry connection attached to an origin circuit.
   * As of connection_edge_process_inbuf(), the connection was in state
 AP_CONN_STATE_OPEN or AP_CONN_STATE_CONNECT_WAIT. (or else we wouldn't
 have called package_raw_inbuf())
   * As of connection_edge_package_raw_inbuf(), the connection was not
 marked for close. (Or else the function would have exited.)
   * By the time we reach the bottom of the callstack, the circuit's n_chan
 was NULL, which shouldn't be possible.

 I think what I'd most like to know at this point is the exact status of
 the circuit -- is it completely corrupted, marked for close, or in-
 progress for a build?

 I'm ''guessing'' that this connection was once attached to a working
 circuit (otherwise the earlier attempt to send the BEGIN cell would have
 failed with the same error) and then the circuit became non-working.

 What if the channel becomes closed, and so channel_closed() we call
 circuit_unlink_all_from_channel()?  That will clear the n_chan field of
 the circuit, and mark the circuit.  But the streams attached to the
 circuit won't get marked for close or have their circuits removed until
 circuit_about_to_free() calls connection_edge_destroy().

 I'm going to go with the theory that the circuit is marked, and add
 logging to catch in case it isn't.  Cooking up a patch 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] #23706 [Core Tor/Tor]: Tor's seccomp sandbox does not know about the syscall epoll_pwait

[Tor Bug Tracker & Wiki]

#23706: Tor's seccomp sandbox does not know about the syscall epoll_pwait
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  seccomp, sandbox, musl  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 musl-libc will probably have some more issues to tackle here; 0.3.3 seems
 like a plausible target

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

Re: [tor-bugs] #23704 [Applications/Tor Browser]: Tor Browser seems to remember tabs *at the very moment* of a new available version

[Tor Bug Tracker & Wiki]

#23704: Tor Browser seems to remember tabs *at the very moment* of a new 
available
version
--+---
 Reporter:  gagz  |  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):

 Danger!
 Related or not, but TBB 7.0.5/6 has `places.history.enabled` set to `true`
 by default. And now TBB 7.5a5 has it set to `false` as a non-default value
 for unknown reason!

 @cpunk: "the tabs" means "several tabs".

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

Re: [tor-bugs] #23707 [Applications/Tor Browser]: Enable "Sandbox 1" in the torrc for the Tor Browser for Linux builds

[Tor Bug Tracker & Wiki]

#23707: Enable "Sandbox 1" in the torrc for the Tor Browser for Linux builds
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 One blocker currently,

 {{{
 [warn] Managed proxies are not compatible with Sandbox
 mode.(ClientTransportPlugin line was "fte exec
 ./TorBrowser/Tor/PluggableTransports/fteproxy.bin --managed")
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23707 [Applications/Tor Browser]: Enable "Sandbox 1" in the torrc for the Tor Browser for Linux builds

[Tor Bug Tracker & Wiki]

#23707: Enable "Sandbox 1" in the torrc for the Tor Browser for Linux builds
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 From #23378 "Sandbox 1" seems to no longer be an experimental feature, and
 it may be good (or not?) to see it enabled for the little-t-tor that is
 bundled with alpha Tor Browser Linux builds

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

Re: [tor-bugs] #23704 [Applications/Tor Browser]: Tor Browser seems to remember tabs *at the very moment* of a new available version

[Tor Bug Tracker & Wiki]

#23704: Tor Browser seems to remember tabs *at the very moment* of a new 
available
version
--+---
 Reporter:  gagz  |  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):

 Also do you mean _all_ the previous tabs in some session appeared or is it
 just a single site?

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-client, tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by pastly):

 * keywords:  tor-client => tor-client, tor-sched


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

Re: [tor-bugs] #23706 [Core Tor/Tor]: Tor's seccomp sandbox does not know about the syscall epoll_pwait

[Tor Bug Tracker & Wiki]

#23706: Tor's seccomp sandbox does not know about the syscall epoll_pwait
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  seccomp, sandbox, musl  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by cypherpunks):

 #23449

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pastly):

 Replying to [comment:2 arma]:
 > Question for pastly:
 >
 > A) This is on Windows -- is the kist scheduler supposed to be picked
 here? Is it supposed to be kistlite or something? (I still haven't read
 all the code.)
 >

 I'm guessing KISTLite was used from the beginning. They both use the same
 code, except for ~1 function (not this one).

 If Tor switched during runtime, it should have logged the switch and
 probably a reason why.

 Regardless, I'm betting this is a failure of monotime actually being
 monotonic. Or ... if this was literally right away on startup and if we
 can't assume statically-allocated memory on Windows is initialized to 0,
 then it's possible `scheduler_last_run` was garbage and larger than `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

[tor-bugs] #23706 [Core Tor/Tor]: Tor's seccomp sandbox does not know about the syscall epoll_pwait

[Tor Bug Tracker & Wiki]

#23706: Tor's seccomp sandbox does not know about the syscall epoll_pwait
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:  seccomp, sandbox, musl
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I was playing with the seccomp sandbox with tor 3.2.1-alpha.

 The system in question uses Musl as the standard C library. When adding
 "Sandbox 1" to a minimal torrc (attached at the end), this results in an
 error, saying "(Sandbox) Caught a bad syscall attempt (syscall
 epoll_pwait)".

 The operating system is Gentoo, and the kernel version is 4.9.24-grsec. It
 is reproducible on Alpine Linux (which also uses Musl as standard C
 library), but not on Debian, which suggests this is due to Musl exposing
 an extra system call to Tor that the sandbox does not recognize.

 It's also reproducible on tor-0.3.1.7, which suggests this is not a new
 defect for the 3.2.x series.

 The minimal torrc for which this is reproducible is as follows:

 User tor
 Log debug file /var/log/tor/tor.log
 DataDirectory /var/lib/tor/data
 Sandbox 1

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23705 [Internal Services/Service - trac]: Make asn wiki admin on trac

[Tor Bug Tracker & Wiki]

#23705: Make asn wiki admin on trac
--+--
 Reporter:  hiro  |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Asn will need to make pages "read-only" and requires wiki admin
 privileges. Asn doesn't want to be wiki admin forever and will request
 when he doesn't need this anymore.

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

Re: [tor-bugs] #23705 [Internal Services/Service - trac]: Make asn wiki admin on trac

[Tor Bug Tracker & Wiki]

#23705: Make asn wiki admin on trac
--+
 Reporter:  hiro  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

 * status:  assigned => 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] #23704 [Applications/Tor Browser]: Tor Browser seems to remember tabs *at the very moment* of a new available version

[Tor Bug Tracker & Wiki]

#23704: Tor Browser seems to remember tabs *at the very moment* of a new 
available
version
--+---
 Reporter:  gagz  |  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:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Is that reproducible? If so, could you give us exact steps?
 https://dist.torproject.org/torbrowser/7.0.5/ has older bundles that could
 help with 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] #23688 [Applications/Tor Browser]: Add GitLab CI script

[Tor Bug Tracker & Wiki]

#23688: Add GitLab CI script
--+---
 Reporter:  krichter  |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by krichter):

 Thank for you feedback.

 > the before_script is downloading some deb file and installing them
 without checking their checksum, so we don't really know what we are
 installing.

 I'll fix that if it come to that.

 > where is this gitlab-ci file going to be used? I think doing a full
 rebuild of tor-browser-bundle.git on each commit is going to use a lot of
 resources.

 It can be used in GitLab instance at https://oniongit.eu or you can mirror
 to gitlab.com. Where is the CI script for Tor being used which I linked
 above?

 I followed the [build
 
instructions](https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking).
 A proper CI needs to run all of them on a bare system - reasonable
 compromises are possible of course. After you set up a CI infrastructure
 or bought a plan from a provider, I think resources no longer matter. Note
 that you can connect arbitrary machines as runners to GitLab, so
 trustworthy volunteers might donate CI resources.

 > why is the script first starting a build with LXC, and after doing that
 starting an other one in the vagrant directory?

 Aren't those the two different build systems and how one would use them -
 obviously not, but I never got so far, see e.g.
 https://gitlab.com/krichter/tor-browser-bundle/-/jobs/34423604 for the
 current build?

 > starting with version 7.5a5, we are now using rbm and tor-browser-
 build.git rather than gitian and tor-browser-bundle.git for new
 development.

 Same here, I think I never got the build past the downloading of
 dependencies. Maybe you can fix the checksum error shown in the linked
 GitLab CI log and notify me so that I can proceed with the 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] #23701 [Applications/Tor Browser]: Lower parts of letters get eaten by making line-height uniform

[Tor Bug Tracker & Wiki]

#23701: Lower parts of letters get eaten by making line-height uniform
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-fingerprinting-   |  Actual Points:
  os |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:2 cypherpunks]:
 > Text drifts slightly in the Browser Console. Is this because of this
 feature?

 Could be if you are using 7.5a5. You could test whether disabling
 fingerprinting resistance fixes the issue for you (this feature, as many
 other fingerprinting related ones, is bound to
 `privacy.resistFingerprinting` which we set to `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

[tor-bugs] #23704 [Applications/Tor Browser]: Tor Browser seems to remember tabs *at the very moment* of a new available version

[Tor Bug Tracker & Wiki]

#23704: Tor Browser seems to remember tabs *at the very moment* of a new 
available
version
--+--
 Reporter:  gagz  |  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:|
--+--
 Hi,

 Sorry if this is a duplicate, I tried to give a look but didn't find
 anything.
 And sorry for the weird title, couldn't find anything better...

 I'm not sure exactly what happened, but here is, in order, what I did/saw:
 - open tor browser (under debian stretch)
 - open a few tabs
 - "new identity"
 - open some tabs
 - "new identity"
 - open some tabs
 - close tor browser
 - see a "new version available" window
 - click on something like "yeay, let's upgrade" (maybe the upgrade *was
 done* and only a "restart" was expected)
 - see tor browser starting and opening the tabs I had open some time ago
 (not the last "identity", but the first one)


 Voilà.
 I probably could give more details if needed.

 Oh, also, I cannot say *when* that "Upgrade available" window appeared, I
 only saw it when I closed Tor Browser.

 I think it's a privacy issue (the tabs are stored somewhere or whatever).

 Thanks

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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection 029-backport  |  Actual Points:
  030-backport 031-backport  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Hmm, fix looks reasonable and obvious here.

 Help me understand one thing: Where does the `tor_llround()` happen after
 `compute_weighted_bandwidths()`? I think the cypherpunks at comment:2 is
 implying that it should be done as part of `final_weight =
 weight*this_bw;`?

 I see `tor_llround()` activity in
 `smartlist_choose_node_by_bandwidth_weights()` using
 `scale_array_elements_to_u64()`.

 However, we don't do it in `frac_nodes_with_descriptors()`. There we just
 use the value as a decimal without rounding. Is that OK?

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

Re: [tor-bugs] #23602 [Core Tor/Tor]: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)

[Tor Bug Tracker & Wiki]

#23602: Detect homebrew OpenSSL on OSX (was:Fix compilation on macOS)
-+-
 Reporter:  hellais  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 032-backport, 031  |  Actual Points:
  -backport-maybe, 030-backport-maybe|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hellais):

 Cherry picking da36def955ca749230896c219251ba52181688c0 into master it
 works for me on macOS 10.12.6 and Homebrew 1.3.4 without any additional
 configuration:

 {{{
 ./autogen.sh && ./configure && make
 }}}

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

Re: [tor-bugs] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

[Tor Bug Tracker & Wiki]

#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery,  |  Actual Points:
  needs-proposal, mike-can, prop247, tor-guard   |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Thanks for the patch! This seems important! A few comments:

 - I don't understand how the mods to
 `circuit_timeout_want_to_count_circ()` helps us achieve the goal of this
 ticket. It kinda seems like we are restricting that function even more
 (doc change implies that too), when we actually want it to be more
 accepting. I think a nice comment is required for people like me to
 understand how that function works wrt HS circs.

 - I also don't understand why the
 `circuit_build_times_decide_to_count_circ()` logic was moved from one
 function to another. I think we need some help here to understand, since
 I'm not familiar with the CBT system at all.

 - I think `circuit_get_cpath_len()` should be moded instead of adding
 another func `circuit_get_cpath_opened_len()`. We can add an arg
 `only_count_opened` which does that. I think that'd be cleaner.

 - `circuit_build_times_decide_to_count_circ()` is undocumented and I'd
 actually like to know what it does.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23703 [Webpages]: The Readme.md of Tor Browser Bundle mirror on Github is not correctly updated

[Tor Bug Tracker & Wiki]

#23703: The Readme.md of Tor Browser Bundle mirror on Github is not correctly
updated
-+---
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Webpages |Version:
 Severity:  Normal   |   Keywords:  github mirror
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 The Readme.md of the Tor Browser Bundle mirror on Github at
 https://github.com/TheTorProject/gettorbrowser reports today:

 "In this repository you will find links to download the latest version of
 Tor Browser and Orbot, which currently are 7.0.4 and 15.1.2."

 but it links the 7.0.5 version of TBB and furthermore the current version
 is 7.0.6.

 Probably we need to automate the update process of the Tor Browser Bundle
 mirror on Github.

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

Re: [tor-bugs] #23701 [Applications/Tor Browser]: Lower parts of letters get eaten by making line-height uniform

[Tor Bug Tracker & Wiki]

#23701: Lower parts of letters get eaten by making line-height uniform
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-fingerprinting-   |  Actual Points:
  os |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Text drifts slightly in the Browser Console. Is this because of this
 feature?

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

Re: [tor-bugs] #23697 [Webpages/Website]: List frontdesk, not execdir, on the contact page

[Tor Bug Tracker & Wiki]

#23697: List frontdesk, not execdir, on the contact page
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Here is another option, which folds in donations@ so only the frontdesk
 remains.
 {{{
 diff --git a/about/en/contact.wml b/about/en/contact.wml
 index 132f82d..1104642 100644
 --- a/about/en/contact.wml
 +++ b/about/en/contact.wml
 @@ -91,20 +91,20 @@
  
  Email
  If you have Tor questions, please try to help yourself via the
 -above support venues. Please don't use these contact addresses
 +above support venues. Please don't use this contact address
  for helpdesk or user requests  we all get too much mail and
  we won't be able to help you there.

  
 -  donati...@torproject.org is for questions and comments
 about
 https://donate.torproject.org;>getting money to the
 developers. More
 -  donations means more
 -  Tor. We're happy to help think about creative ways for you
 -  to contribute.
 -  exec...@torproject.org is for questions and comments
 about
 -  Tor the non-profit corporation: trademark questions, affiliation
 -  and coordination, major gifts, contract inquiries, licensing and
 -  certification, etc.
 +  frontd...@rt.torproject.org is for questions and
 +  comments about Tor the non-profit organization: funding and
 +  donations, trademark questions,
 +  affiliation and coordination, major gifts, contract inquiries, etc.
 +  Please note that email is not a great approach for safe
 +  communication, so if you need privacy consider reaching us some
 +  other way. Also note that the frontdesk is currently handled by
 +  volunteers, so please be patient.
 +  
  

  
 }}}

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

Re: [tor-bugs] #23696 [Core Tor/Tor]: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed.

[Tor Bug Tracker & Wiki]

#23696: Bug: scheduler_kist.c:520: kist_scheduler_schedule: Non-fatal assertion
!((diff < 0)) failed.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 After third restart it changed to
 {{{
 Tor NOTICE: Scheduler type KISTLite has been enabled.
 }}}

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

[tor-bugs] #23702 [Applications/Tor Browser]: Fix the sandbox intermediate filename

[Tor Bug Tracker & Wiki]

#23702: Fix the sandbox intermediate filename
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201709
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In `projects/sandbox/config` the filename of the sandbox build ends with
 `.tar.gz` while it is a zip file, which is confusing.

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

Re: [tor-bugs] #23663 [Applications/Tor Browser]: ESR52 codebase is incompatible with anything below Universal C Runtime (CRT) in Windows

[Tor Bug Tracker & Wiki]

#23663: ESR52 codebase is incompatible with anything below Universal C Runtime
(CRT) in Windows
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  invalid
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:8 cypherpunks]:
 > Replying to [comment:7 gk]:
 > > Replying to [comment:6 cypherpunks]:
 > > > Replying to [comment:5 gk]:
 > > > > Replying to [comment:4 cypherpunks]:
 > > > > > Don't you see that Jacek's patch activated compat shims for
 mingw? They were removed later as useless for UCRT (but needed for <=
 `msvcr120.dll`!).
 > > > >
 > > > > Oh, okay. You are just concerned about https://hg.mozilla.org
 /mozilla-central/rev/5680a55b2ec1?
 > > > Of course, no.
 > > > > I thought about cases in the other patches as well as you posted
 them in the description. But as I said they are guarded by `_MSC_VER`
 defines which are not used by mingw-w64 anyway.
 > > > But they should have been adapted to mingw where it's about CRT
 bugs.
 > >
 > > Why? Removing those patches does not change anything with respect to
 mingw-w64. Those code parts did not get used for it before code removal
 either.
 > Because you're using CRT, obviously. Patches for MSVC don't change
 anything, but for CRT do, e.g. https://hg.mozilla.org/mozilla-
 central/rev/398f38361dc2#l10.10

 That one does not affect us either. We don't use jemalloc in mingw-w64
 Windows builds and `MOZ_CRT` is not defined either. Thus, removing this
 part is not mingw-w64 related.

 So, if you have concrete things that are bugs and are affecting us, please
 report them. I think the ticket as-is is invalid.

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-

Comment (by cypherpunks):

 Okay, the stack trace that Nick added may prove useful, here are the ones
 that popped up for me:

 {{{
 [warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
 src/or/relay.c:825 has n_chan==NULL. Dropping. (on Tor 0.3.2.1-alpha )
 [warn] Bug: . Stack trace: (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(log_backtrace+0x42) [0x55a025ae0c72] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(relay_send_command_from_edge_+0x50f)
 [0x55a0259d598f] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_edge_send_command+0x62)
 [0x55a0259d5c72] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_edge_package_raw_inbuf+0x1fa)
 [0x55a0259d5f9a] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_edge_process_inbuf+0xd7)
 [0x55a025a702c7] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x1071e9) [0x55a025a681e9] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x4e1f1) [0x55a0259af1f1] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/.local/share/torbrowser/tbb/x86_64/tor-
 browser_en-
 US/Browser/TorBrowser/Tor/libevent-2.0.so.5(event_base_loop+0x812)
 [0x7ff8cbc66002] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(do_main_loop+0x23d) [0x55a0259b028d] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(tor_main+0x1c15) [0x55a0259b3c05] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(main+0x19) [0x55a0259abab9] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)
 [0x7ff8cadfd3f1] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x4ab09) [0x55a0259abb09] (on Tor
 0.3.2.1-alpha )
 [warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
 src/or/relay.c:825 has n_chan==NULL. Dropping. (on Tor 0.3.2.1-alpha )
 [warn] Bug: . Stack trace: (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(log_backtrace+0x42) [0x55a025ae0c72] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(relay_send_command_from_edge_+0x50f)
 [0x55a0259d598f] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_edge_send_command+0x62)
 [0x55a0259d5c72] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_edge_package_raw_inbuf+0x1fa)
 [0x55a0259d5f9a] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(connection_edge_process_inbuf+0xd7)
 [0x55a025a702c7] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x1071e9) [0x55a025a681e9] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(+0x4e1f1) [0x55a0259af1f1] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/.local/share/torbrowser/tbb/x86_64/tor-
 browser_en-
 US/Browser/TorBrowser/Tor/libevent-2.0.so.5(event_base_loop+0x812)
 [0x7ff8cbc66002] (on Tor 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(do_main_loop+0x23d) [0x55a0259b028d] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(tor_main+0x1c15) [0x55a0259b3c05] (on Tor
 0.3.2.1-alpha )
 [warn] Bug: /home/alfred/tor-browser_en-
 US/Browser/TorBrowser/Tor/tor(main+0x19) [0x55a0259abab9] (on Tor
 

Re: [tor-bugs] #23701 [Applications/Tor Browser]: Lower parts of letters get eaten by making line-height uniform

[Tor Bug Tracker & Wiki]

#23701: Lower parts of letters get eaten by making line-height uniform
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-fingerprinting-   |  Actual Points:
  os |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I wonder whether that would get solved by making sure the patch only
 applies to content and not the chrome parts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23701 [Applications/Tor Browser]: Lower parts of letters get eaten by making line-height uniform

[Tor Bug Tracker & Wiki]

#23701: Lower parts of letters get eaten by making line-height uniform
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-usability, tbb-
 Severity:  Normal   |  fingerprinting-os
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In #23104 we tried to make the line height uniform in order to avoid
 operating system fingerprinting. It seems that affects some systems in a
 way that lower parts of letters in the URL bar are eaten:

 https://blog.torproject.org/tor-browser-75a5-released#comment-271522

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 Replying to [comment:12 pospeselr]:
 > So those repro steps result in successful printing for me
 > * Debian Unstable VM (1 core CPU, 4 gigs of RAM, 8 GB disk)
 > * latest Tor-Browser (version 7.0.5)
 > * browser.tabs.remote.autostart.2 = true
 > * printing various pages (about:config, slashdot, reddit, etc)
 >
 > gk: could you perhaps post Tor Browser's debug log output on a failed
 print?

 There is not shown much, only
 {{{
 (firefox:3965): GLib-GObject-WARNING **:
 ../../../../gobject/gsignal.c:3492: signal name 'load_complete' is invalid
 for instance '0x7f72016908d0' of type 'MaiAtkType139'
 }}}
 but I am not convinced that this indicates what is going on.

 That said, you could check if you can reproduce it with Tails. I am
 wondering, though, what's different on my and Tails' Linux config. I took
 a vanilla Ubuntu 14.04 which I had on a different machine and I had not
 issues.

 intrigeri: do you have any ideas?

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

Re: [tor-bugs] #23648 [Applications/Tor Browser]: I get this error on duckduckgo when using this exit node "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

[Tor Bug Tracker & Wiki]

#23648: I get this error on duckduckgo when using this exit node
"8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:4 cypherpunks]:
 > #23648 is a duplicate.
  This ticket cannot be a duplicate of itself.

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

Re: [tor-bugs] #23700 [Core Tor/Tor]: Tor tells me "Scheduler type KIST has been enabled" multiple times

[Tor Bug Tracker & Wiki]

#23700: Tor tells me "Scheduler type KIST has been enabled" multiple times
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

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


Comment:

 Oops, the fix didn't make it into 0.3.2.1-alpha, sorry!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23700 [Core Tor/Tor]: Tor tells me "Scheduler type KIST has been enabled" multiple times

[Tor Bug Tracker & Wiki]

#23700: Tor tells me "Scheduler type KIST has been enabled" multiple times
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Despite #23552.

 How to reproduce:

 1. Download 7.5a5, and run it with debugging enabled obviously
 2. Use custom obfs4 bridges.
 3. Visit some website.
 4. Change bridge in Torbutton to snowflake.
 5. You should see stuff below

 {{{
 [notice] Scheduler type KIST has been enabled.
 [notice] Scheduler type KIST has been enabled.
 [notice] Scheduler type KIST has been enabled.
 [notice] Scheduler type KIST has been enabled.
 }}}

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

Re: [tor-bugs] #23648 [Applications/Tor Browser]: I get this error on duckduckgo when using this exit node "8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"

[Tor Bug Tracker & Wiki]

#23648: I get this error on duckduckgo when using this exit node
"8175A86D8896CEA37FDC67311F9BDC1DDCBE8136"
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 #23648 is a duplicate.

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

Re: [tor-bugs] #23699 [Applications/Tor Browser]: Tor exit node clashes with duckduckgo connectivity

[Tor Bug Tracker & Wiki]

#23699: Tor exit node clashes with duckduckgo connectivity
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate: #23648

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

Re: [tor-bugs] #22501 [Applications/Tor Browser]: Requests via javascript: violate FPI

[Tor Bug Tracker & Wiki]

#22501: Requests via javascript: violate FPI
-+-
 Reporter:  cypherpunks  |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-linkability, noscript,   |  Actual Points:
  TorBrowserTeam201709R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-linkability, noscript, TorBrowserTeam201709 => tbb-
 linkability, noscript, TorBrowserTeam201709R


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

Re: [tor-bugs] #22501 [Applications/Tor Browser]: Requests via javascript: violate FPI

[Tor Bug Tracker & Wiki]

#22501: Requests via javascript: violate FPI
-+-
 Reporter:  cypherpunks  |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-linkability, noscript,   |  Actual Points:
  TorBrowserTeam201709   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Applied to `master` (commit
 ee2f06091d76272c7b629265d8c0a67c3d3b07e1).

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

Re: [tor-bugs] #23698 [Applications/Tor Browser]: TBB has defualt cache , wouldnt that be risky ?

[Tor Bug Tracker & Wiki]

#23698: TBB has defualt cache , wouldnt that be risky ?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 That's for the background requests your browser made during start-up, like
 version checks. The active disk cache is a bit misleading as we only have
 caching in memory enabled. I think that's okay. That said `about:cache` is
 not that useful anymore and we need to investigate how to fix that, see
 #22451.

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