Re: [tor-bugs] #23362 [Applications/Tor Browser]: consider performing network operations in a dedicated process for ESR59

[Tor Bug Tracker & Wiki]

#23362: consider performing network operations in a dedicated process for ESR59
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff59-esr, tbb-security|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 I haven't heard anything about that bug, so I suspect it is a future
 wishlist item but not actively being planned out.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24323 [- Select a component]: get bridges

[Tor Bug Tracker & Wiki]

#24323: get bridges
--+
 Reporter:  123456|  Owner:  bridges@…
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  bridgedb-reportbug
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #24323 [- Select a component]: get bridges

[Tor Bug Tracker & Wiki]

#24323: get bridges
--+---
 Reporter:  123456|  Owner:  bridges@…
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  bridgedb-reportbug|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

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


Comment:

 You can get bridges by:
 * Going to https://bridges.torproject.org/
 * Or emailing brid...@torproject.org from a RiseUp, Gmail, or Yahoo
 account

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

Re: [tor-bugs] #24322 [Core Tor/Tor]: make IPv6-only clients bootstrap without needing config changes.

[Tor Bug Tracker & Wiki]

#24322: make IPv6-only clients bootstrap without needing config changes.
--+---
 Reporter:  dkg   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  IPv6  |  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * status:  new => closed
 * version:  Tor: 0.3.1.8 =>
 * resolution:   => duplicate
 * parent:   => #17835


Comment:

 Hi dkg,

 This is a duplicate of #17835 and #17217. (There are a lot of tickets
 about IPv6 support in Tor.)

 You can see the relevant section of the IPv6 roadmap here:

 
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ClientConnectiontoEntryNodes

 The next task I am working on is #20916, because consensus changes take a
 while to deploy to all the authorities. I suspect we might also need to
 improve IPv6 support on relays before we can make clients use IPv6 by
 default, as only 20% of relays have IPv6 ORPorts.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24322 [Core Tor/Tor]: make IPv6-only clients bootstrap without needing config changes.

[Tor Bug Tracker & Wiki]

#24322: make IPv6-only clients bootstrap without needing config changes.
--+--
 Reporter:  dkg   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.8
 Severity:  Normal|   Keywords:  IPv6
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 #17281 suggests that an IPv6-only client should be able to bootstrap by
 setting some flags in torrc.  I've done:

 {{{
 ClientUseIPv4 0
 ClientUseIPv6 1
 }}}

 But, most clients are not *always* IPv4-only or IPv6-only.  In particular,
 i tend to move my laptop between networks that have different properties
 (i'm writing this from a v6-only network).

 I shouldn't have to fiddle with my torrc to make tor work.  it should be
 able to auto-detect this situation and do the right thing automatically.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://addons.mozilla.org/en-US/firefox/addon/privacy-pass/

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

Re: [tor-bugs] #23323 [Core Tor/Tor]: sample_laplace_distribution should produce a valid result on 0.0

[Tor Bug Tracker & Wiki]

#23323: sample_laplace_distribution should produce a valid result on 0.0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  security-low, tor-relay, |  Actual Points:
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 026-backport-maybe|
Parent ID:  #23061   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by teor):

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


Comment:

 We're still working out the best way to do this in the PrivCount in Tor
 spec. Let's revisit this issue when that's been reviewed on tor-dev@.

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

Re: [tor-bugs] #23414 [Core Tor/Tor]: rep_hist_format_hs_stats() should add noise, then round

[Tor Bug Tracker & Wiki]

#23414: rep_hist_format_hs_stats() should add noise, then round
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  1.0
  031-backport, 030-backport, 029-backport,  |
  028-backport   |
Parent ID:  #23061   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by teor):

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


Comment:

 We're still working out the best way to do this in the PrivCount in Tor
 spec. Let's revisit this issue when that's been reviewed on tor-dev@.

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

Re: [tor-bugs] #24023 [Core Tor/Tor]: Is proto required for alternate relay implementations?

[Tor Bug Tracker & Wiki]

#24023: Is proto required for alternate relay implementations?
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy doc tor-spec  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * owner:  teor => (none)
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 We don't have to do this in 0.3.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

[tor-bugs] #24320 [Community/Tor Browser Manual]: Add an instruction to how to translate tbb-manual in your language

[Tor Bug Tracker & Wiki]

#24320: Add an instruction to how to translate tbb-manual in your language
--+---
 Reporter:  cypherpunks   |  Owner:  phoul
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Add an instruction to how to translate tbb-manual in your language and how
 to submit 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] #23968 [Applications/Tor Browser]: NoScript icon jumps to the right after update

[Tor Bug Tracker & Wiki]

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

 * status:  closed => reopened
 * cc: catalyst (added)
 * resolution:  fixed =>


Comment:

 I just upgraded from 7.5a7 to 7.5a8 on Linux and the NoScript button
 jumped to the right after the automatic post-update restart.

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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201711R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Wow, this is janky.  Definitely agree with cypherpunks that eventually
 firefox should probably handle file-dialogs internally the same way
 everywhere.  Otherwise we're just waiting for GTK/KDE/MacOS/Windows devs
 to break us.

 === Code Fixes:

 ::GetDlgItemText truncates the requested string based on the nMaxCount
 provided.  Given that scheme part of the URI (http, https, ftp, etc) is
 going to be short, does it make sense to have a smaller buffer?

 messageBuffer ought to just be an HLOCAL (which is just a typedef'd HANDLE
 which itself is a typede'd void*) rather than LPTSTR.  The memory
 allocated by ::FormatMessageW is done so using ::LocalAlloc.  You also
 need to add a ::LocalFree(messageBuffer) call after we're finished with
 messageBuffer.

 === Approach in General:

 Checking the URI string for ':^^/^^/' is not sufficient.  Playing around
 in a Win10 VM, you can access SMB shares via strings like:

 * {{{ \\Hostname\Path\To\File.txt }}}
 * {{{ \\192.168.50.123\Path\To\File.txt }}}

 However, this is sort of irrelevant because (on Win10 at least) the file
 explorer does DNS and LLMNR (for local shares) queries AS YOU TYPE for
 SMB.  So for instance, if you have an SMB share of the form
 {{{\\other\shared}}} as soon as you type that '\' before shared an LLMNR
 request is sent out.  Same story if you query {{{\\.cnn.com\shared}}}
 a DNS request gets sent out.  The requests will also be triggered on
 paste.

 This auto-lookup does not occur with https/http/ftp URIs, only windows SMB
 strings starting with ^^\^^\ .

 After a fair amount of digging today it doesn't look like there's an easy
 way to fix this.  I'd hoped a fix would be as easy as detouring the
 relevant DNS API, but the DNS request doesn't appear to be coming from the
 process which opens the file dialog.  The URL string does get passed
 through RPC APIs several times (which makes me think some service is doing
 the request).

 We might be able to detour whichever root offending function is causing
 the DNS request to happen but that will require more investigation, and
 would be inherently fragile and would need to be tested on every Windows
 SKU.

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

Re: [tor-bugs] #24319 [Applications/Tor Browser]: change text - "Change details that distinguish you from other Tor Browser users"

[Tor Bug Tracker & Wiki]

#24319: change text - "Change details that distinguish you from other Tor 
Browser
users"
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 And when the user untick the checkbox:
 [X] Prevent any changes that distinguish you from other Tor Browser users

 Show dialog box(something like JS' confirm())

 "Do you really want to do this? Tor can't help you if you use it wrong!
 [YES] [NO]"

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

Re: [tor-bugs] #24319 [Applications/Tor Browser]: change text - "Change details that distinguish you from other Tor Browser users"

[Tor Bug Tracker & Wiki]

#24319: change text - "Change details that distinguish you from other Tor 
Browser
users"
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 [X] Prevent any changes that distinguish you from other Tor Browser users
 if enabled, TBB will stick to DEFAULT_FINGERPRINT. TBB users unite!


 [X] Let me change something that distinguish you from other Tor Browser
 if enabled, user is taking off one's vendetta mask in public. Yikes!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24319 [Applications/Tor Browser]: change text - "Change details that distinguish you from other Tor Browser users"

[Tor Bug Tracker & Wiki]

#24319: change text - "Change details that distinguish you from other Tor 
Browser
users"
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 [X] Change details that distinguish you from other Tor Browser users

 It's checked by default. Isn't this safe?

 "Enabled change details" = "Change details is okay"
 what details? = distinguish you from other Tor Browser users
 Enabled = you are different than others = identifiable = danger

 Why not say:
 [X] Prevent any changes that distinguish you from other Tor Browser users

 OR

 [X] Let me change something that distinguish you from other Tor Browser

 Now, which is correct?

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

Re: [tor-bugs] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

#23101: Predict and build specific HS purpose circuits (rather than GENERAL)
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #13837   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Replying to [comment:6 asn]:
 > Replying to [comment:5 mikeperry]:
 > > Asn - you are right to worry about trying to alter how we deal with
 existing purposes, especially in a way that changes the HS state machine.
 However, adding a whole new circuit purpose is quite easy. I have done it
 several times before (including in my draft patch for parent ticket
 #13837). I know how to do it without issue. Aside from a couple asserts
 and checks here and there, new purposes get ignored by existing code.
 That's what circuit purposes are for.
 > >
 > > How about this: instead of messing with the existing HS purpose state
 machine(s), we create a new purpose (say CIRCUIT_PURPOSE_HS_GENERAL), and
 then in circuit_predict_and_launch_new() we launch new circuits of that
 type when we predict we need any hidden service circuits. Then we should
 be able to make just a few changes to circuit_get_open_circ_or_launch(),
 circuit_launch_by_extend_info(), and circuit_find_to_cannibalize() to use
 this new circuit type for hidden service circuits (instead of using
 CIRCUIT_PURPOSE_C_GENERAL for them).
 > >
 > > That way circuits with this new purpose will otherwise be ignored
 unless we are looking to build a new one. And that mechanism for reusing
 them will be very similar as it is today, just drawing from
 CIRCUIT_PURPOSE_HS_GENERAL instead of CIRCUIT_PURPOSE_C_GENERAL, and we
 also don't have to change our current rephist prediction code.
 > >
 > > Sound like a plan?
 >
 > Plausible plan. I'm still a bit concerned but I don't have a better plan
 tbh.
 >
 > What would be the interaction between `CIRCUIT_PURPOSE_C_GENERAL` and
 `CIRCUIT_PURPOSE_HS_GENERAL`? e.g. would you be able to cannibalize a
 `C_GENERAL` circuit to an `HS_GENERAL` circuit if we find that we have
 idle general circuits and we need HS ones (or the opposite)?

 The desired behavior is that this should not be allowed. The idea is that
 these two types of general circuits will have different path construction
 mechanisms for the first three hops (vanguards/pinned middles vs normal),
 and should not be mixed.

 In terms of how this will be done - I am going to alter
 circuit_find_to_cannibalize() so that you must also specify a circuit type
 to cannibalize from in addition to the one you want to create, and you
 can't switch between these classes of circuits (in the case where there is
 nothing to cannibalize in this way, that function can find nothing and
 return NULL, and the calling code in circuit_launch_by_extend_info() will
 build a fresh circuit instead). Since circuit_find_to_cannibalize()
 already behaves as if you specified canibalize_from ==
 CIRCUIT_PURPOSE_C_GENERAL, I don't anticipate that the change to draw from
 CIRCUIT_PURPOSE_HS_GENERAL will be very complicated.

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

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
-+-
 Reporter:  kernelcorn   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability tbb-security, tbb- |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 "If that's not the case then there should be some bug report."

 There are many ways to identify its users. I'm against adding uBO to TBB.
 This will make unique fingerprint if the user choose filterlist their own
 and download them from the 3rd party server.

 Instead, bundle the "lite" blocklist to TBB itself. Lite-list will block
 some ads so 99.% user will not disable it. By bundle it to TBB, it
 will NEVER make a connection to the outside. Fingerprints will be the same
 because everyone use same list.

 like; https://github.com/mozilla-mobile/focus-android/issues/1127

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 uBlock Origin was never included in Tor Browser by default. By using
 Tails' TBB, you agree to be identified differently than us who use
 official Tor Browser. Uninstall that default and always support OFFICIAL
 TBB.

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * priority:  High => Very Low


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

Re: [tor-bugs] #24317 [Core Tor/Tor]: Do not use same country in the Tor circuits (was: Tor circuits in the same country)

[Tor Bug Tracker & Wiki]

#24317: Do not use same country in the Tor circuits
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * type:  defect => task


Comment:

 [US]-[US]-[US]
 [US]-[US]-[UK]
 [US]-[UK]-[US]

 Tor SHOULD not use same country. Please fix this already.

 1. Read ExcludeNodes if exist.
 2. Build "country array".
 3. While connect to 1st, pick 1 country and delete it from country array.
 4. While connect to 2nd, instruct the 1st node to use 2nd, pick 1 country
 and delete it from country array.
 5. same as 4

 result:
 [UK]-[CN]-[RU]

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

Re: [tor-bugs] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+

Comment (by mikeperry):

 Ugh, the other wrinkle to check is if the hidden service comes back online
 after the socks timeout, but while that old intro circuit is still laying
 around. Does Tor try to reuse the intro in that case? Does that work, or
 does it break?

 Sorry this is so annoying to verify.

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

Re: [tor-bugs] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+

Comment (by mikeperry):

 The socks timeout is not going to close the circuit. Did it eventually
 close? If you have a test case, you can lower that idle timeout by setting
 CircuitsAvailableTimeout to like 3 (3 minutes - long enough for the socks
 timeout).

 If the circuit does close, then this is merge ready IMO.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25|
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 As I said on IRC, for further background: The reason why these tickets are
 functionally together (and touch the same block of code) is that both
 changes are needed for the rate of circuit timeouts for hidden service
 circuits (and regular circuits) to be at the target 20%. If we only merge
 this ticket, the resulting tor still will timeout circuits at some other
 rate. This is why in my mind they are a package deal. Tor won't exhibit
 the designed behavior without both fixes together.

 I filed the tickets separately as I began noticing problems while writing
 the prop247 simulator. In retrospect, I should have filed a single ticket:
 "Tor does not time out circuits at the target 20% rate".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25|
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 Ok, I separated bug #23100 without the tests. mikeperry/bug23100-squashed
 is just that (and is the same commit hash for #23100 from bugs23100+23114
 -cleanup-squashed2). mikeperry/bug23100-presquashed-fixups contains just
 the fixups in that commit.

 I think I also see where you got confused with the rebase. I accidentally
 labeled the refactoring commits as fixups to #23100, since you asked for
 them in that review. I simply removed those commits from
 mikeperry/bug23100-presquashed-fixups now. They will be part of #23114.

 I will annotate the gitlab review with the fixup commit hashes for your
 comments.

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

Re: [tor-bugs] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Authorities do not use guards for anything.

 And chutney uses TestingTorNetwork, which turns off the IPv4 /16
 restriction, which normally stops us choosing a guard and middle that are
 the same relay. When it is turned off, we still need to avoid choosing
 exactly the same relay for two hops in the same circuit.

 I'm not sure why this is happening on the live network and the test
 network. Because the /16 restriction should prevent any node from choosing
 the same relay twice in a path.

 Does the /16 restriction work when we're using an IPv6 address to extend
 to the guard?

 I think we should add an unconditional same-id restriction, and bug-log
 (and log the ip addresses and fingerprints in the path) when it's
 triggered when the /16 restriction is on. And we should check if IPv6
 guards trigger it. And if anything else triggers 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] #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:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25|
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 asn - I am trying to honor your many requests for things that were either
 already done, redundant to other code, and/or difficult to deal with wrt
 git history.

 Since these two tickets touch the very same block of code, I see them as a
 unit. Maybe I should have simply filed only one ticket... Separating them
 is very time consuming, especially wrt tests (which did not exist for any
 of this code before, so I ended up having to write tests that covered a
 lot of timeout functionality - which was also changing in *both* of these
 tickets). If you want me to separate the tests, and refactor separately,
 and do the copy-code-first thing (even though in my eyes, that is what
 #213100 mostly was, aside from one extra conditional and a relocation),
 that will take me another *two days* of git juggling, test re-writing, and
 verification, at least.

 I spent all day yesterday trying to merge the fixups for #23100 down
 without conflicts for #23114. Other than the refactoring you asked for, in
 fact all of those fixups are cleanly merged into #23100. I even provided
 you two versions of the branch (pre-fixup and post-fixup) to verify this.

 Wrt refactoring: because you requested that the initial commit just be a
 move of code with minimal changes, I merged the refactoring that you asked
 for into the following ticket, #23114. I think the refactoring was a good
 idea. But to avoid making you review a completely different #23100, I did
 it in #23114 instead... It is frustrating to me that you are now upset by
 this effort.

 I think we are both underestimating what we're asking of the other, and
 communicating poorly on top of it. :/

 I can make a separate commit for this, but I think it is way too much for
 you to also ask for me to separate the tests for this and #23114 just for
 git history. And I'm not sure if you are even asking for this. That is
 still not clear.

 If you want to merge this without tests, that's fine. I will make a branch
 for the #23100 commit in a second, and I will also make a reference branch
 with only the fixups it contains. But if you want tests with this code,
 again, I would rather simply wait for someone to review #23114. As I said,
 the tests cover a lot of timeout functionality that is being changed by
 these tickets. Writing tests for each ticket means changing the tests
 after each ticket, which is a lot of busy work for no gain in the end.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24318 [Core Tor/Tor]: Clarify that the RelayBandwidth* options exclude directory fetches by relays

[Tor Bug Tracker & Wiki]

#24318: Clarify that the RelayBandwidth* options exclude directory fetches by
relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy doc
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Twice in the last few months, I have explained to relay operators that
 RelayBandwidthRate/Burst includes directory fetches from the relay by
 clients. But they do not include directory fetches by the relay (from
 authorities or other relays), because that is considered "client"
 activity.

 We should clarify in the man page, because it clearly causes some
 confusion.

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Exits are the only nodes that log these warnings, because they're a
 single-hop exit warning.

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Ah, C header dependencies. Not fun.

 That probably means that this new function:
 * should be in address.c, and
 * should call tor_getsockname(), rather than replacing it.

 How about tor_addr_from_getsockname()?
 That's a much better name anyway, because it describes exactly what the
 function 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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 https://labs.riseup.net/code/issues/14968

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

Re: [tor-bugs] #24287 [Metrics/Consensus Health]: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health summary

[Tor Bug Tracker & Wiki]

#24287: Add a "votes for IPv6 ORPorts" flag to authorities in consensus health
summary
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Oh, and do you have access to relay descriptors in consensus-health?
 If you do, a feature like OnionOO's #21637 (which will show unreachable
 addresses on RelaySearch/Atlas) would be great:

 If a relay declares an IPv6 address in its descriptor (in an "a" line),
 but an authority doesn't vote for it, that relay should get the
 UnreachableIPv6 pseudo-flag from that authority.

 If an authority's vote contains any "a" lines with IPv6 addresses, the
 authority should be marked as knowing the "ReachableIPv6" and
 "UnreachableIPv6" pseudo-flags.

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 > You're probably using Tails.

 Ah, okay! Are there any Tails people hanging around over here available
 helping clarify 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] #21637 [Metrics/Onionoo]: Include both declared and reachable IPv6 OR addresses

[Tor Bug Tracker & Wiki]

#21637: Include both declared and reachable IPv6 OR addresses
+---
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo |Version:
 Severity:  Normal  | Resolution:
 Keywords:  metrics-2017, ipv6  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+---
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-21637
 the last commit in my updated task-21637 branch] which contains a new test
 class with unit tests for this new field.

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pastly):

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


Comment:

 Replying to [comment:2 cypherpunks]:
 > Wait, what?! Why do I see uBlock Origin on the extensions list of TBB's
 add-on manager?

 You're probably using Tails. The Tails developers added uBlock Origin to
 the Tor Browser that they ship.

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

Re: [tor-bugs] #24254 [Core Tor/Tor]: There needs to be documentation on what kernel versions the KIST Scheduler will run on

[Tor Bug Tracker & Wiki]

#24254: There needs to be documentation on what kernel versions the KIST 
Scheduler
will run on
+
 Reporter:  Dbryrtfbcbhgf   |  Owner:  pastly
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-sched, tor-doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+
Changes (by pastly):

 * status:  accepted => needs_review


Comment:

 Ok ready for review again.

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

Re: [tor-bugs] #24204 [Core Tor/Tor]: Improve the in-process Tor API: create owning control port

[Tor Bug Tracker & Wiki]

#24204: Improve the in-process Tor API: create owning control port
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-mobile, s8-api  |  Actual Points:
Parent ID:  #23684  | Points:
 Reviewer:  |Sponsor:  Sponsor8-can
+
Changes (by mtigas):

 * cc: mike@… (removed)
 * cc: mtigas (added)


Comment:

 Don't have too much to comment on here, but just reporting back so folks
 know I saw it.

 Since AFAIK all of the mobile implementations (including the in-process
 iOS "tor as thread" way of doing things) happily use a TCP or unix socket
 control port, this is a much lower priority for me (nice to have someday)
 than #24107 / #23847 (which fixes a platform-specific stability 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] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 uBlock Origin was never included in Tor Browser by default. It's possible
 that you installed yourself the extension. Although I don't know why it
 stopped 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] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+
Changes (by pastly):

 * status:  accepted => needs_review


Comment:

 Removed the man page changes. Squashed and rebased on master again.
 `ticket24158_02`

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

Re: [tor-bugs] #23362 [Applications/Tor Browser]: consider performing network operations in a dedicated process for ESR59

[Tor Bug Tracker & Wiki]

#23362: consider performing network operations in a dedicated process for ESR59
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff59-esr, tbb-security|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 It would be very useful if this networking process executed a file
 separate from torbrowser or plugin-processes, since then it could be given
 a separate domain/subject in MAC policy. The same goes for any process
 with different required privileges.

 I know nothing about Mozilla's planned design other than this ticket and
 the referenced bug. Perhaps someone with Mozilla's ear could make a case
 for this?

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Wait, what?! Why do I see uBlock Origin on the extensions list of TBB's
 add-on manager? It has been there since a while (it's an official TBB, no
 crap downloaded somehow somewhere). With TBB 7.0.10, it's still there in
 the extensions list but the button in the toolbar has disappeared as well
 as blocking ads has. On major websites, ads are being displayed now. So
 again, what's changed?

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

Re: [tor-bugs] #23348 [Metrics/Onionoo]: Update all documentation markdown files

[Tor Bug Tracker & Wiki]

#23348: Update all documentation markdown files
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Onionoo-1.8.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * milestone:  Onionoo-1.7.0 => Onionoo-1.8.0


Comment:

 Let's move this to the next release, I'd say.

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

Re: [tor-bugs] #16553 [Metrics/Onionoo]: Add support for searching by (partial) host name

[Tor Bug Tracker & Wiki]

#16553: Add support for searching by (partial) host name
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Very Low |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 How about we merge my branch for the upcoming release and leave the Java 8
 stuff for the next release?

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

Re: [tor-bugs] #24310 [Applications/Tor Browser]: Consider encrypted bookmarks addon for storing onions on the browser

[Tor Bug Tracker & Wiki]

#24310: Consider encrypted bookmarks addon for storing onions on the browser
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tbb, network-need  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  |Sponsor:
+--
Changes (by phw):

 * cc: phw (added)


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

[tor-bugs] #24317 [Core Tor/Tor]: Tor circuits in the same country

[Tor Bug Tracker & Wiki]

#24317: Tor circuits in the same country
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Recently, Tor circuits often choose paths trough the same country. Paths
 with three relays within the same country occur frequently but should be a
 bad idea. This makes it easier for attackers with nation-wide power. The
 risk of correlation attacks should be mitigated by using relays located
 across different countries.

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

Re: [tor-bugs] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+
Changes (by pastly):

 * status:  merge_ready => accepted


Comment:

 Wait. Gotta sort out which ticket to modify the man page in.

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

Re: [tor-bugs] #24254 [Core Tor/Tor]: There needs to be documentation on what kernel versions the KIST Scheduler will run on

[Tor Bug Tracker & Wiki]

#24254: There needs to be documentation on what kernel versions the KIST 
Scheduler
will run on
+
 Reporter:  Dbryrtfbcbhgf   |  Owner:  pastly
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-sched, tor-doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+
Changes (by pastly):

 * status:  merge_ready => accepted


Comment:

 Not yet. Rewriting moar to use less jargon and make KISTLite sound 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] #24107 [Core Tor/Tor]: Write a design document for the control interface for enhanced battery awareness on Android devices

[Tor Bug Tracker & Wiki]

#24107: Write a design document for the control interface for enhanced battery
awareness on Android devices
-+-
 Reporter:  ahf  |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s8-battery, s8-control, s8-201711|  Actual Points:
  TorCoreTeam201711.1|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by mtigas):

 This looks great to me. Don't know the specifics of Android, but what
 you've got would be super useful for the limited callbacks we get on iOS:
 
https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW3

 The app's `applicationWillResignActive:` or `applicationDidEnterBackground
 :` are where I'd likely call `SIGNAL SLEEP`, and likewise with
 `applicationDidBecomeActive:` and `SIGNAL WAKEUP`. (Right now I think I
 only call `SIGNAL HUP` at `applicationDidBecomeActive:` time, which
 doesn't always gracefully recover from the iOS background state. So think
 this will be very useful.)


 But yeah, LGTM (from the iOS point of view).

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

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


Comment:

 Tor Browser does not include uBlock Origin. See #17569 for discussion
 about adding uBlock Origin.

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

Re: [tor-bugs] #24312 [Core Tor/Tor]: Update DirCache Warning

[Tor Bug Tracker & Wiki]

#24312: Update DirCache Warning
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Hi David,

 I think there is a misunderstanding. This ticket is not about showing a
 warning to Tor Browser users.

 This ticket is about the fact that tor (relay) says:
 {{{
 This may disqualify us from becoming a guard in the future.
 }}}
 , but it should say:

 {{{
 This disqualifies us from becoming a guard.
 }}}

 or am I wrong about this?

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

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  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:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 `ticket24315_029` has some necessary changes, I hope.  I've tested a
 client a bit, but I haven't tested in too much detail.

 One point for consideration during review -- I'm not sure whether the old
 openat() rules need to remain at all, or if there really were any "opens"
 that should have not have been openats.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

[Tor Bug Tracker & Wiki]

#24316: Tor Browser doesn't filter ads anymore?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor Browser includes uBlock Origin. But TBB version 7.0.10 doesn't display
 the uBlock Origin button in the toolbar anymore. Furthermore, ads seem to
 not being blocked anymore. What's going on?

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

Re: [tor-bugs] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay

[Tor Bug Tracker & Wiki]

#24158: I get this error "Looks like our kernel doesn't have the support for 
KIST
anymore." on my relay
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

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

Re: [tor-bugs] #24312 [Core Tor/Tor]: Update DirCache Warning

[Tor Bug Tracker & Wiki]

#24312: Update DirCache Warning
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dgoulet):

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


Comment:

 "tor" in Tor Browser aren't relays so this warning can't be showed with
 Tor Browser.

 Only relays can get this warning if the available memory is `>= 300MB` and
 `DirCache 0`.

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

Re: [tor-bugs] #23442 [Applications/Tor Browser]: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp

[Tor Bug Tracker & Wiki]

#23442: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201710R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 I can't fix the parent id, it won't let me add it back (and I couldn't
 comment without removing it.)

 It was #23229

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

Re: [tor-bugs] #23442 [Applications/Tor Browser]: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp

[Tor Bug Tracker & Wiki]

#23442: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201710R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * parent:  #23229 =>


Comment:

 Replying to [comment:4 cypherpunks]:
 > Replying to [comment:3 boklm]:
 > > Adding an `#include ` to `pkixnames.cpp` is fixing the build
 issue:
 > > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_20636_v5=f7826cf2476406e668b049006c154374d546ab91
 > Not fixing. It's not even a workaround.
 > "The proper fix needs to be consistent with the fix for bug 1189891:
 change the code to use std::equals and similar instead of mem*, and remove
 all #include ." Because of
 https://bugzilla.mozilla.org/show_bug.cgi?id=1189891#c0 and other funny
 things.
 > > But maybe it can be fixed in the same way as
 https://bugzilla.mozilla.org/show_bug.cgi?id=1199624
 > It should have been fixed there "for memcmp/memmove/memset functions".
 > Also 2 occurrences of `memcpy` in https://dxr.mozilla.org/mozilla-
 esr52/source/security/manager/ssl/SSLServerCertVerification.cpp#1007
 should be fixed in the same way.
 > > However I'm wondering why we don't have the same issue for x86 builds.
 > A lot of reasons why mem* were declared there, but all of them were
 bugs.


 I spoke with Keeler about this. From his recollection there were no
 security concerns with the changes, it was just toolchain weirdness. He
 guesses that it was mostly a coincidence that we had to make those changes
 in security/pkix but not security/manager.

 If there's no build that failing with it now he doesn't see a strong
 reason to move to std::copy, etc., but he is very concern about our cert
 verifier failing, and asked if they have testcases or steps to reproduce.

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

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * owner:  dgoulet => nickm
 * reviewer:   => dgoulet


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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Add rendezvous point IPv6 address to client introduce cells

[Tor Bug Tracker & Wiki]

#23577: Add rendezvous point IPv6 address to client introduce cells
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:  2
  ipv6, review-group-25  |
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 lgtm;

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Add rendezvous point IPv6 address to client introduce cells

[Tor Bug Tracker & Wiki]

#23577: Add rendezvous point IPv6 address to client introduce cells
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:  2
  ipv6, review-group-25  |
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-
Changes (by neel):

 * Attachment "010-bugfix-r2.patch" added.

 Revision patch 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] #23577 [Core Tor/Tor]: Add rendezvous point IPv6 address to client introduce cells

[Tor Bug Tracker & Wiki]

#23577: Add rendezvous point IPv6 address to client introduce cells
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:  2
  ipv6, review-group-25  |
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-

Comment (by neel):

 I have a revised patch 010-bugfix-r2.patch which uses memset().

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

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 we can detect the specific version at runtime with gnu_get_libc_version().
 Of course, it would be cleaner to call open() and somehow discover whether
 open() or openat() is being called.

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

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 the change seems to have been made with glibc commit
 b41152d716ee9c5ba34495a54e64ea2b732139b5, which first appeared in 2.26.

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

Re: [tor-bugs] #24167 [Core Tor/Tor]: connection_check_event: Bug: Event missing on connection

[Tor Bug Tracker & Wiki]

#24167: connection_check_event: Bug: Event missing on connection
-+-
 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:  tor-relay mem-limit 031-backport |  Actual Points:
  030-backport 029-backport 028-backport |
  025-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

[Tor Bug Tracker & Wiki]

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => 029-backport 030-backport 030-backport


Comment:

 Fix for this one in `bug24198_029`.

 The problem here showed up when Chutney started to use
 OwningControllerProcess.

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

[Tor Bug Tracker & Wiki]

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  030-backport   |
Parent ID:   | Points:  0.1
 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] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Hmmm that glibc source code is kind of _crazy_ but I see that
 `__libc_open()` functions in `sysdeps/unix/sysv/linux/open.c` is calling:

 {{{
   return SYSCALL_CANCEL (openat, AT_FDCWD, file, oflag, mode);
 }}}

 A small test only doing `open()` on a file does call `openat()` and
 nothing else.

 So I assume they did (well at least on glibc 2.26 Ubuntu).

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

[Tor Bug Tracker & Wiki]

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
--+
 Reporter:  asn   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 As for the kill issue -- we call kill() either through
 tor_process_monitor_poll_cb(), or in tor_terminate_process().  I think
 it's likely to be our kill(pid, 0) usage in process_monitor_poll_cb().

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

Re: [tor-bugs] #24097 [Core Tor/Tor]: evdns_callback(): Bug: eventdns returned no addresses or error

[Tor Bug Tracker & Wiki]

#24097: evdns_callback(): Bug: eventdns returned no addresses or error
--+
 Reporter:  toralf|  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Patch looks good to me. Great that we fix '!' in the end of log messages
 to '.' 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] #20963 [Core Tor/Tor]: [notice] The Tor Directory Consensus has changed how many circuits we must track to detect network failures from 0 to 20.

[Tor Bug Tracker & Wiki]

#20963: [notice] The Tor Directory Consensus has changed how many circuits we 
must
track to detect network failures from 0 to 20.
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 031-deferred-20170425  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 The patch looks good to me. Unsure if arma still wants to comment on what
 the error message should be?

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

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, in the libevent source code at that point, it calls open, not openat.
 Is libc turning that open() into an openat?  Did the linux kernel unify
 the open and openat calls?

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

[Tor Bug Tracker & Wiki]

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
--+
 Reporter:  asn   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:6 nickm]:
 > So, I'm pretty sure that the openat one has to be a separate issue.
 dgoulet -- could you open a new ticket for that?  Has your libevent
 version changed at all?

 #24315 is not about the `openat()` 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

[tor-bugs] #24315 [Core Tor/Tor]: sandbox: openat() not handled for all our files

[Tor Bug Tracker & Wiki]

#24315: sandbox: openat() not handled for all our files
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sandbox
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 If I enable the sandbox on my system, I get killed with:

 {{{
 (Sandbox) Caught a bad syscall attempt (syscall openat)
 /usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7fb5203ab8c0]
 /lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7fb51ec6667e]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7fb51ec67150]
 /lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7fb51ec6667e]
 /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(evutil_open_closeonexec_+0x20)[0x7fb51fbb5540]
 /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(evutil_read_file_+0x53)[0x7fb51fbb5603]
 /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(evdns_base_load_hosts+0x8b)[0x7fb51fbc429b]
 /home/dgoulet/Documents/git/tor/src/or/tor(+0x9f7adf)[0x55aa6adf]
 /home/dgoulet/Documents/git/tor/src/or/tor(do_main_loop+0x745)[0x55aa440f01d5]
 /home/dgoulet/Documents/git/tor/src/or/tor(tor_run_main+0x1895)[0x55aa440f4065]
 /home/dgoulet/Documents/git/tor/src/or/tor(tor_main+0x86)[0x55aa440e1fb6]
 /home/dgoulet/Documents/git/tor/src/or/tor(main+0x1c)[0x55aa440df20c]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb51db741c1]
 /home/dgoulet/Documents/git/tor/src/or/tor(_start+0x2a)[0x55aa440e1c6a]
 }}}

 strace output:

 {{{
 19360 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 257
 19360 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
 si_call_addr=0x7f7d90ab667e, si_syscall=__NR_openat,
 si_arch=AUDIT_ARCH_X86_64 ---}
 }}}

 It is the first file being opened _after_ the seccomp sandbox has been
 applied. Our sandbox code only considers "open()" to touch that file:

  `OPEN("/etc/hosts");`

 My libc is 2.26.

 We probably need to handle the same files with `openat()` as we do with
 `open()` for this.

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

[Tor Bug Tracker & Wiki]

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
--+
 Reporter:  asn   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, I'm pretty sure that the openat one has to be a separate issue.
 dgoulet -- could you open a new ticket for that?  Has your libevent
 version changed at all?

 I'll look into the kill() thing here.

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

Re: [tor-bugs] #24167 [Core Tor/Tor]: connection_check_event: Bug: Event missing on connection

[Tor Bug Tracker & Wiki]

#24167: connection_check_event: Bug: Event missing on connection
-+-
 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:  tor-relay mem-limit 031-backport |  Actual Points:
  030-backport 029-backport 028-backport |
  025-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-relay mem-limit =>
 tor-relay mem-limit 031-backport 030-backport 029-backport
 028-backport 025-backport
 * status:  accepted => needs_review


Comment:

 Fix in branch `bug24167_025`.  This is a bug on every supported Tor
 version -- fortunately, it's not a crash bug on any of them.

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

Re: [tor-bugs] #24167 [Core Tor/Tor]: connection_check_event: Bug: Event missing on connection

[Tor Bug Tracker & Wiki]

#24167: connection_check_event: Bug: Event missing on connection
-+
 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:  tor-relay mem-limit  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Okay. So the fact that the connection was marked for close at
 `src/or/connection.c:3894` means that it was closed via
 `connection_close_immediate`, because a buf_flush_to_tls() operation gave
 us a TLS error.

 Then, later, we call connection_start_reading on the connection -- from
 connection_bucket_refill if the logs can be believed.

 I don't think the memlimit issue is actually related.

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

Re: [tor-bugs] #24314 [Internal Services/Service - trac]: Change trac username to tjr

[Tor Bug Tracker & Wiki]

#24314: Change trac username to tjr
--+-
 Reporter:  tom   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Sebastian):

 I think that it would be quite difficult because (at least as of a few
 years ago) many things in trac store the user name, not an ID...

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

Re: [tor-bugs] #24222 [Metrics/Onionoo]: Improve onionoo's war structure and startup

[Tor Bug Tracker & Wiki]

#24222: Improve onionoo's war structure and startup
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Onionoo-1.8.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:  Onionoo-1.7.0 => Onionoo-1.8.0


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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Okay.  Let's give teor another change to look at it, if he has time?

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

Re: [tor-bugs] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11

[Tor Bug Tracker & Wiki]

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * priority:  Medium => High
 * 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] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by callumw):

 Replying to [comment:17 teor]:
 > Hi, thanks for your persistence, sorry it has taken a while for someone
 to reply.
 >
 > `struct sockaddr_storage` is large enough to hold an IPv4 or IPv6
 address. So we can pass a local variable of that type to getsockname(),
 even if we don't know the size of the address. On return, it will have the
 right address in it.
 >
 > Similarly, we can initialise a local `socklen_t` variable to the size of
 sockaddr_storage. On return, it will have the right size in it.
 >
 > Then, we can call tor_addr_from_sockaddr() to populate the tor_addr_t.
 And it turns out we don't even need the size for this.
 >
 > Does that help?

 Thanks! This has clarified the issue much more.

 I have implemented the function as you suggested and will submit another
 patch when I can. For now I have hit a compilation problem when attempting
 to include address.h in compat.h so that the type tor_addr_t can be used
 in the new function

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

Re: [tor-bugs] #24269 [Core Tor/Tor]: Raise a FATAL error if the user tried to combine v2 and prop224 hidden service in same directory

[Tor Bug Tracker & Wiki]

#24269: Raise a FATAL error if the user tried to combine v2 and prop224 hidden
service in same directory
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  0.3
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

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


Comment:

 Ok btw, we have this in `hs_config.c`:

 {{{
   /* XXX: Validate if we have any service that has the given service dir
 path.
* This has two problems:
*
* a) It's O(n^2), but the same comment from the bottom of
*rend_config_services() should apply.
*
* b) We only compare directory paths as strings, so we can't
*detect two distinct paths that specify the same directory
*(which can arise from symlinks, case-insensitivity, bind
*mounts, etc.).
*
* It also can't detect that two separate Tor instances are trying
* to use the same HiddenServiceDir; for that, we would need a
* lock file.  But this is enough to detect a simple mistake that
* at least one person has actually made. */
 }}}

 So known issue but not that simple to 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] #23861 [Core Tor/Tor]: Excessive I learned some more directory information. [...] log message at startup

[Tor Bug Tracker & Wiki]

#23861: Excessive I learned some more directory information. [...] log message 
at
startup
+
 Reporter:  s7r |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay, logging  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

 * keywords:   => tor-relay, logging
 * 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] #23861 [Core Tor/Tor]: Excessive I learned some more directory information. [...] log message at startup

[Tor Bug Tracker & Wiki]

#23861: Excessive I learned some more directory information. [...] log message 
at
startup
--+
 Reporter:  s7r   |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Downloading relay descriptors makes this log statement to notice level:

 `directory_info_has_arrived(now, 0, 0);` , last "0" doesn't send it to
 info. We've suppressed those for microdescriptors, I think we should also
 for normal descriptors.

 See branch: `bug23861_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

Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Onionoo-1.8.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:  Onionoo-1.7.0 => Onionoo-1.8.0


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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 I wonder how much this could be related to #21534... On what tor type do
 you see these warnings, client, relay, authorities, ... ?

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

Re: [tor-bugs] #24301 [Applications/Tor Browser]: TOR APP CRASH on Windows 7 Professional 64-bit

[Tor Bug Tracker & Wiki]

#24301: TOR APP CRASH on Windows 7 Professional 64-bit
--+---
 Reporter:  js9reyn   |  Owner:  tbb-team
 Type:  project   | Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by js9reyn):

 Replying to [comment:2 gk]:
 > Do you have some Trusteer product installed on your system?
 Yes. IBM Security Trusteer Version: Emerald Build 1804.161

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24314 [Internal Services/Service - trac]: Change trac username to tjr

[Tor Bug Tracker & Wiki]

#24314: Change trac username to tjr
--+-
 Reporter:  tom   |  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:|
--+-
 Can this be done? My trac name not matching my irc name leads to a lot of
 confusion.  I've registered tjr (just a moment ago) to make sure no one
 else had; but I'd like to keep my user history, assigned tickets, etc from
 this account.

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

Re: [tor-bugs] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 I appears that `longclaw` is seeing those warnings quite a bit. Info logs
 from October 25th shows that it happens a lot thus it is confirmed that
 this is on the real network as well.

 Fortunately, things like reachability test from authorities don't require
 a `Guard` so this random circuit breakage wouldn't affect that at least
 thus failing to vote on Running for some relays.

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

Re: [tor-bugs] #24310 [Applications/Tor Browser]: Consider encrypted bookmarks addon for storing onions on the browser

[Tor Bug Tracker & Wiki]

#24310: Consider encrypted bookmarks addon for storing onions on the browser
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tbb, network-need  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  |Sponsor:
+--
Changes (by tom):

 * cc: tom (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] #24310 [Applications/Tor Browser]: Consider encrypted bookmarks addon for storing onions on the browser

[Tor Bug Tracker & Wiki]

#24310: Consider encrypted bookmarks addon for storing onions on the browser
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tbb, network-need  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  |Sponsor:
+--

Comment (by tom):

 Does Firefox's Master Password feature encrypt bookmarks?

 Also, could you talk more about client authorization credentials for
 .onions? How are those provided today (For some reason I thought you had
 to edit torrc) via Tor Browser?

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

Re: [tor-bugs] #21534 [Core Tor/Tor]: "Client asked me to extend back to the previous hop" in small networks

[Tor Bug Tracker & Wiki]

#21534: "Client asked me to extend back to the previous hop" in small networks
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression?, guard-selection,|  Actual Points:
  dirauth|
Parent ID:  #21573   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * priority:  Medium => Very High
 * keywords:  regression?, guard-selection => regression?, guard-selection,
 dirauth


Comment:

 I can still hit that on master. This seems to be caused only by authority
 who can't pick a node for a circuit and this shows up:

 {{{
 Nov 16 09:27:50.380 [info] router_choose_random_node(): We couldn't find
 any live, fast, stable, guard routers; falling back to list of all
 routers.
 }}}

 I've added more logging and when they need a Guard, no nodes are
 considered Guards by any of the authorities leading to a probability of
 picking the same nodes twice in the path selection because tor is falling
 back to all nodes. Below are logs I've added within
 `nodes_is_unreliable()` called by
 `router_choose_random_node()->router_add_running_nodes_to_smartlist()`:

 {{{
 Nov 16 10:07:24.018 [warn] Node
 $B6813ACD5E30C9560CB8F3CAAE08EB1A9643FFE7~test002a at 127.0.0.1 is stable:
 1, is fast: 1, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $B6813ACD5E30C9560CB8F3CAAE08EB1A9643FFE7~test002a at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $24F57B943178DA7D1351F9566FDBD0620B2921CF~test000a at 127.0.0.1 is stable:
 1, is fast: 1, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $24F57B943178DA7D1351F9566FDBD0620B2921CF~test000a at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $A183E34C4F3465994DC8D69378A05F1B43141AF3~test003ba at 127.0.0.1 is
 stable: 1, is fast: 1, is possible guard: 0. We needed: Uptime, Capacity,
 Guard
 Nov 16 10:07:24.018 [warn] node
 $A183E34C4F3465994DC8D69378A05F1B43141AF3~test003ba at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] node
 $492A22ABAD8203EA2B6A10076F251AC50AB1EFE0~test001a at 127.0.0.1
 (is_runnig: 0, is_valid: 1)
 Nov 16 10:07:24.018 [warn] Node
 $01D04CBA14565AA7EFC4612F5B388B07802475AC~test004r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $01D04CBA14565AA7EFC4612F5B388B07802475AC~test004r at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $70CAC7E209998F7B073F3C13950BDE2787231D18~test005r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $70CAC7E209998F7B073F3C13950BDE2787231D18~test005r at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $2836767EF7120AF306B8A1AE87E364073334B247~test006r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $2836767EF7120AF306B8A1AE87E364073334B247~test006r at 127.0.0.1 is
 unreliable
 Nov 16 10:07:24.018 [warn] Node
 $D1657CB2A8D479F2D5D617819326C49FBB6D1133~test007r at 127.0.0.1 is stable:
 0, is fast: 0, is possible guard: 0. We needed: Uptime, Capacity, Guard
 Nov 16 10:07:24.018 [warn] node
 $D1657CB2A8D479F2D5D617819326C49FBB6D1133~test007r at 127.0.0.1 is
 unreliable
 }}}

 You can see that all `is_possible_guard` equals 0 when "Guard" was needed
 (or `need_guard = 1`). Which btw leads to this warning on the other relays
 when this happens:

 {{{
 Nov 16 10:19:16.664 [warn] connection_edge_process_relay_cell (away from
 origin) failed.
 Nov 16 10:19:16.664 [warn] circuit_receive_relay_cell (forward) failed.
 Closing.
 }}}

 That is something I've been seeing quite a bit on my test relay recently
 on the real network. So I think this might affect authorities outside
 `TestingNetwork`.

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:39 nickm]:
 > I've tried to implement the approach above in a branch
 `bug23817_032_asn_a`, based on your code.  In a different branch, called
 `bug23817_032_asn_b`, I've taken an approach that might be simpler, using
 existing functions.  Do you like one of those?

 I like your filtered approach Nick.

 I think I like (a) more than (b) because `num_reachable_filtered_guards()`
 tries to do a bit too many things at once (resets timeouts, and also only
 counts '''reachable filtered''' guards instead of just filtered). (a)
 seems simpler to understand.

 In (a) we can also constify the `entry_guard_t *` inside the smartlist
 loop. I tested it on the real net and on chutney `test-network-all` and
 seems to work well (and restrictions seem to apply correctly).

 Marking this 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] #24097 [Core Tor/Tor]: evdns_callback(): Bug: eventdns returned no addresses or error

[Tor Bug Tracker & Wiki]

#24097: evdns_callback(): Bug: eventdns returned no addresses or error
--+
 Reporter:  toralf|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 Huh. From looking at the libevent code, I believe this can happen if the
 nameserver gives us (for example) an A record or an  record of length
 zero.  If that's the case, it's not a tor bug, and we probably shouldn't
 freak out about it.

 Will nameservers do that sometimes?

 If so, I think the right response here is to downgrade the warning.  My
 branch `ticket24097_032` takes that approach.

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

[tor-bugs] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11

[Tor Bug Tracker & Wiki]

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 [notice] Tor has successfully opened a circuit. Looks like client
 functionality is working.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Your network connection speed appears to have changed. Resetting
 timeout to 60s after 18 timeouts and 892 buildtimes.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Our directory information is no longer up-to-date enough to build
 circuits: We're missing descriptors for 1/2 of our primary entry guards
 (total microdescriptors: 6124/6450).
 [notice] I learned some more directory information, but not enough to
 build a circuit: We're missing descriptors for 1/2 of our primary entry
 guards (total microdescriptors: 6124/6450).
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 [notice] Tor has successfully opened a circuit. Looks like client
 functionality is working.
 [notice] Tor has successfully opened a circuit. Looks like client
 functionality is working.
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
 [warn] Error launching circuit to node [scrubbed] for service [scrubbed].
  T= 1510821832
 Tor 0.3.2.3-alpha (git-894b61b1d19f6235) died: Caught signal 11
 /usr/bin/tor(+0x1830c9)[0x55c71b98d0c9]
 /usr/bin/tor(extend_info_free+0x1d)[0x55c71b8e0add]
 /usr/bin/tor(extend_info_free+0x1d)[0x55c71b8e0add]
 /usr/bin/tor(rend_intro_point_free+0x25)[0x55c71b88a8d5]
 /usr/bin/tor(rend_consider_services_intro_points+0x5c4)[0x55c71b894744]
 /usr/bin/tor(hs_service_run_scheduled_events+0xa1c)[0x55c71b97c15c]
 /usr/bin/tor(+0x4e931)[0x55c71b858931]
 /usr/bin/tor(+0x6e6d0)[0x55c71b8786d0]
 /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f0067487420]
 /usr/bin/tor(do_main_loop+0x29d)[0x55c71b85be1d]
 /usr/bin/tor(tor_main+0x1c25)[0x55c71b85f925]
 /usr/bin/tor(main+0x19)[0x55c71b8575c9]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f0065ea31c1]
 /usr/bin/tor(_start+0x2a)[0x55c71b85761a]
 }}}

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

Re: [tor-bugs] #24254 [Core Tor/Tor]: There needs to be documentation on what kernel versions the KIST Scheduler will run on

[Tor Bug Tracker & Wiki]

#24254: There needs to be documentation on what kernel versions the KIST 
Scheduler
will run on
+
 Reporter:  Dbryrtfbcbhgf   |  Owner:  pastly
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-sched, tor-doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+
Changes (by dgoulet):

 * keywords:  tor-sched => tor-sched, tor-doc
 * reviewer:   => dgoulet
 * status:  needs_review => merge_ready


Comment:

 lgtm;

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

Re: [tor-bugs] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 The `SocksTimeout` of 120 seconds kicked in much faster than the idle
 circuit timeout:

 {{{
 [...]
 Nov 16 09:17:03.886 [info] connection_ap_handshake_attach_circuit(): Intro
 2980528860 (id: 6) and rend circuit 0 (id: 0) circuits are not both ready.
 Stalling conn. (119 sec old)
 Nov 16 09:17:04.886 [notice] Tried for 120 seconds to get a connection to
 [scrubbed]. Giving up. (waiting for circuit)
 }}}

 Intro circuit (id = 6), choose this quite huge timeout of 52 minutes:

 {{{
 Nov 16 09:14:21.888 [info] origin_circuit_new(): Circuit 6 chose an idle
 timeout of 3140 based on 3026 seconds of predictive building remaining.
 }}}

 Seems "normal" but also quite long.

 Anyway, here is the updated branch: `bug23681_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

Re: [tor-bugs] #24254 [Core Tor/Tor]: There needs to be documentation on what kernel versions the KIST Scheduler will run on

[Tor Bug Tracker & Wiki]

#24254: There needs to be documentation on what kernel versions the KIST 
Scheduler
will run on
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  pastly
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-sched  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by pastly):

 * status:  assigned => needs_review


Comment:

 See `ticket24254` for notes added to the man page.

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

Re: [tor-bugs] #24310 [Applications/Tor Browser]: Consider encrypted bookmarks addon for storing onions on the browser

[Tor Bug Tracker & Wiki]

#24310: Consider encrypted bookmarks addon for storing onions on the browser
+--
 Reporter:  asn |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tbb, network-need  |  Actual Points:
Parent ID:  | Points:  6
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * cc: mcs (added)


Comment:

 It looks like AMO includes some add-ons that try to do something similar,
 e.g., https://addons.mozilla.org/en-US/firefox/addon/webext-private-
 bookmarks/

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

Re: [tor-bugs] #24097 [Core Tor/Tor]: evdns_callback(): Bug: eventdns returned no addresses or error

[Tor Bug Tracker & Wiki]

#24097: evdns_callback(): Bug: eventdns returned no addresses or error
--+
 Reporter:  toralf|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 That's strange. What version of libevent do you have?

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

Re: [tor-bugs] #24303 [Core Tor/Tor]: Tor fails to start if %include

[Tor Bug Tracker & Wiki]

#24303: Tor fails to start if %include
---+
 Reporter:  littlefeather  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.4-alpha
 Severity:  Major  | Resolution:
 Keywords:  config |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 Are you running Tor inside Apparmor, or something else that might restrict
 which files it's allowed to read?

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

Re: [tor-bugs] #24303 [Core Tor/Tor]: Tor fails to start if %include

[Tor Bug Tracker & Wiki]

#24303: Tor fails to start if %include
---+
 Reporter:  littlefeather  |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.3.2.4-alpha
 Severity:  Major  | Resolution:
 Keywords:  config |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  new => needs_information


Comment:

 I've just tried this, and it worked for me.  Can you say more about what
 platform you're using, and how Tor is installed?

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