Re: [tor-bugs] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by yawning):

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


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

Re: [tor-bugs] #21716 [Core Tor/Tor]: Avoid recursive call to routerlist_remove_old_routers via router_rebuild_store

[Tor Bug Tracker & Wiki]

#21716: Avoid recursive call to routerlist_remove_old_routers via
router_rebuild_store
--+
 Reporter:  anstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by aruna1234):

 I think it's the other way round. There are two call to
 router_rebuild_store() from routerlist_remove_old_routers(), compared to a
 single call in router_rebuild_store() to routerlist_remove_old_routers. Is
 there any 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] #20628 [Applications/Tor Browser]: More locales for Tor Browser

[Tor Bug Tracker & Wiki]

#20628: More locales for Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton, tbb-easy, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 I created an auto-updating page that lets us see what extra locales are
 available for Tor Browser:
 https://torpat.ch/locales

 Right now, the list of possible new locales with 100% coverage (in tor-
 launcher and torbutton) are:
 `bg, bn-BD, ca, da, en-GB, fr-CA, ga, he, id, lv, mk, nb, pt, ro, sv, zh-
 TW`

 I'd like to propose adding these, with the exception of en-GB, fr-CA, and
 pt which are probably well-enough covered by en-US, fr, and pt-BR
 respectively. So the list would be:
 `bg, bn-BD, ca, da, ga, he, id, lv, mk, nb, ro, sv, zh-TW`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25130 [Core Tor]: Installed 7.5 Initial Screen Hangs before Welcome Screen Displayed

[Tor Bug Tracker & Wiki]

#25130: Installed 7.5 Initial Screen Hangs before Welcome Screen Displayed
--+--
 Reporter:  jllover   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  Welcome Screen
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor upgraded itself to 7.5.  It no longer starts on my system which is
 running Windows Vista.  Their is a pause of 15-20 seconds and then a blank
 screen is displayed.  No splash screen is visible. The log only shows the
 following entries:

 2/3/2018 3:14:01 AM.800 [NOTICE] Bootstrapped 85%: Finishing handshake
 with first hop
 2/3/2018 3:14:02 AM.100 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 2/3/2018 3:14:03 AM.100 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 2/3/2018 3:14:03 AM.100 [NOTICE] Bootstrapped 100%: Done
 2/3/2018 3:14:08 AM.600 [NOTICE] New control connection opened from
 127.0.0.1.
 2/3/2018 3:14:08 AM.900 [NOTICE] New control connection opened from
 127.0.0.1.
 2/3/2018 3:17:18 AM.900 [NOTICE] Renaming old configuration file to
 "C:\Development\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.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] #25124 [Core Tor/Stem]: Stem v3 Onion Service support

[Tor Bug Tracker & Wiki]

#25124: Stem v3 Onion Service support
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:2 atagar]:
 > Hi David. Thanks, and in general I'd agree with you but there's been
 enough interest in v3 Onion Service support I'd be fine making this into
 the tracking issue. Adjusting the ticket title to reflect that.
 >
 > As mentioned on the list I probably won't get to this for a week or two.
 Correction, this is the correct comment on GitHub explaining the issue.
 https://github.com/micahflee/onionshare/issues/461#issuecomment-361021213

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

Re: [tor-bugs] #4187 [Core Tor/Tor]: A verified unverified-consensus should be renamed to cached-consensus

[Tor Bug Tracker & Wiki]

#4187: A verified unverified-consensus should be renamed to cached-consensus
-+-
 Reporter:  anonym   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.33
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, directory, rename, fs,   |  Actual Points:
  easy, 032-unreached|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by fristonio):

 Thanks for this nickm, it was a great help to reproduce the issue with
 your suggestion. Here is my patch for the ticket.

 https://github.com/fristonio/tor/tree/ticket4187

 Please comment if any other changes are required.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Yeah so long as the seccomp policies for AF_INET6 socket creation doesn't
 kill the calling thread, the existing Firefox code gracefully handles
 socket creation failure.

 In the event that we want to enable such a strict policy for the sandbox
 the relevant code in nsSOCKSIOLayer.cpp's nsSOCKSIOLayerAddToSocket() can
 probably be safely refactored to ignore the IPv6 detection if the desired
 socket family is AF_LOCAL.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-22794-Don-t-open-AF_INET-AF_INET6-sockets-
 when-A.patch" added.

 updated patch to also be enabled on macOS rather than just Linux

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-22794-Don-t-open-AF_INET-AF_INET6-sockets-
 when-A.patch" removed.


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

Re: [tor-bugs] #15599 [Applications/Tor Browser]: Range requests used by pdfjs are not isolated to URL bar domain (was: Range requests are not isolated to URL bar domain)

[Tor Bug Tracker & Wiki]

#15599: Range requests used by pdfjs are not isolated to URL bar domain
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201802   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-15599-Range-requests-used-by-pdfjs-are-not-
 isola.patch" removed.


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

Re: [tor-bugs] #15599 [Applications/Tor Browser]: Range requests used by pdfjs are not isolated to URL bar domain

[Tor Bug Tracker & Wiki]

#15599: Range requests used by pdfjs are not isolated to URL bar domain
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201802   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-15599-Range-requests-used-by-pdfjs-are-not-
 isola.patch" added.

 updated description to be grammatical

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

Re: [tor-bugs] #15599 [Applications/Tor Browser]: Range requests used by pdfjs are not isolated to URL bar domain

[Tor Bug Tracker & Wiki]

#15599: Range requests used by pdfjs are not isolated to URL bar domain
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201802   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Unfortunately, the user_pref setting doesn't seem to stick when placed in
 the usual 000-tor-browser.js, and it gets overwritten by pdfjs
 initialization code if specified in the usual fashion (verified with an
 rbm build).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25129 [Applications/TorBirdy]: Can you stop enabling ocsp each time on startup?

[Tor Bug Tracker & Wiki]

#25129: Can you stop enabling ocsp each time on startup?
---+-
 Reporter:  cypherpunks|  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Your addon enable ocsp 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

Re: [tor-bugs] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1000
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page

 They clearly marking all exits automatically.
 Why Tor didn't ask Google about this?!

 Cloudflare and Google must die.

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100% #HumanIsCategorizedAsARobot #FuckGoogle (was: Google's reCAPTCHA fails 100%)

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100% #HumanIsCategorizedAsARobot #FuckGoogle
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | 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] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 100% (was: Google's reCAPTCHA fails 99%)

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Tor Support   |Version:
 Severity:  Blocker | Resolution:
 Keywords:  cloudflare,google,captcha,noscript  |  Actual Points:
Parent ID:  #18361  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

 * keywords:  noscript => cloudflare,google,captcha,noscript


Comment:

 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page
 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page

 They clearly marking all exits automatically.
 Why Tor didn't ask Google 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] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  Hello71
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * status:  assigned => new


Comment:

 I will not do this. :)

 It would be best to join with " " at compile time, but I don't know if
 that's even possible with Rust macros. Alternatively, import lazy_static,
 but I got yelled at last time I was asking about TOR_RUST_DEPENDENCIES.

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

Re: [tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

[Tor Bug Tracker & Wiki]

#24456: Figure out what to do with the guardfraction feature
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dirauth, tor-guard  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Replying to [comment:4 asn]:
 > Replying to [comment:3 teor]:
 > > Replying to [comment:2 asn]:
 > > > OK I did it! I ripped off the code from the codebase. Here are the
 rewards:
 > > > {{{
 > > > 19 files changed, 11 insertions(+), 1063 deletions(-)
 > > > }}}
 > > >
 > > > Please see branch `ticket24456` in my repo for this.
 > >
 > > Quick structural review:
 > >
 > > We don't delete options, we OBSOLETE() them.
 > >
 > > We can't just delete code from networkstatus_compute_consensus() and
 any the functions it calls. Instead, we add a new consensus method, and
 only run the old code when the consensus method is old enough. For
 guardfraction, there will be a range of consensus methods that run the
 guardfraction code.
 > >
 >
 > Oh man you are right. I guess we need to do this even tho no dirauths
 run the guardfraction code right now and they don't plan to start... So
 I'd need to define a new consensus method
 `MIN_METHOD_FOR_REMOVING_GUARDFRACTION` and only run the guardfraction
 consensus code if it's between `MIN_METHOD_FOR_GUARDFRACTION` and
 `MIN_METHOD_FOR_REMOVING_GUARDFRACTION`.

 It's >= MIN_METHOD_FOR_GUARDFRACTION and <
 MIN_METHOD_FOR_REMOVING_GUARDFRACTION.

 > And then eventually when all dirauths are upgraded to versions `>=
 MIN_METHOD_FOR_REMOVING_GUARDFRACTION` we can remove that consensus
 guardfraction code too. Does this plan make sense?

 Technically, we can't remove the guardfraction code until we remove all
 the consensus methods that could have used it.
 At the moment, we support all methods from 13-28, excluding 21.

 We can't remove all the buggy guardfraction methods like we removed 21,
 because the buggy range is 20-28.
 (Maybe we could remove 20, because we'll never use it.)

 See also #24378, where I suggest we start removing some of the lower
 methods. The last time we removed consensus methods was in #10163.

 > > Votes are different: we can make authorities stop voting guardfraction
 without needing a new consensus method.
 > >
 > > How buggy is guardfraction?
 >
 > It suffers from #16255 and perhaps other unknown bugs. It's extremely
 hard to test this feature on chutney (because chutney's bandwidth weights
 are not realistic), so we only learned of #16255 when we deployed it on
 the real net.
 >
 > > Does it work?
 >
 > It "works" but it's buggy. Authorities compute bad consensus weights for
 the relays and
 > then the bandwidth equations complain.
 >
 > > Does it cause consensus failures when it's turned on?
 >
 > Yes.

 Ok, so let's rip out the vote generation code in master as soon as we
 obsolete the option.

 > > Should we backport the "don't vote guardfraction" part of this patch
 to 0.3.1 and 0.3.2?
 >
 > Not sure. Perhaps not. No dirauths have the guardfraction torrc option
 enabled anyway.

 Let's backport making the option obsolete to 0.2.9 and later.
 That's a one-line patch.

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

Re: [tor-bugs] #24378 [Core Tor/Tor]: Prune the list of supported consensus methods

[Tor Bug Tracker & Wiki]

#24378: Prune the list of supported consensus methods
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+

Comment (by teor):

 See #10163, for how we did this last 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] #25128 [Core Tor/Tor]: Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed

[Tor Bug Tracker & Wiki]

#25128: Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion
new_circuit_bucket_count >= stats->circuit_bucket failed
+
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-sched, tor-dos  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 See commit `78d6cb58707ff464` in branch `ticket24902_029_05` which is
 mergeable into master.

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

[tor-bugs] #25128 [Core Tor/Tor]: Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed

[Tor Bug Tracker & Wiki]

#25128: Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion
new_circuit_bucket_count >= stats->circuit_bucket failed
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched, tor-dos
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I changed the `DoSCircuitCreationBurst` value in my torrc and this BUG()
 was triggered:

 {{{
 Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312:
 cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >=
 stats->circuit_bucket failed. (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
 Feb 02 21:52:55.903 [warn] Bug: Non-fatal assertion
 new_circuit_bucket_count >= stats->circuit_bucket failed in
 cc_stats_refill_bucket at src/or/dos.c:312. Stack trace: (on Tor 0.3.3.1
 -alpha-dev eafa252b26ecf83a)
 Feb 02 21:52:55.903 [warn] Bug:
 /root/git/tor/src/or/tor(log_backtrace+0x42) [0x557248c2bbd2] (on Tor
 0.3.3.1-alpha-dev eafa252b26ecf83a)
 Feb 02 21:52:55.903 [warn] Bug:
 /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x557248c46f69] (on Tor
 0.3.3.1-alpha-dev eafa252b26ecf83a)
 Feb 02 21:52:55.903 [warn] Bug:
 /root/git/tor/src/or/tor(dos_cc_new_create_cell+0x263) [0x557248bf1e63]
 (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
 }}}

 This is because of:

 {{{
   /* This function is not allowed to make the bucket count smaller */
   tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket);
 }}}

 We actually can make it smaller if the Burst or Rate is changed at
 runtime.

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

Re: [tor-bugs] #24715 [Core Tor/Tor]: Job for tor.service failed when /var/run is tmpfs

[Tor Bug Tracker & Wiki]

#24715: Job for tor.service failed when /var/run is tmpfs
-+-
 Reporter:  vilhelmgray  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:  invalid
 Keywords:  tmpfs, tor.service, systemd, |  Actual Points:
  review-group-31|
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

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


Comment:

 Hi vilhelmgray! Thanks for the bug report and the patch.

 I'm wondering if this is in fact a Gentoo bug, since in the standard
 configuration, the `--PIDFile` option isn't given to tor through systemd.
 (My understanding is that this is because systemd has its own system for
 keeping track of PIDs, i.e. and so using `$MAINPID` is the most systemd-
 ish way to do this.)  Since Gentoo appears to have enabled `PIDFile`, they
 should probably also make sure that the place they are attempting to write
 to is actually available.  Perhaps the Gentoo packagers would be willing
 to either take your patch or otherwise remove `--PIDFile`?

 Feel free to reopen if I've misunderstood something… I'm not the most
 systemd-inclined person and my only experience is through setting up VMs
 for various services in Qubes.

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  Hello71
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * owner:  (none) => Hello71
 * status:  new => assigned


Comment:

 I will do 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] #24715 [Core Tor/Tor]: Job for tor.service failed when /var/run is tmpfs

[Tor Bug Tracker & Wiki]

#24715: Job for tor.service failed when /var/run is tmpfs
-+-
 Reporter:  vilhelmgray  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tmpfs, tor.service, systemd, |  Actual Points:
  review-group-31|
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * reviewer:   => isis


Comment:

 Others who are more knowledgeable about systemd are welcome to review 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] #25126 [Applications/Torbutton]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
+
 Reporter:  igt0|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #24855  | Points:
 Reviewer:  |Sponsor:
+
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 That does not surprise me. If I remember correctly, the original about:tor
 HTML and CSS was contributed by a volunteer quite a few years ago. I am
 not sure if there is a ticket for it yet, but one of the UX team projects
 for 2018 is to redesign about:tor and work on an "onboarding" flow for our
 new users.

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: chelseakomlo (added)


Comment:

 I think we could use some Rust guidance about what's the right way to do
 this.  We could maybe make a singleton copy of the string?  And then free
 it on exit somehow?

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

[tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, protover, leak
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The src/rust/protover/ffi.rs version of protover_get_supported_protocols
 returns a newly allocated char*.  But the C version of it returns a const
 char *, and doesn't allocate.  This difference causes a memory leak when
 the C code uses the rust.

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  implemented
  029-backport, 031-backport, 032-backport   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

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


Comment:

 This is now merged into dgoulet's ticket24902_029_05, and onto master for
 0.3.3. It should get merged to older versions along with the rest of
 ticket24902_029_05.

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by dgoulet):

 033 branch: `ticket25122_033_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] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and wall time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and wall time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [comment:15 karsten]:
 > My Java 8 is not good enough to say much about commit 6264477, but at
 least it doesn't look wrong to me. And commit ae12c2e looks obviously
 correct. I say if it compiles and passes tests, let's do it.

 Thanks for the quick review!

 >
 > Thanks for putting in this effort! I'm positive that it will be worth
 it.
 >
 > Let me know when I should do something. Otherwise I'll just wait for
 more commits or green light to merge.

 I didn't only mean review, but also testing or whatever you did to cause
 this ticket :-)

 Unless any bugs show up I don't intend more commits.

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:8 karsten]:
 > Interesting approach. I'd probably have stored the `int` value rather
 than the `T` reference. But I see how your approach should work as well.
 >
 > One thing, though: you're never using the `int` value returned by
 `numFromList` other than for immediately looking up the reference in the
 list. Why not use a `HashSet` instead and change `numFromList` to
 `fromSet` that returns the `T` reference directly? Just in case there are
 more than just a few thousand entries in that list. And even with those,
 the set might be faster.

 My choice of collection was rather a reflex.  Maybe, I stared at logs and
 heap dumps for too long, but how do you retrieve a particular object
 reference from a Set?

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

Re: [tor-bugs] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+--
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 I think I provided all of the necessary information. Setting as `new`
 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] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and wall time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and wall time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 My Java 8 is not good enough to say much about commit 6264477, but at
 least it doesn't look wrong to me. And commit ae12c2e looks obviously
 correct. I say if it compiles and passes tests, let's do it.

 Thanks for putting in this effort! I'm positive that it will be worth it.

 Let me know when I should do something. Otherwise I'll just wait for more
 commits or green light to merge.

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Interesting approach. I'd probably have stored the `int` value rather than
 the `T` reference. But I see how your approach should work as well.

 One thing, though: you're never using the `int` value returned by
 `numFromList` other than for immediately looking up the reference in the
 list. Why not use a `HashSet` instead and change `numFromList` to
 `fromSet` that returns the `T` reference directly? Just in case there are
 more than just a few thousand entries in that list. And even with those,
 the set might be faster.

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 See the two new commits along with the fixup from previous comment. First
 one adds the inc/dec functions for the cache size. Second commit adds a
 new() function for a client map entry.

 Branch: `ticket25122_029_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] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and wall time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and wall time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-25100
 two small commits] applying parallelization tweaks and making use of the
 metrics-lib changes.

 With [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/log/?h=task-25103 metrics-lib task-25103 branch] meronense's 516
 logs can be processed using 2G (heap usage throughout was mostly below
 1.5G and with three peaks slightly above 1.5G) in 2.5 min.

 Test runs processing of larger imports using 8G are still on the way.  So
 far, the memory handling looks fine; mostly well below 4G, only the
 processing of aus1.tp.o logs, which are quite large needed the 8G to work.
 Considering that these are the logs for a year (327 days) this should be
 ok and CollecTor is surely able to handle the regular daily imports and
 occasionally imports of a few months now with modest RAM and time demand.

 I test further and post results, but I think the changes here and those in
 metrics-lib can be reviewed now.

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

Re: [tor-bugs] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 Do we think it's dangerous to downgrade the warning without first ensuring
 that we can safely use `/dev/urandom` even early in boot?

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  merge_ready => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-25103=f12e88e696e5a3612e1a2fbbbcffbb85be893baf
 this commit] (based on the branch used above).

 This optimization of the log lines memory footprint will also benefit
 other API users when processing log descriptors.  'WebServerAccessLogLine'
 collects different items and uses references and is applied for fields
 that cannot become an enum type, e.g., there are usually only 'HTTP/1.0'
 and  'HTTP/1.1' as protocols, but we chose to also accommodate/allow
 others to be valid, too.

 I still have tests running importing CollecTor webstats logs.  An example
 of the gain these changes offer:  A heap dump of approx. 7.5G containing
 `73*10^6`  'WebServerAccessLogLine's only contains about
 `51*10^3`  String instances and less than `10^4` LocalDate instances.  As
 the heap is from importing logs with CollecTor most of the LocalDate
 instances are parts of paths and the dateList contains contains just the
 327 dates of the days available for import.

 I'll post more regarding CollecTor's webstat module on #25100.

 There is also [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-25103=60907f87c1b6c99d5a84e43faafcdccaa3a5617e
 another commit] providing hashCode and equals implementations for future
 use, but they not used currently.

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

Re: [tor-bugs] #25124 [Core Tor/Stem]: Stem v3 Onion Service support (was: Problems integrating V3 onion services using stem 1.6)

[Tor Bug Tracker & Wiki]

#25124: Stem v3 Onion Service support
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

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


Comment:

 Hi David. Thanks, and in general I'd agree with you but there's been
 enough interest in v3 Onion Service support I'd be fine making this into
 the tracking issue. Adjusting the ticket title to reflect that.

 As mentioned on the list I probably won't get to this for a week or two.

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => nickm


Comment:

 Replying to [comment:4 nickm]:
 > Looks good.  But could you take a few minutes to make sure that there is
 nowhere else in all the codebase, before or after applying #24902, that
 allocates or frees one of these objects?  And that the transport_name
 field never changes once the object is allocated?

 I really hope the `transport_name` doesn't change because it is used to
 compare entries in the HT if present. I'll confirm that.

 >
 > Possibly, we should make a _new() function to handle the allocate-and-
 count part of this function.  That could be a separate ticket, though.

 Yes agree, we need a new() there. This will be a bit bigger change to
 backport but should be fairly trivial though.

 >
 > Possibly, we should check to make sure that we never underflow on
 geoip_client_history_cache_size

 Hmmm, I'll work on inc/dev functions for that value that validates.

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Looks good.  But could you take a few minutes to make sure that there is
 nowhere else in all the codebase, before or after applying #24902, that
 allocates or frees one of these objects?  And that the transport_name
 field never changes once the object is allocated?

 Possibly, we should make a _new() function to handle the allocate-and-
 count part of this function.  That could be a separate ticket, though.

 Possibly, we should check to make sure that we never underflow on
 geoip_client_history_cache_size

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

Re: [tor-bugs] #25125 [Core Tor/Tor]: KIST: Bug: scheduler_release_channel: Non-fatal assertion !(smartlist_pos(channels_pending, chan) == -1)

[Tor Bug Tracker & Wiki]

#25125: KIST: Bug: scheduler_release_channel: Non-fatal assertion
!(smartlist_pos(channels_pending, chan) == -1)
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 squashed and merged to 0.3.2 and forward!

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:2 nickm]:
 > I'm guessing that clientmap_entry_size() is something we'd extend once
 we have this and #24902 merged to the same branch?

 Don't think so because the added stuff in a `clientmap_entry_t` in #24902
 are not allocated so the `sizeof()` will pick them up.

 >
 > The geoip_client_cache_total_allocation() function needs to be much
 faster -- otherwise it will eat tons of CPU by walking the whole map every
 time cell_queues_check_size() is called -- and it is called from inside
 append_cell_to_circuit_queue().  How about having a static size_t that we
 increment when we allocate an entry, and decrement when we free it?

 Ah right, indeed. What about this fixup commit: `64e595e07c42a6f4` ?

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

Re: [tor-bugs] #4187 [Core Tor/Tor]: A verified unverified-consensus should be renamed to cached-consensus

[Tor Bug Tracker & Wiki]

#4187: A verified unverified-consensus should be renamed to cached-consensus
-+-
 Reporter:  anonym   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.33
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, directory, rename, fs,   |  Actual Points:
  easy, 032-unreached|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Here's an easier way to see the bug:

 1. Start tor, and let it bootstrap.
 2. Stop tor.
 3. In the DataDirectory, rename `cached-microdesc-consensus` to
 `unverified-microdesc-consensus`.
 4. Start tor again.

 Although Tor will use the unverified-microdesc-consensus file, it will not
 rename it to the proper name once it is verified.

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

Re: [tor-bugs] #25126 [Applications/Torbutton]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
+
 Reporter:  igt0|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #24855  | Points:
 Reviewer:  |Sponsor:
+
Changes (by igt0):

 * parent:   => #24855


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25126 [Applications/Torbutton]: about:tor should work on small screens (mobile)

[Tor Bug Tracker & Wiki]

#25126: about:tor should work on small screens (mobile)
+
 Reporter:  igt0|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Torbutton  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+
 Right now the about:tor page doesn't render properly on mobile.

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I'm guessing that clientmap_entry_size() is something we'd extend once we
 have this and #24902 merged to the same branch?

 The geoip_client_cache_total_allocation() function needs to be much faster
 -- otherwise it will eat tons of CPU by walking the whole map every time
 cell_queues_check_size() is called -- and it is called from inside
 append_cell_to_circuit_queue().  How about having a static size_t that we
 increment when we allocate an entry, and decrement when we free it?

 Otherwise, looks plausible.

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

Re: [tor-bugs] #25125 [Core Tor/Tor]: KIST: Bug: scheduler_release_channel: Non-fatal assertion !(smartlist_pos(channels_pending, chan) == -1)

[Tor Bug Tracker & Wiki]

#25125: KIST: Bug: scheduler_release_channel: Non-fatal assertion
!(smartlist_pos(channels_pending, chan) == -1)
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Indeed and it is also faster!

 See fixup commit: `6b415382651d5a22`

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

Re: [tor-bugs] #25125 [Core Tor/Tor]: KIST: Bug: scheduler_release_channel: Non-fatal assertion !(smartlist_pos(channels_pending, chan) == -1)

[Tor Bug Tracker & Wiki]

#25125: KIST: Bug: scheduler_release_channel: Non-fatal assertion
!(smartlist_pos(channels_pending, chan) == -1)
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 [should this / could this] look at sched_heap_idx [instead of / in
 addition to] smartlist_pos()?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by karsten):

 I pushed two commits related to this branch to a branch that is under
 review for #24729. Those commits and comments there also ask the question
 above. Feel free to move that part of the discussion here, but I'm also
 happy to keep it there.

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

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:15 iwakeh]:
 > Replying to [comment:14 karsten]:
 > > Hmm, no, I don't like my last suggestion anymore after trying it out
 based on the #16513 changes. Those interpolated/upsampled points look much
 more awkward than I had expected. We'd mainly shift confusion from missing
 points to points that look like glitches. Also, we don't really need a 3
 month graph and a 6 month graph.
 >
 > Makes sense.
 >
 > > ...
 > > New plan:
 > >  - Short-term fix:
 > >- We change just the bandwidth graph for 3 months to a data
 resolution of 24 hours rather than 12 hours. That way it can accommodate
 new statistics along with old statistics.
 >
 > Let's take a look and try how this influences the resulting graphs.

 Alright, I implemented this and attached a sample graph showing 3 months
 of the relay in question in this ticket:

 [[Image(3-month-graph-with-24-hour-resolution.png, width=700px)]]

 The graph of the left is the current graph. It contains `null` values in
 the middle.

 The graph on the right is the new graph. It has fewer data points, but it
 does have the part in the middle and an additional part on the right that
 is not contained in the graph on the left.

 Please review the last four commits in
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-16513-24729
 my task-16513-24729 branch] which is based on your earlier task-16513-2
 branch:

  - 8a14e83 is an important fix related to #16513.
  - 08932a6 is what I suggested as "Tor time" in #16513 and which is
 similar to your suggestion in #25091.
  - b00d44a changes the data resolution of the bandwidth 3 months graph.
  - 5769dca retains histories on a 24 hour granularity for up to 6 months
 rather than 6.

 (Feel free to comment on the first two commits on #16513, if you prefer,
 and on the last two commits on this ticket.)

 > >- We fix Relay Search to plot `null` as missing data point rather
 than the value `0`. That's going to fix the 1 month graph, and it's the
 right thing to do anyway.
 >
 > This is a ticket, i.e., planned already, afaik.

 Okay.

 > >  - Medium-term fix:
 > >- We start retaining data in statuses on 24 hour granularity rather
 than 48 hours for up to 6 months.
 >
 > The granularity of one day is a good choice, imo.

 Done. See the fourth commit above.

 > >- In 3 months from now, we change the 3 months graph to 6 a months
 graph with a resolution of 24 hours.
 > >- Also in 3 months from now, we change Relay Search to display a 6
 months graph rather than the 3 months graph.
 >
 > Sure, the graphing window should rather be set and computed at the
 client side.

 Right, though in this case I basically meant to change the label from "3
 Months" to "6 Months". Computing things would be left to the long-term fix
 below.

 > >  - Long-term fix:
 > >- We stop giving out data for fixed intervals and provide all data
 in a single history object along with a normalized x axis with timestamps.
 >
 > A fine goal and the way to go.

 Agreed.

 > >- We teach Relay Search to draw different graphs based on this
 single history object. Basically, it will need to learn how to downsample
 data points that are too detailed for a graph showing a long period of
 time.
 > >
 >
 > Clients should be able to handle the new data.

 Agreed.

 > > I can try this out this afternoon. Does this make sense?
 >
 > Yes.  It might be good to also hear more from the client/Relay Search
 side here.  And, an opinion of what users expect to see graphed, e.g. six
 vs. three month, granularity etc.

 Hopefully, the attached graphs are sufficient to make a decision on the
 short-term fix. And yes, the medium-term and long-term changes should be
 discussed more on their own tickets.

 So, assuming this review goes through, how do we proceed, and in which
 order?

  1. Squash and merge to master.
  2. Put out a release, possibly adapting the change log.
  3. Update the specification page on metrics-web.
  4. Coordinate deployment by making backups and then updating.
  5. Create tickets for the suggested medium-term and long-term changes.
  6. Maybe also create a ticket for removing redundant graphs in the
 clients document.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "3-month-graph-with-24-hour-resolution.png" 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] #23468 [Applications/TorBirdy]: TorBirdy 0.2.3: Custom setting for protected headers lost after reboot

[Tor Bug Tracker & Wiki]

#23468: TorBirdy 0.2.3: Custom setting for protected headers lost after reboot
---+-
 Reporter:  jankowitsch|  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by sukhbir):

 Hi. I couldn't reproduce this issue. Does it still persist for you? Also
 did you install TorBirdy from the Debian repo?

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

Re: [tor-bugs] #25089 [Applications/Tor Launcher]: Tor bundle: Special characters not escaped in proxy password

[Tor Bug Tracker & Wiki]

#25089: Tor bundle: Special characters not escaped in proxy password
---+--
 Reporter:  ro0ter |  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Major  | Resolution:
 Keywords:  TorBrowserTeam201802R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * keywords:   => TorBrowserTeam201802R
 * status:  assigned => needs_review


Comment:

 Here is a fix:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug25089-01=fa8590a497b492f6da62bbf7009735a17e17ec21

 ro0ter, you can work around this bug by editing the torrc file that is
 part of your Tor Browser installation. You will want to ensure that your
 torrc includes lines that look like the following:
  HTTPSProxy 1.2.3.4:80
  HTTPSProxyAuthenticator "mcs:secret#1"
 The `HTTPSProxy` value should be `host:port` and the value for
 `HTTPSProxyAuthenticator` should be `"username:password"`.

 Note that if you later use our GUI to make changes, your manual changes
 will be overwritten.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

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

 Do you want me to open a new ticket to track this issue? Have you had any
 luck tracking own the problem?

 Kathy and I would really like to get the Tor Launcher side of Moat into
 code review (and then to the point where it can be tested by others). But
 I don't think we can do that until this problem is fixed. Thanks!

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

Re: [tor-bugs] #20892 [Applications/Tor Browser]: tools/update-responses/download_missing_versions fails to download OSX mar files

[Tor Bug Tracker & Wiki]

#20892: tools/update-responses/download_missing_versions fails to download OSX 
mar
files
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * keywords:  TorBrowserTeam201702 => TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 I pushed in branch `bug_20892` a patch using the `sha256sums-signed-
 build.txt` file to verify the downloads:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_20892=f5211682c2dd2115a2c3da3f3d5a564fe5d109ec

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

Re: [tor-bugs] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-oom, tor-dos, |  Actual Points:
  029-backport, 031-backport, 032-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review
 * keywords:  tor-relay, tor-oom, tor-dos => tor-relay, tor-oom, tor-dos,
 029-backport, 031-backport, 032-backport
 * type:  defect => enhancement


Comment:

 Because this is especially important for the DoS mitigation, I've made
 this based on 029 for which we should backport along with #24902.

 You'll notice I've picked some constant timings here for which I think it
 is reasonable but I'm happy to reconsider them.

 Branch: `ticket25122_029_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] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#24642: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser
--+--
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 David — if you are willing to live with this fix for now, can you please
 merge it and then also create a tag for us (#24614)? I would really like
 to get the Moat feature to the point of code review and testing by someone
 other than Kathy and myself.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:20 yawning]:
 > Oh hey, I was right.
 >
 > Regarding the patch:
 >  * I'm not sure if checking that the URI scheme is file is the correct
 long term fix (eg: #20337), but that bridge can be burnt when someone gets
 there.

 Agreed. Richard, if we keep the `"file://"` prefix test, please add a
 comment to #20337 so we don't forget about this loose end.

 >  * Should this apply to OSX as well?  I do not know how OSX's process
 sandboxing stuff works, or what options it has for limiting what a process
 can do.

 I think we might as well apply the patch to OSX as well since it may be
 useful there. The not-really-awesome OSX sandboxing prototype that Kathy
 and I created a while ago does use the older mechanism of the ones that
 teor discussed (sandbox-exec).

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

Re: [tor-bugs] #24860 [Core Tor/Tor]: Bug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.c

[Tor Bug Tracker & Wiki]

#24860: Bug: Assertion cmux failed in circuitmux_get_policy at 
src/or/circuitmux.c
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-sched, cmux, tor- |  Actual Points:
  channel|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 Should be fixed by #24700.

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

Re: [tor-bugs] #25124 [Core Tor/Stem]: Problems integrating V3 onion services using stem 1.6

[Tor Bug Tracker & Wiki]

#25124: Problems integrating V3 onion services using stem 1.6
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |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:

 Hmmm Stem doesn't have v3 support yet and I expect tickets to be opened to
 address any issues encountered once Stem implements it.

 This ticket is a bit too vague and tracks another ticket in another
 project for Stem. Feel free to re-open if needed but I believe atagar
 might want to track issues independently and in a more fine grained way.

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

Re: [tor-bugs] #25116 [Core Tor/Tor]: hs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuit

[Tor Bug Tracker & Wiki]

#25116: hs: circuit_log_ancient_one_hop_circuits() should probably not log 
single
onion service rendezvous circuit
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, sos, easy  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * status:  new => accepted
 * owner:  (none) => 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] #25125 [Core Tor/Tor]: KIST: Bug: scheduler_release_channel: Non-fatal assertion !(smartlist_pos(channels_pending, chan) == -1)

[Tor Bug Tracker & Wiki]

#25125: KIST: Bug: scheduler_release_channel: Non-fatal assertion
!(smartlist_pos(channels_pending, chan) == -1)
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  assigned => needs_review
 * keywords:  032-backport => 032-backport, tor-sched


Comment:

 Branch: `bug25125_032_01`

 Been on my fast test relay for more than 30 min now, no bug no nothing.
 While before, this was hit much faster. I'll keep an eye on it but I do
 think that is the fix and we have a unit test.

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

[tor-bugs] #25125 [Core Tor/Tor]: KIST: Bug: scheduler_release_channel: Non-fatal assertion !(smartlist_pos(channels_pending, chan) == -1)

[Tor Bug Tracker & Wiki]

#25125: KIST: Bug: scheduler_release_channel: Non-fatal assertion
!(smartlist_pos(channels_pending, chan) == -1)
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  032-backport
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Because of commit `cb5654f300312a8f` and `adaf3e9b89f62d68` merged last
 night, we now see a new bug (benign as far as I can tell).

 Here is the `SCHED_BUG()` on one of my test relay:

 {{{
 Feb 02 12:56:21.930 [warn] tor_bug_occurred_(): Bug:
 src/or/scheduler.c:648: scheduler_release_channel: Non-fatal assertion
 !(smartlist_pos(channels_pending, chan) == -1) failed. (on Tor 0.3.3.1
 -alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.930 [warn] Bug: Non-fatal assertion
 !(smartlist_pos(channels_pending, chan) == -1) failed in
 scheduler_release_channel at src/or/scheduler.c:648. Stack trace: (on Tor
 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.930 [warn] Bug:
 /root/git/tor/src/or/tor(log_backtrace+0x42) [0x5579b56bb582] (on Tor
 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.930 [warn] Bug:
 /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x5579b56d6919] (on Tor
 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug:
 /root/git/tor/src/or/tor(scheduler_release_channel+0x1aa) [0x5579b55edb0a]
 (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /root/git/tor/src/or/tor(+0x10bd94)
 [0x5579b563fd94] (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug:
 /root/git/tor/src/or/tor(connection_handle_write+0x2e) [0x5579b564067e]
 (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /root/git/tor/src/or/tor(+0xbb229)
 [0x5579b55ef229] (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /root/git/tor/src/or/tor(+0xb8c8f)
 [0x5579b55ecc8f] (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7fcbd0fe94c9] (on Tor
 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug:
 /root/git/tor/src/or/tor(do_main_loop+0x25c) [0x5579b5587f0c] (on Tor
 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug:
 /root/git/tor/src/or/tor(tor_run_main+0x275) [0x5579b5589475] (on Tor
 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug:
 /root/git/tor/src/or/tor(tor_main+0x3a) [0x5579b5582b3a] (on Tor 0.3.3.1
 -alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /root/git/tor/src/or/tor(main+0x19)
 [0x5579b55828a9] (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf0) [0x7fcbcff01830] (on Tor 0.3.3.1
 -alpha-dev 0fd91772b1ece9e0)
 Feb 02 12:56:21.931 [warn] Bug: /root/git/tor/src/or/tor(_start+0x29)
 [0x5579b55828f9] (on Tor 0.3.3.1-alpha-dev 0fd91772b1ece9e0)
 }}}

 It appears that we can release a channel from within
 `connection_handle_write()`. At that point, the channel was popped from
 the pending list and within the scheduler loop, we are writing the channel
 connection's outbuf onto the wire so when it is release, this bug is
 triggered in `scheduler_release_channel()`:

 {{{
   if (chan->scheduler_state == SCHED_CHAN_PENDING) {
 if (SCHED_BUG(smartlist_pos(channels_pending, chan) == -1, chan)) {
   log_warn(LD_SCHED, "Scheduler asked to release channel %" PRIu64 " "
  "but it wasn't in channels_pending",
chan->global_identifier);
 }}}

 This doesn't affect tor in any ways and the current codeflow of channels
 suggest that the release should accept that the channel is not in the
 pending list even if the scheduler state is in PENDING.

 The reason is that while in the scheduler loop, once the channel is popped
 from the pending list, we *have* to keep it in PENDING state (see #24700)
 until the scheduler is done with it and decides to put it back in the list
 or change its state. This is because a channel can be rescheduled in while
 it is in the scheduler loop which is *not* ideal for KIST but this is the
 way it is for now.

 We have to do a quick fix for 032 and 033 but this should be resolved in
 034 with #24554.

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

Re: [tor-bugs] #24921 [Internal Services/Tor Sysadmin Team]: Creating some space to host Tor Browser nightly builds

[Tor Bug Tracker & Wiki]

#24921: Creating some space to host Tor Browser nightly builds
-+-
 Reporter:  boklm|  Owner:  tpa
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 On `archeotrichon` I created a file
 `/srv/nightlies.tbb.torproject.org/htdocs/test.txt`, but loading the URL
 https://nightlies.tbb.torproject.org/test.txt I get a "Not found" error.

 Looking at the file `/etc/apache2/sites-
 enabled/10-nightlies.tbb.torproject.org.conf`, it seems it doesn't have a
 `DocumentRoot` line.

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

Re: [tor-bugs] #24456 [Core Tor/Tor]: Figure out what to do with the guardfraction feature

[Tor Bug Tracker & Wiki]

#24456: Figure out what to do with the guardfraction feature
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-dirauth, tor-guard  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+

Comment (by asn):

 Replying to [comment:3 teor]:
 > Replying to [comment:2 asn]:
 > > OK I did it! I ripped off the code from the codebase. Here are the
 rewards:
 > > {{{
 > > 19 files changed, 11 insertions(+), 1063 deletions(-)
 > > }}}
 > >
 > > Please see branch `ticket24456` in my repo for this.
 >
 > Quick structural review:
 >
 > We don't delete options, we OBSOLETE() them.
 >
 > We can't just delete code from networkstatus_compute_consensus() and any
 the functions it calls. Instead, we add a new consensus method, and only
 run the old code when the consensus method is old enough. For
 guardfraction, there will be a range of consensus methods that run the
 guardfraction code.
 >

 Oh man you are right. I guess we need to do this even tho no dirauths run
 the guardfraction code right now and they don't plan to start... So I'd
 need to define a new consensus method
 `MIN_METHOD_FOR_REMOVING_GUARDFRACTION` and only run the guardfraction
 consensus code if it's between `MIN_METHOD_FOR_GUARDFRACTION` and
 `MIN_METHOD_FOR_REMOVING_GUARDFRACTION`.

 And then eventually when all dirauths are upgraded to versions `>=
 MIN_METHOD_FOR_REMOVING_GUARDFRACTION` we can remove that consensus
 guardfraction code too. Does this plan make sense?

 > Votes are different: we can make authorities stop voting guardfraction
 without needing a new consensus method.
 >
 > How buggy is guardfraction?

 It suffers from #16255 and perhaps other unknown bugs. It's extremely hard
 to test this feature on chutney (because chutney's bandwidth weights are
 not realistic), so we only learned of #16255 when we deployed it on the
 real net.

 > Does it work?

 It "works" but it's buggy. Authorities compute bad consensus weights for
 the relays and
 then the bandwidth equations complain.

 > Does it cause consensus failures when it's turned on?

 Yes.

 > Should we backport the "don't vote guardfraction" part of this patch to
 0.3.1 and 0.3.2?

 Not sure. Perhaps not. No dirauths have the guardfraction torrc option
 enabled anyway.

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

Re: [tor-bugs] #24995 [Applications/Tor Browser]: Truncated git hash not available in the windows expert bundle build for Tor 0.3.2.9

[Tor Bug Tracker & Wiki]

#24995: Truncated git hash not available in the windows expert bundle build for 
Tor
0.3.2.9
+--
 Reporter:  TheDcoder   |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201802R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm, TorBrowserTeam201801 => tbb-rbm,
   TorBrowserTeam201802R
 * status:  needs_revision => needs_review


Comment:

 There is a new version of the patch in branch `bug_24995_v3`, using
 `abbrev_length` instead of `abbrev_lenght`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_24995_v3=c873b63900021e29f7ac01c92145e91a7cb64fff

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ffmancera):

 * status:  new => needs_review


Comment:

 Here is a patch! I hope everything is fine.

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ffmancera):

 * Attachment "0001-Bug22614-Make-e10s-non-e10s-Tor-Browsers-
 indistingui.patch" 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] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff52-esr, tbb-fingerprinting => ff52-esr, tbb-fingerprinting,
 TorBrowserTeam201802R


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

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:14 karsten]:
 > Hmm, no, I don't like my last suggestion anymore after trying it out
 based on the #16513 changes. Those interpolated/upsampled points look much
 more awkward than I had expected. We'd mainly shift confusion from missing
 points to points that look like glitches. Also, we don't really need a 3
 month graph and a 6 month graph.

 Makes sense.

 > ...
 > New plan:
 >  - Short-term fix:
 >- We change just the bandwidth graph for 3 months to a data
 resolution of 24 hours rather than 12 hours. That way it can accommodate
 new statistics along with old statistics.

 Let's take a look and try how this influences the resulting graphs.

 >- We fix Relay Search to plot `null` as missing data point rather
 than the value `0`. That's going to fix the 1 month graph, and it's the
 right thing to do anyway.

 This is a ticket, i.e., planned already, afaik.


 >  - Medium-term fix:
 >- We start retaining data in statuses on 24 hour granularity rather
 than 48 hours for up to 6 months.

 The granularity of one day is a good choice, imo.

 >- In 3 months from now, we change the 3 months graph to 6 a months
 graph with a resolution of 24 hours.
 >- Also in 3 months from now, we change Relay Search to display a 6
 months graph rather than the 3 months graph.

 Sure, the graphing window should rather be set and computed at the client
 side.

 >  - Long-term fix:
 >- We stop giving out data for fixed intervals and provide all data in
 a single history object along with a normalized x axis with timestamps.

 A fine goal and the way to go.

 >- We teach Relay Search to draw different graphs based on this single
 history object. Basically, it will need to learn how to downsample data
 points that are too detailed for a graph showing a long period of time.
 >

 Clients should be able to handle the new data.

 > I can try this out this afternoon. Does this make sense?

 Yes.  It might be good to also hear more from the client/Relay Search side
 here.  And, an opinion of what users expect to see graphed, e.g. six vs.
 three month etc.

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

Re: [tor-bugs] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by gk):

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


Comment:

 Glad to hear. Please reopen the ticket if the issue comes up again, so
 that we can investigate whether we can do something on our side.

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

Re: [tor-bugs] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 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] #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:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:42 karsten]:
 > Here's a possible improvement: how about we use the last consensus
 valid-after time or bridge network status publication timestamp

 > as timestamp

 Which timestamp in particular are you referring to?

 >rather than the last time we saw a specific relay or bridge? I think we
 called that "Tor time" on #25002. This would lead to a smaller `out/`
 directory, because we wouldn't write as detailed history files anymore for
 relays or bridges that are long gone. Does this make sense?

 Regardless, 'Tor time' makes sense, b/c it is a value from the network and
 not 'added' to the data.

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

Re: [tor-bugs] #24870 [Metrics/Onionoo]: Use java 8 date-time functionality in Onionoo

[Tor Bug Tracker & Wiki]

#24870: Use java 8 date-time functionality in Onionoo
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:  #23752   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Note: This also applies to the new graph history compiler code.

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

Re: [tor-bugs] #24973 [Core Tor/Tor]: Tor should be more gentle when launching dozens of circuits at once

[Tor Bug Tracker & Wiki]

#24973: Tor should be more gentle when launching dozens of circuits at once
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-dos tor-hs performance  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by alecmuffett):

 * cc: alecmuffett (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] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 ...Did you change anything? :)

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

Re: [tor-bugs] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Snowflake again works for me.

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

Re: [tor-bugs] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 In particular, I wonder if your system has the "atomic" library installed
 or not: #25087.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #21704, #23745, #18022, #21850, ...

[Tor Bug Tracker & Wiki]

Batch modification to #21704, #23745, #18022, #21850, #22659 by gk:


Comment:
Moving reviews to February.

--
Tickets URL: 

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

Re: [tor-bugs] #15599 [Applications/Tor Browser]: Range requests used by pdfjs are not isolated to URL bar domain

[Tor Bug Tracker & Wiki]

#15599: Range requests used by pdfjs are not isolated to URL bar domain
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201802   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-linkability, TorBrowserTeam201801R => tbb-linkability,
 TorBrowserTeam201802


Comment:

 Okay, let's try that in the alpha series a bit. I admit, though, I am a
 bit skeptical whether the possible usability issues are worth it. We'll
 see.

 But before that, two things:

 1) s/cannot/can/ (it seems to me one negation is already enough :) )
 2) `extension-overrides.js` is the wrong place for the patch. We don't
 treat `pdf.js` as en extension but rather as part of the browse core
 (after all it does not show up in the `about:addons` menu etc.). So, our
 usual prefs file, `000-tor-browser.js`, would be the better place.

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

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by karsten):

 Hmm, no, I don't like my last suggestion anymore after trying it out based
 on the #16513 changes. Those interpolated/upsampled points look much more
 awkward than I had expected. We'd mainly shift confusion from missing
 points to points that look like glitches. Also, we don't really need a 3
 month graph and a 6 month graph.

 [[Image(relay-search-upsampled.png, width=700px)]]

 New plan:
  - Short-term fix:
- We change just the bandwidth graph for 3 months to a data resolution
 of 24 hours rather than 12 hours. That way it can accommodate new
 statistics along with old statistics.
- We fix Relay Search to plot `null` as missing data point rather than
 the value `0`. That's going to fix the 1 month graph, and it's the right
 thing to do anyway.
  - Medium-term fix:
- We start retaining data in statuses on 24 hour granularity rather
 than 48 hours for up to 6 months.
- In 3 months from now, we change the 3 months graph to 6 a months
 graph with a resolution of 24 hours.
- Also in 3 months from now, we change Relay Search to display a 6
 months graph rather than the 3 months graph.
  - Long-term fix:
- We stop giving out data for fixed intervals and provide all data in a
 single history object along with a normalized x axis with timestamps.
- We teach Relay Search to draw different graphs based on this single
 history object. Basically, it will need to learn how to downsample data
 points that are too detailed for a graph showing a long period of time.

 I can try this out this afternoon. Does this make sense?

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

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "relay-search-upsampled.png" 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] #13575 [Applications/Tor Browser]: Disable randomised Firefox HTTP cache decay user test groups

[Tor Bug Tracker & Wiki]

#13575: Disable randomised Firefox HTTP cache decay user test groups
-+-
 Reporter:  isis |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-pref, tbb-fingerprinting,|  Actual Points:
  ff52-esr, tbb-easy, TorBrowserTeam201801R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks, applied to `tor-browser-52.6.0esr-8.0-2` (commit
 f6d6512bf85d964fa5a470f2528042c527523a34).

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

Re: [tor-bugs] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * component:  - Select a component => Obfuscation/Snowflake


Comment:

 Do you have some log output showing what is going on (you might get it if
 you start Tor Browser from the command line)?

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

Re: [tor-bugs] #25123 [Obfuscation/Snowflake]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
---+---
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * cc: dcf, arlolra (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] #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:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by karsten):

 Here's a possible improvement: how about we use the last consensus valid-
 after time or bridge network status publication timestamp as timestamp
 rather than the last time we saw a specific relay or bridge? I think we
 called that "Tor time" on #25002. This would lead to a smaller `out/`
 directory, because we wouldn't write as detailed history files anymore for
 relays or bridges that are long gone. Does this make sense?

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

Re: [tor-bugs] #25016 [Applications/Tor Browser]: Remove 2017 in-browser donation banner

[Tor Bug Tracker & Wiki]

#25016: Remove 2017 in-browser donation banner
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201801R |  Actual Points:
Parent ID:  #23482| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Thanks, looks good to me. No need for a patch for `maint-1.9.7` as we are
 using 1.9.8.X for the 7.5 series (there is no `maint-1.9.8` branch yet).
 Thus, I just merged your changes to `master` (commit
 f96a293d146d3dc54f8ecfaa1d3dfc669bf4198d).

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 For what it's worth, I'm of the opinion that the `AF_INET6` socket being
 created is probably fine, as long as the browser isn't rendered non-
 functional if `AF_INET6` isn't supported.

 This can be revisited if/when people want to write seccomp rules that will
 kill (rather than gently reject) proscribed calls, but I don't think
 that's realistic at the moment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25124 [Core Tor/Stem]: Problems integrating V3 onion services using stem 1.6

[Tor Bug Tracker & Wiki]

#25124: Problems integrating V3 onion services using stem 1.6
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 The Onionshare developers have been experiencing issues getting V3 onions
 services working correctly with onionshare using stem. Here is the ticket
 on GitHub with the issues explained in detail.
 https://github.com/micahflee/onionshare/issues/461#issuecomment-360971386

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