Re: [tor-bugs] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_information
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Applications/Tor Browser   |Version:
 Severity:  Major  | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:11 gk]:
 > Thanks. Could you test Tor Browser with NoScript and/or HTTPS Everywhere
 being disabled? Maybe having their toolbar buttons injected into the
 toolbar is causing this.
 When I disable the torbutton extension but have HTTPS Everywhere and
 Noscript extensions enabled i get.
 Browser window width: 1000
 Browser window height: 600
 HTTPS Everywhere disabled.
 Browser window width: 1000
 Browser window height: 610
 Noscript disabled
 Browser window width: 1000
 Browser window height: 610
 Both HTTPS Everywhere and Noscript disabled
 Browser window width: 1000
 Browser window height: 610
 When I set the security slider to low I get.
 Browser window width: 1000
 Browser window height: 610
 Tested on TBB 7.0.2

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

Re: [tor-bugs] #22989 [Applications/Tor Browser]: TBB Size 1000x610 Mac

[Tor Bug Tracker & Wiki]

#22989: TBB Size 1000x610 Mac
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_information
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Applications/Tor Browser   |Version:
 Severity:  Major  | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by Dbryrtfbcbhgf):

 * severity:  Normal => Major
 * milestone:   => Tor: 0.3.2.x-final


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

Re: [tor-bugs] #23062 [Applications/Tor Browser]: Tor browser bundle crashed when clicking on a link

[Tor Bug Tracker & Wiki]

#23062: Tor browser bundle crashed when clicking on a link
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:1 gk]:
 > I assume this is not reproducible for you, right?
 >
 > (see #22977 and #22330 as well).
 No I can not reproduce 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] #23119 [Core Tor/Tor]: Make Tors no longer warn if they're running a newer-than-recommended version?

[Tor Bug Tracker & Wiki]

#23119: Make Tors no longer warn if they're running a newer-than-recommended
version?
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Sebastian):

 I don't think we should do this. We need more precise information about
 which versions to actually *unrecommend* and do that quickly, then I'm
 more willing to add new recommended versions quickly. Probably the right
 way is to actually stop recommending anything in the consensus and just
 letting distributions and autoupdaters deal with 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] #23118 [Core Tor/Tor]: release checklist should include "make sure the new version got recommended"

[Tor Bug Tracker & Wiki]

#23118: release checklist should include "make sure the new version got
recommended"
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Sebastian):

 I've been waiting for the network team to get me some details about which
 versions they think should be recommended, and not updating anything in
 the meantime.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23121 [Applications/Torbutton]: Allow adding "New tor circuit" icon to the toolbar

[Tor Bug Tracker & Wiki]

#23121: Allow adding "New tor circuit" icon to the toolbar
+---
 Reporter:  torbacchi   |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  |   Keywords:  toolbar torbutton
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 Feature request: allow the user to customize the firefox toolbar adding an
 icon to execute the "New tor circuit for this site" command, instead of
 having to click on the torbutton icon and select the command from the menu
 (or press Shift-Ctrl-L).

 (Of course the same could be done also with the "New identity" command)

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

Re: [tor-bugs] #23120 [Internal Services/Service - trac]: Make it harder to brute-force Trac user passwords

[Tor Bug Tracker & Wiki]

#23120: Make it harder to brute-force Trac user passwords
--+
 Reporter:  gk|  Owner:  qbi
 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 qbi):

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


Comment:

 The `trac.ini` has now the following settings:

 {{{
 login_attempt_max_count = 17
 user_lock_max_time = 10
 }}}
 This means that after 17 failed attempts the account will be locked. A
 normal user who wants to log in through the website would not take those
 many attempts. So the assumption is that it is a automatic approach.

 The second line means that the account will be locked for 10 seconds. This
 is just a workaround. According to the [https://trac-
 hacks.org/wiki/CookBook/AccountManagerPluginConfiguration CookBook] it
 should be `0`. However  when it is set trac throws an error. Due to the
 fact that every user visits this site at the same time the 10 seconds also
 results in a indefinite time.

 If a user's login was locked the user can contact the trac admin to unlock
 the account. So it can use the `cypherpunks` account to create a ticket or
 contact us in other ways.

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

Re: [tor-bugs] #22827 [Core Tor/Tor]: Formalise CollecTor spec for sanitised bridge descriptors and put in torspec

[Tor Bug Tracker & Wiki]

#22827: Formalise CollecTor spec for sanitised bridge descriptors and put in
torspec
-+-
 Reporter:  isis |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  tor-spec, tor-docs, tor-bridges  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 And now it's [https://metrics.torproject.org/bridge-descriptors.html
 deployed]! Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23120 [Internal Services/Service - trac]: Make it harder to brute-force Trac user passwords

[Tor Bug Tracker & Wiki]

#23120: Make it harder to brute-force Trac user passwords
--+-
 Reporter:  gk|  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Currently we don't have any measures in place to stop brute-forcing
 passwords of Trac accounts. I know, we are all using secure passwords, but
 still we could do better here and set up an upper limit password retries.

 That got reported via HackerOne by S.M.Usman (muhammad_usman)

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

Re: [tor-bugs] #23119 [Core Tor/Tor]: Make Tors no longer warn if they're running a newer-than-recommended version?

[Tor Bug Tracker & Wiki]

#23119: Make Tors no longer warn if they're running a newer-than-recommended
version?
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 We would want to update Atlas, and other tools, so they don't write a
 scary "not recommended" next to relays that are running newer-than-
 recommended versions. But we probably want to make that change to atlas
 anyway.

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

Re: [tor-bugs] #23118 [Core Tor/Tor]: release checklist should include "make sure the new version got recommended"

[Tor Bug Tracker & Wiki]

#23118: release checklist should include "make sure the new version got
recommended"
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 This bug was reported on irc several times, and also by Ralph on tor-
 relays:
 https://lists.torproject.org/pipermail/tor-relays/2017-August/012715.html

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

Re: [tor-bugs] #23119 [Core Tor/Tor]: Make Tors no longer warn if they're running a newer-than-recommended version?

[Tor Bug Tracker & Wiki]

#23119: Make Tors no longer warn if they're running a newer-than-recommended
version?
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * cc: weasel, sebastian (added)


Comment:

 I am cc'ing weasel and sebastian so they can say "yes, this would help
 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] #23118 [Core Tor/Tor]: release checklist should include "make sure the new version got recommended"

[Tor Bug Tracker & Wiki]

#23118: release checklist should include "make sure the new version got
recommended"
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 I opened #23119 for what I hope is a more thorough solution.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23119 [Core Tor/Tor]: Make Tors no longer warn if they're running a newer-than-recommended version?

[Tor Bug Tracker & Wiki]

#23119: Make Tors no longer warn if they're running a newer-than-recommended
version?
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Right now, we need to get three dir auths to add lines to their torrc
 files before we can put out a new release. Sometimes, we screw that up
 (#23118). The rest of the time, it's still a hassle.

 One option is just to drop the recommendedversions thing entirely. I heard
 Sebastian and weasel discussing doing that.

 An intermediate option would be to have Tors stop warning when they're
 running a newer version in a series. That is, we mostly focus on having
 the recommendedversions thing warn you when you're too old, and we stop
 minding when we're too new.

 That way the dir auths only need to mess with their recommendedversions
 config when they're *un*recommending a version, which is an active
 decision that it's reasonable for directory authority operators to take.
 They never need to mess with them when some newer thing comes out (which
 should not need to involve a dir auth operator).

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

Re: [tor-bugs] #23118 [Core Tor/Tor]: release checklist should include "make sure the new version got recommended"

[Tor Bug Tracker & Wiki]

#23118: release checklist should include "make sure the new version got
recommended"
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by arma):

 Btw, I think Sina might not be doing recommendedversions anymore.
 According to
 https://consensus-health.torproject.org/#recommendedversions
 it is just weasel/arma/sebastian.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23118 [Core Tor/Tor]: release checklist should include "make sure the new version got recommended"

[Tor Bug Tracker & Wiki]

#23118: release checklist should include "make sure the new version got
recommended"
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 In doc/HACKING/ReleasingTor.md we have
 {{{
 1. Get at least three of weasel/arma/Sebastian/Sina to put the new
version number in their approved versions list.
 }}}

 But there's no follow-up step later in the checklist, to make sure that it
 really happened.

 For Tor 0.3.0.10, it didn't happen -- moria1 recommended the new version,
 but nobody else did. So in retrospect, it would have been wise to do some
 sort of follow-up to check that the new version actually got recommended,
 before releasing.

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

Re: [tor-bugs] #23096 [Internal Services/Blog]: Request to investigate solution for permanent link of newsletter letters + archive

[Tor Bug Tracker & Wiki]

#23096: Request to investigate solution for permanent link of newsletter 
letters +
archive
+--
 Reporter:  isabela |  Owner:  hiro
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Blog  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by hiro):

 Hi,

 I am going to investigate this more monday, but something that popped into
 my head today is that the EFF uses civicrm to send newsletter. We have a
 civi instance running somewhere right? Maybe if I could get access to it I
 could investigate that too.

 More soon.

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

Re: [tor-bugs] #9924 [Applications/Tor Browser]: Firefox bug - TBB queries the A record of the hostname of the machine it is running on.

[Tor Bug Tracker & Wiki]

#9924: Firefox bug - TBB queries the A record of the hostname of the machine it 
is
running on.
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-firefox-patch,tbb-proxy-bypass  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Replying to [comment:5 gk]:
 > cypherpunks: Is that still an issue? If so, do you have logs (pcaps) for
 that? A couple of days ago I checked Tor Browser start-up on a Windows
 machine and no DNS resolution outside of Tor showed up
 It was done by DNS Client service, and Tor Browser got it through IPC from
 the DNS Client cache.

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

Re: [tor-bugs] #17412 [Applications/Tor Browser]: High-precision timestamps in JS

[Tor Bug Tracker & Wiki]

#17412: High-precision timestamps in JS
-+--
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-time-highres  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 > shared  memory  counter (SMC),   relies   on   an   experimental
 feature that   allows   for   sharing   of   memory   between JavaScript’s
 web   workers.   SMC   builds   a   high-resolution counter  that  can  be
 used  to  reliably  implement  AnC  in  all the  browsers  that  implement
 it.
 http://www.cs.vu.nl/~giuffrida/papers/anc-ndss-2017.pdf

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

Re: [tor-bugs] #23117 [Applications/Tor Browser]: Link Tor Browser Bundle statically against musl libc

[Tor Bug Tracker & Wiki]

#23117: Link Tor Browser Bundle statically against musl libc
--+--
 Reporter:  robotanarchy  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  musl,libc,tbb |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 https://lists.torproject.org/pipermail/tor-dev/2016-October/011604.html

 My view remains unchanged, not sure about the browser developers.

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

[tor-bugs] #23117 [Applications/Tor Browser]: Link Tor Browser Bundle statically against musl libc

[Tor Bug Tracker & Wiki]

#23117: Link Tor Browser Bundle statically against musl libc
--+---
 Reporter:  robotanarchy  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  musl,libc,tbb
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Right now it isn't possible to run the pre-compiled tor browser bundle on
 musl libc based Linux distributions.

 I have found a mail thread from musl users/developers discussing this
 subject, in which Rich Felker came up with the following proposal (to
 always statically compile against musl):
 > > One thing to note: the whole point of Tor Browser Bundle is to avoid
 > > all sorts of side-channel/information-leak risks associated with just
 > > using a normal web browser build on Tor. If anything showing that your
 > > Tor Browser Bundle is built against musl rather than glibc leaks out
 > > to the network, this would compromise much of the benefit of the
 > > package -- there are relatively few musl desktop users, and even fewer
 > > who use Tor Browser, so it becomes much easier to identify you. Of
 > > course it would be ideal if they _always_ used musl, and fully
 > > static-linked, so that there wouldn't even be any risk of glibc
 > > version information (from the system-wide glibc) leaking over the
 > > network.

 However, the thread ends with the following words, so I guess this never
 reached the tor developers:
 > I just tried to but my message was apparently rejected (not just held
 > for moderation) for not being a subscriber.

 Source:
 http://openwall.com/lists/musl/2016/04/26/1


 So what is your point of view on this subject?
 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] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by Vort):

 This bug can be reproduced with two virtual machines:
 1. Windows 7, Tor 0.3.1.5-alpha relay.
 2. Ubuntu 16.04, chutney "basic" network.

 It takes about 10 minutes until cache fills up with 256 entries and
 assertions start appearing in log file.

 But there is one problem with this test:
 In about a minute, Windows 7-based relay start to use 100% of CPU
 resources.
 (Looks like this overload is made by a lot of `tor_cond_wait()` calls)
 So it needs to be limited for one core usage, or your system will be
 lagging.

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by Vort):

 Looks like this happens when file count for diff-cache reaches 256 (but
 I'm not sure).

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by Vort):

 Still in 0.3.1.5-alpha:
 {{{
 Aug 05 08:24:12.000 [warn] Unable to unlink "d:\\Tor\\Data\\diff-
 cache/1085" while removing file: Permission denied
 Aug 05 09:22:13.000 [warn] Unable to unlink "d:\\Tor\\Data\\diff-
 cache/1005" while removing file: Permission denied
 Aug 05 09:22:13.000 [warn] tor_bug_occurred_(): Bug: consdiffmgr.c:1300:
 store_multiple: Non-fatal assertion !(ent == NULL) failed. (on Tor
 0.3.1.5-alpha )
 Aug 05 09:22:13.000 [warn] Bug: Non-fatal assertion !(ent == NULL) failed
 in store_multiple at consdiffmgr.c:1300. (Stack trace not available) (on
 Tor 0.3.1.5-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] #23113 [Core Tor/Tor]: Manage DNS state better when "All nameservers have failed"

[Tor Bug Tracker & Wiki]

#23113: Manage DNS state better when "All nameservers have failed"
---+
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.6.10
 Severity:  Normal | Resolution:
 Keywords:  dns, security-low  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+

Comment (by hdqdak8v32aor):

 Instead of burying the message, how about fixing the underlying cause,
 which is `eventdns` blindly forwarding malformed DNS queries guaranteed to
 evoke `Bad response 5 (refused)`?

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