Re: [tor-bugs] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

[Tor Bug Tracker & Wiki]

#27813: Tor 0.3.4.8 is leaking memory
-+-
 Reporter:  anong|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Critical | Resolution:
 Keywords:  regression? memleak oom  |  Actual Points:
  034-backport tor-relay 035-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rm):

 Replying to [comment:33 dgoulet]:
 > but on the `Send-Q` side, because the entire network running <= 0.3.4.8
 still have that issue, it will keep filling up.
 >
 > Until we roll out 0.3.4.9 and everyone updates, it won't fully go away
 :S.

 What? You are saying remote peers can do something (no matter what) which
 causes you to leak memory and eventually get OOM? I.e. basically Tor has a
 remote DoS vulnerability? And your solution for that is to kindly ask
 everyone to stop doing that (upgrade versions)? You can't be serious.

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

Re: [tor-bugs] #28283 [Webpages/Website]: Please add job description to website (Metrics Data Architect)

[Tor Bug Tracker & Wiki]

#28283: Please add job description to website (Metrics Data Architect)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by ewyatt:

Old description:

> {{{
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>

> Internet Freedom Nonprofit Seeks Metrics Data Architect
>
> 2-Nov-2018
>
> The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human
> rights and freedoms by creating and deploying free and open source
> anonymity and privacy technologies, is seeking an experienced Data
> Architect to take our metrics work to the next level.
>
> Tor is for everyone, and we are actively working to build a team that
> represents people from all over the world — people from diverse ethnic,
> national, and cultural backgrounds; people from all walks of life. Racial
> minorities, non-gender-binary people, women, and people from any group
> that is generally underrepresented in tech are encouraged to apply.
>
> The team:
>
> Our Metrics Team has been collecting data since 2004 to help improve the
> tools we build and learn more about the Tor network. For example, we
> monitor the number of relays and clients in the network, their respective
> capabilities, the number of clients connecting via bridges, fluctuations
> in network speed, etc. Gathering this data results in huge data archives,
> so we are also working to develop tools to process this data and make it
> available to everyone.
>
> How we achieve our goals:
> •   Robustness (We want to avoid bugs and/or bad design
> decision that cause us to miss data)
> •   Timeliness (users need up-to-date network status
> information)
> •   Scalability (as the network grows, so does our data)
> •   Transparency (our community rightly wants to know what
> data we're collecting)
>
> The Tor Metrics team presently consists of two full-time developers; this
> position will be the third. Our team works asynchronously on each
> person’s own schedule, but we sync regularly via Git, Trac, IRC, e-mail,
> and an occasional video chat.
>
> The most interesting challenge for the Metrics team is how to gather data
> on an anonymity system without de-anonymizing users.
>
> The job:
>
> The person in this position will work directly with helping us design and
> refine systems for gathering and analyzing data. The bulk of our code is
> written in Java, but smaller portions are written in R, Python,
> PostgreSQL, and JavaScript. Part of this job will be to analyze and fix
> bugs in our current code and review patches. We will also be migrating
> parts of our code from Java to Python, and the person in this position
> will help with that.
>
> Our main five codebases:
> •   Collector (https://gitweb.torproject.org/collector.git/ )
> •   metrics-lib (https://gitweb.torproject.org/metrics-
> lib.git/ )
> •   Onionoo (https://gitweb.torproject.org/onionoo.git/ )
> •   Exonerator (https://gitweb.torproject.org/exonerator.git/
> )
> •   metrics-web (https://gitweb.torproject.org/metrics-
> web.git/ )
>
> Requirements:
>
> Technical abilities/experience:
> •   Have experience finding your way into existing
> Java/Python/R/PostgreSQL code bases and the ability to review patches and
> make changes to fix bugs/smaller enhancements.
> •   Able to identify shortcomings in our data pipeline and
> suggest improvements to reduce complexity and future maintenance efforts.
> •   Experience working with Git and Trac or similar issue
> tracking tools.
> •   Ability to learn quickly and can adapt to our current
> processes; are able to improve future processes for releasing software
> and operating services.
> •   Understanding of the inherent privacy implications of
> gathering data in an anonymity system, the security implications of
> gathering metrics data from semi-trusted relays in the Tor network, and
> the challenges of processing large amounts of data per day (specifically
> performance and scalability challenges).
>
> Collaborative requirements:
> •   Ability to work remotely 90% of the time, as most team
> synchronization happening via email and/or IRC.
> •   Participation in weekly IRC meetings and monthly team
> video chats.
> •   Willingness and ability to travel internationally up to
> four times per year, to semi-annual Tor meeting plus up to two team-
> internal meetings.
> •   Language: write and 

[tor-bugs] #28283 [Webpages/Website]: Please add job description to website (Metrics Data Architect)

[Tor Bug Tracker & Wiki]

#28283: Please add job description to website (Metrics Data Architect)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Internet Freedom Nonprofit Seeks Metrics Data Architect

 2-Nov-2018

 The Tor Project, Inc., a 501(c)(3) nonprofit organization advancing human
 rights and freedoms by creating and deploying free and open source
 anonymity and privacy technologies, is seeking an experienced Data
 Architect to take our metrics work to the next level.

 Tor is for everyone, and we are actively working to build a team that
 represents people from all over the world — people from diverse ethnic,
 national, and cultural backgrounds; people from all walks of life. Racial
 minorities, non-gender-binary people, women, and people from any group
 that is generally underrepresented in tech are encouraged to apply.

 The team:

 Our Metrics Team has been collecting data since 2004 to help improve the
 tools we build and learn more about the Tor network. For example, we
 monitor the number of relays and clients in the network, their respective
 capabilities, the number of clients connecting via bridges, fluctuations
 in network speed, etc. Gathering this data results in huge data archives,
 so we are also working to develop tools to process this data and make it
 available to everyone.

 How we achieve our goals:
 •   Robustness (We want to avoid bugs and/or bad design
 decision that cause us to miss data)
 •   Timeliness (users need up-to-date network status
 information)
 •   Scalability (as the network grows, so does our data)
 •   Transparency (our community rightly wants to know what
 data we're collecting)

 The Tor Metrics team presently consists of two full-time developers; this
 position will be the third. Our team works asynchronously on each person’s
 own schedule, but we sync regularly via Git, Trac, IRC, e-mail, and an
 occasional video chat.

 The most interesting challenge for the Metrics team is how to gather data
 on an anonymity system without de-anonymizing users.

 The job:

 The person in this position will work directly with helping us design and
 refine systems for gathering and analyzing data. The bulk of our code is
 written in Java, but smaller portions are written in R, Python,
 PostgreSQL, and JavaScript. Part of this job will be to analyze and fix
 bugs in our current code and review patches. We will also be migrating
 parts of our code from Java to Python, and the person in this position
 will help with that.

 Our main five codebases:
 •   Collector (https://gitweb.torproject.org/collector.git/ )
 •   metrics-lib (https://gitweb.torproject.org/metrics-
 lib.git/ )
 •   Onionoo (https://gitweb.torproject.org/onionoo.git/ )
 •   Exonerator (https://gitweb.torproject.org/exonerator.git/
 )
 •   metrics-web (https://gitweb.torproject.org/metrics-
 web.git/ )

 Requirements:

 Technical abilities/experience:
 •   Have experience finding your way into existing
 Java/Python/R/PostgreSQL code bases and the ability to review patches and
 make changes to fix bugs/smaller enhancements.
 •   Able to identify shortcomings in our data pipeline and
 suggest improvements to reduce complexity and future maintenance efforts.
 •   Experience working with Git and Trac or similar issue
 tracking tools.
 •   Ability to learn quickly and can adapt to our current
 processes; are able to improve future processes for releasing software and
 operating services.
 •   Understanding of the inherent privacy implications of
 gathering data in an anonymity system, the security implications of
 gathering metrics data from semi-trusted relays in the Tor network, and
 the challenges of processing large amounts of data per day (specifically
 performance and scalability challenges).

 Collaborative requirements:
 •   Ability to work remotely 90% of the time, as most team
 synchronization happening via email and/or IRC.
 •   Participation in weekly IRC meetings and monthly team
 video chats.
 •   Willingness and ability to travel internationally up to
 four times per year, to semi-annual Tor meeting plus up to two team-
 internal meetings.
 •   Language: write and speak fluent English.
 •   Comfortable posting to a public mailing list or speaking
 up in a public IRC channel to ask questions, even when you 

Re: [tor-bugs] #27601 [Applications/Tor Browser]: browser notifications are not working anymore with Tor Browser 8 (was: growl a-like browser notifications are not working anymore on macOS with Tor Br

[Tor Bug Tracker & Wiki]

#27601: browser notifications are not working anymore with Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201810|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nsIContentPermissionRequest):

 Replying to [comment:2 mcs]:
 On Windows 10:
 {{{
 0:26:44.707 [Exception... "Component returned failure code: 0x80004005
 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.principal]"  nsresult:
 "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
 
jar:file:///C:/Tor%20Browser/Browser/browser/omni.ja!/components/nsBrowserGlue.js
 :: prompt :: line 3000"  data: no] (unknown)
 prompt
 
jar:file:///C:/Tor%20Browser/Browser/browser/omni.ja!/components/nsBrowserGlue.js:3000:1
 0:26:44.707 NS_ERROR_FAILURE: Component returned failure code: 0x80004005
 (NS_ERROR_FAILURE) [nsIContentPermissionRequest.cancel]
 nsBrowserGlue.js:3024
 }}}

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

Re: [tor-bugs] #28011 [Core Tor/Tor]: shellcheck: run_calltool.sh issues

[Tor Bug Tracker & Wiki]

#28011: shellcheck: run_calltool.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  mikeperry   |Sponsor:
+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks good!

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

Re: [tor-bugs] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
---+--
 Reporter:  antonela   |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  sstevenson, steph  |Sponsor:
---+--
Changes (by antonela):

 * Attachment "tpo.org - YE - strong - dark - iteration2 green.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] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
---+--
 Reporter:  antonela   |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  sstevenson, steph  |Sponsor:
---+--
Changes (by antonela):

 * Attachment "tpo.org - YE - strong - dark - iteration2.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] #28010 [Core Tor/Tor]: shellcheck: run_trunnel.sh issues

[Tor Bug Tracker & Wiki]

#28010: shellcheck: run_trunnel.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  mikeperry   |Sponsor:
+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks good!

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

Re: [tor-bugs] #27601 [Applications/Tor Browser]: growl a-like browser notifications are not working anymore on macOS with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27601: growl a-like browser notifications are not working anymore on macOS with
Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201810|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gok):

 I just tested notifications with TBB 8.5a4 and First Party Isolation
 enabled, and notifications did not work.
 I don't know how different TBB alpha and TBB nightly currently are though,
 so I don't know if this bit of information helps.

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

Re: [tor-bugs] #25461 [Core Tor/Tor]: main event-loop spins consuming 100% of a CPU core running scheduler_set_channel_state

[Tor Bug Tracker & Wiki]

#25461: main event-loop spins consuming 100% of a CPU core running
scheduler_set_channel_state
-+-
 Reporter:  Dhalgren |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  performance, 034-roadmap-subtask,|  Actual Points:
  034-triage-20180328, 034-included-20180328 |
  035-removed|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * parent:  #25500 =>


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

Re: [tor-bugs] #28006 [Core Tor/Tor]: shellcheck: chutney-git-bisect.sh issues

[Tor Bug Tracker & Wiki]

#28006: shellcheck: chutney-git-bisect.sh issues
--+-
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks good.

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

Re: [tor-bugs] #25461 [Core Tor/Tor]: main event-loop spins consuming 100% of a CPU core running scheduler_set_channel_state

[Tor Bug Tracker & Wiki]

#25461: main event-loop spins consuming 100% of a CPU core running
scheduler_set_channel_state
-+-
 Reporter:  Dhalgren |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  performance, 034-roadmap-subtask,|  Actual Points:
  034-triage-20180328, 034-included-20180328 |
  035-removed|
Parent ID:  #25500   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


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

Re: [tor-bugs] #28282 [Core Tor/sbws]: Refactor bandwidth file generation code

[Tor Bug Tracker & Wiki]

#28282: Refactor bandwidth file generation code
--+--
 Reporter:  juga  |  Owner:  juga
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor, technical-debt  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by juga:

Old description:

> Initially, `v3bwfile.py` was just converting measurement `Result`s to a
> `Bandwidth file` lines format.
> Then we started to apply scaling methods and filtering the measurements
> to satisfy certain restrictions.
> To don not have to modify code in other file/classes, all of that was
> implemented in `v3bwfile.py` classes/methos, but it should be moved to
> either an intermediate file/classes that deal with the statistics
> calculations (and not the format) or modify `Results` to be able to
> perform those calculations.

New description:

 Initially, `v3bwfile.py` was just converting measurement `Result`s to a
 `Bandwidth file` lines format.
 Then we started to apply scaling methods and filtering the measurements to
 satisfy certain restrictions.
 To don not have to modify code in other file/classes, all of that was
 implemented in `v3bwfile.py` classes/methods, but it should be moved to
 either an intermediate file/classes that deal with the statistics
 calculations (and not the format) or modify `Results` to be able to
 perform those calculations.

 Edit: fix typo

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28282 [Core Tor/sbws]: Refactor bandwidth file generation code

[Tor Bug Tracker & Wiki]

#28282: Refactor bandwidth file generation code
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:  refactor, technical-debt
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Initially, `v3bwfile.py` was just converting measurement `Result`s to a
 `Bandwidth file` lines format.
 Then we started to apply scaling methods and filtering the measurements to
 satisfy certain restrictions.
 To don not have to modify code in other file/classes, all of that was
 implemented in `v3bwfile.py` classes/methos, but it should be moved to
 either an intermediate file/classes that deal with the statistics
 calculations (and not the format) or modify `Results` to be able to
 perform those calculations.

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

Re: [tor-bugs] #27225 [Core Tor/Tor]: Perform fewer allocations in summarize_protocol_flags()

[Tor Bug Tracker & Wiki]

#27225: Perform fewer allocations in summarize_protocol_flags()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26630   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor8
-+-

Comment (by mikeperry):

 Hrmm question: Do we require a specific ordering on protover keywords? The
 proposal says we "should" sort by keyword. But if other tor
 implementations do not carefully order protover strings (or if
 modularization of core-tor makes the protover strings dynamically
 generated in non-deterministic order), then we may exceed
 MAX_PROTOVER_SUMMARY_MAP_LEN, right?

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

Re: [tor-bugs] #26478 [Core Tor/Tor]: Unify bandwidth related terms in dir-spec and Tor code.

[Tor Bug Tracker & Wiki]

#26478: Unify bandwidth related terms in dir-spec and Tor code.
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, 035-roadmap-proposed,|  Actual Points:
  refactor   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * keywords:  tor-bwauth, 035-roadmap-proposed => tor-bwauth, 035-roadmap-
 proposed, refactor


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

Re: [tor-bugs] #28128 [Core Tor/Tor]: v3 client auth: No interned sandbox parameter found

[Tor Bug Tracker & Wiki]

#28128: v3 client auth: No interned sandbox parameter found
-+
 Reporter:  pege |  Owner:  dgoulet
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.5.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, sandbox  |  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] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


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

Re: [tor-bugs] #15621 [Core Tor/Tor]: Kill the pre-version 3 intro protocol code with fire.

[Tor Bug Tracker & Wiki]

#15621: Kill the pre-version 3 intro protocol code with fire.
-+-
 Reporter:  yawning  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs technical-debt deprecation|  Actual Points:
  prop224|
Parent ID:  #6418| Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

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


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

Re: [tor-bugs] #15621 [Core Tor/Tor]: Kill the pre-version 3 intro protocol code with fire.

[Tor Bug Tracker & Wiki]

#15621: Kill the pre-version 3 intro protocol code with fire.
-+-
 Reporter:  yawning  |  Owner:  dgoulet
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs technical-debt deprecation|  Actual Points:
  prop224|
Parent ID:  #6418| Points:  1
 Reviewer:  asn  |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  accepted => new


Comment:

 I would love to see this but we also need to be wise about it. For now,
 unassigning from 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] #26300 [Core Tor/Tor]: Attempt by … to open a stream on first hop of circuit. Closing.

[Tor Bug Tracker & Wiki]

#26300: Attempt by … to open a stream on first hop of circuit. Closing.
--+---
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dgoulet):

 * milestone:  Tor: 0.3.6.x-final => Tor: unspecified


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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  bsd, test, 032-backport, |  Actual Points:
  033-triage-20180320, 033-removed-20180320, |
  031-unreached-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

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


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

Re: [tor-bugs] #25461 [Core Tor/Tor]: main event-loop spins consuming 100% of a CPU core running scheduler_set_channel_state

[Tor Bug Tracker & Wiki]

#25461: main event-loop spins consuming 100% of a CPU core running
scheduler_set_channel_state
-+-
 Reporter:  Dhalgren |  Owner:  dgoulet
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.14
 Severity:  Normal   | Resolution:
 Keywords:  performance, 034-roadmap-subtask,|  Actual Points:
  034-triage-20180328, 034-included-20180328 |
  035-removed|
Parent ID:  #25500   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => new


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

Re: [tor-bugs] #25568 [Core Tor/Tor]: hs: Lookup failure cache when introducing to an intro point

[Tor Bug Tracker & Wiki]

#25568: hs: Lookup failure cache when introducing to an intro point
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, tor-hs,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28281 [Core Tor/Tor]: outline of high-level bootstrap tracker abstractions

[Tor Bug Tracker & Wiki]

#28281: outline of high-level bootstrap tracker abstractions
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  s8-boostrap
Actual Points:|  Parent ID:  #28018
   Points:  0.5   |   Reviewer:
  Sponsor:  Sponsor8  |
--+
 This is a placeholder to summarize the high-level bootstrap tracking
 abstractions I talked about with Nick.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28280 [Core Tor/Tor]: control: Add a key to GETINFO to get the DoS subsystem stats

[Tor Bug Tracker & Wiki]

#28280: control: Add a key to GETINFO to get the DoS subsystem stats
--+---
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-control, tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 The DoS subsystem keeps track of statistics that are logged in the
 heartbeat with `dos_log_heartbeat()`. I would like those to be exposed to
 the control port so it can be collected and graph over time (improve relay
 monitoring).

 (Follows the idea behind #28279)

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

Re: [tor-bugs] #28279 [Core Tor/Tor]: control: Add a key to GETINFO to fetch the circuit onion handshake rephist values

[Tor Bug Tracker & Wiki]

#28279: control: Add a key to GETINFO to fetch the circuit onion handshake 
rephist
values
---+--
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28279 [Core Tor/Tor]: control: Add a key to GETINFO to fetch the circuit onion handshake rephist values

[Tor Bug Tracker & Wiki]

#28279: control: Add a key to GETINFO to fetch the circuit onion handshake 
rephist
values
--+---
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-control, tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Basically something that would export the rephist value of the onion
 handshakes:

 {{{
 onion_handshakes_assigned
 onion_handshakes_requested
 }}}

 The heartbeat uses `rep_hist_log_circuit_handshake_stats()` to log the
 ntor and tap stats. I want those from the GETINFO command in order to be
 able to graph and keep stats over time of those values.

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

Re: [tor-bugs] #27968 [Core Tor/Tor]: SIGNAL HALT race condition in test-rebind.py

[Tor Bug Tracker & Wiki]

#27968: SIGNAL HALT race condition in test-rebind.py
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ci|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 lgtm!

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

Re: [tor-bugs] #28151 [Internal Services/Service - sandstorm]: sandstorm: should never happen: anonymous, but no token either.

[Tor Bug Tracker & Wiki]

#28151: sandstorm: should never happen: anonymous, but no token either.
-+-
 Reporter:  traumschule  |  Owner:  hiro
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  sandstorm  |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by hiro):

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


Comment:

 I think it is ok if we close it. It can take a lot of time before this is
 fixed upstread and it is not causing any issues 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] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

[Tor Bug Tracker & Wiki]

#27813: Tor 0.3.4.8 is leaking memory
-+-
 Reporter:  anong|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Critical | Resolution:
 Keywords:  regression? memleak oom  |  Actual Points:
  034-backport tor-relay 035-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:32 torkit]:
 > I've tested the proposed patch that has been merged into maint-0.3.4
 branch and do have the same behavior as before. tor keeps getting killed.
 I'll check 0.3.3 for regression now.

 So in theory, your relay should not anymore have `Recv-Q` that keeps
 filling up ... but on the `Send-Q` side, because the entire network
 running <= 0.3.4.8 still have that issue, it will keep filling up.

 Until we roll out 0.3.4.9 and everyone updates, it won't fully go away :S.

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

Re: [tor-bugs] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

[Tor Bug Tracker & Wiki]

#27813: Tor 0.3.4.8 is leaking memory
-+-
 Reporter:  anong|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Critical | Resolution:
 Keywords:  regression? memleak oom  |  Actual Points:
  034-backport tor-relay 035-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by torkit):

 I've tested the proposed patch that has been merged into maint-0.3.4
 branch and do have the same behavior as before. tor keeps getting killed.
 I'll check 0.3.3 for regression now.

 [[https://trac.torproject.org/projects/tor/attachment/ticket/27813/tor-
 sockstats.png()]]

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

Re: [tor-bugs] #27813 [Core Tor/Tor]: Tor 0.3.4.8 is leaking memory

[Tor Bug Tracker & Wiki]

#27813: Tor 0.3.4.8 is leaking memory
-+-
 Reporter:  anong|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Critical | Resolution:
 Keywords:  regression? memleak oom  |  Actual Points:
  034-backport tor-relay 035-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by torkit):

 * Attachment "tor-sockstats.png" added.

 tor sockstats with proposed patch applied

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

Re: [tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users

[Tor Bug Tracker & Wiki]

#11966: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for 
bridge
users
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, sponsor8-maybe,  |  Actual Points:
  bootstrap, 033-triage-20180320,|
  033-removed-20180320   |
Parent ID:  #28018   | Points:  1
 Reviewer:  arma |Sponsor:
 |  Sponsor8-can
-+-

Comment (by catalyst):

 #27308 is the more general case of this kind of problem.

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

Re: [tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users

[Tor Bug Tracker & Wiki]

#11966: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for 
bridge
users
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, sponsor8-maybe,  |  Actual Points:
  bootstrap, 033-triage-20180320,|
  033-removed-20180320   |
Parent ID:  #28018   | Points:  1
 Reviewer:  arma |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * parent:  #25502 => #28018


Comment:

 Replying to [comment:41 nickm]:
 > If we do this, I think it falls under #25502 ?  Apparently there is code
 here that we might be able to use.
 The bug11966 branch seems to be about bootstrap reporting, so this
 probably belongs under #28018.

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

Re: [tor-bugs] #28151 [Internal Services/Service - sandstorm]: sandstorm: should never happen: anonymous, but no token either.

[Tor Bug Tracker & Wiki]

#28151: sandstorm: should never happen: anonymous, but no token either.
-+-
 Reporter:  traumschule  |  Owner:  hiro
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  sandstorm  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by traumschule):

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


Comment:

 Yes, reported it upstream and propose to leave it open until it's closed
 there:
 https://github.com/sandstorm-io/sandstorm/issues/3098

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

Re: [tor-bugs] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:2 arma]:
 > Also rotating all the intro points will mess up clients that have the
 existing descriptor (and intro points) cached, right? Imagine an onion
 service with a pile of clients who are authorized to reach it, but that
 keeps rearranging its set of acceptable clients, in an automated way, due
 to some policy it has. If it keeps shifting its intro points at each
 change, it could really undermine its reachability.

 Yes and this becomes even more annoying if we close all RP circuits
 (because service doesn't know which circuit is which client) every time a
 client is *removed* from the configuration...

 But I still think that there has to be some assumption from an operator
 that once the client auth has been removed, after the HUP, that client CAN
 NOT have access to the service. Equivalent of a tor restart basically.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28278 [Applications]: Connect to tor

[Tor Bug Tracker & Wiki]

#28278: Connect to tor
+--
 Reporter:  rth456  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Component:  Applications
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Hello,

 I have downloaded various versions of the Tor browser, including,
 Tor 8.0.1
 Tor 8.0.3
 as well the alternative 8.5a

 I receive this message each time I open the file...

 ''Tor unexpectedly exited. This might be due to a bug in Tor itself,
 another program on your system, or faulty hardware. Until you restart Tor,
 the Tor Browser will not able to reach any websites. If the problem
 persists, please send a copy of your Tor Log to the support team'

 "Restarting Tor will not close your browser tabs"

 The notification then gives me the option to either, 'Restart Tor', 'Quit'
 and 'Copy Tor Log To Clipboard'.

 In addition, I have also uninstalled each .dmg file and reinstalled and
 each time I received the same message. As of November 1, 2018, Tor is the
 only browser that I do not have. Tor is also the only browser that I am
 having difficulties with. I do not know how to proceed with the
 installation. Will there be any updated version of Tor coming to release
 soon? Or is this an issue that can be looked be into and fixed with an
 update?

 Looking forward to your response.

 Warmly,

 Roderick T Harris
 roderickhar...@live.com
 troderic...@gmail.com

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

Re: [tor-bugs] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Also rotating all the intro points will mess up clients that have the
 existing descriptor (and intro points) cached, right? Imagine an onion
 service with a pile of clients who are authorized to reach it, but that
 keeps rearranging its set of acceptable clients, in an automated way, due
 to some policy it has. If it keeps shifting its intro points at each
 change, it could really undermine its reachability.

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar** - Done

 **2.1.2 Showing Security Slider State**

 Since the shield icon is being used by Firefox for the Content Blocking
 feature, I made a new one for the Tor Security Settings.
 I think is better if when users click to the icon, they go directly to
 `about:preferences#security` page.

 Both Safer and Safest levels will have the firefox violet active color
 once active.
 Both Safer and Safest levels will have permissions per-site.

 **2.1.2.X Change Security Level and Reload to Apply Changes**

 As we discussed, once a user changes the security level Tor Browser needs
 to reload to apply changes. The safest way to do it is loading a new
 identity.

 **2.1.3 Reorganizing the Toolbar - Done**

 **2.2 Dealing with Per-Site Security Settings**

 Safer level will allow enabling javascript per session.
 Safest level will allow enabling javascript and active content per
 session.

 **3.x Restore Default Security Settings**

 When a user wants to have the global Security Settings back to default, it
 will click at "Restore to defaults" in about:preferences#security and a
 prompt will appear to confirm the Restart with a new identity.

 When a user wants to have their current per-site Preference back to
 default (nothing allowed), it can use the [x] at the control center, and a
 message will appear, as current firefox, "You may need to reload to apply
 changes."

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---
Changes (by antonela):

 * Attachment "25658 - 8.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] #28151 [Internal Services/Service - sandstorm]: sandstorm: should never happen: anonymous, but no token either.

[Tor Bug Tracker & Wiki]

#28151: sandstorm: should never happen: anonymous, but no token either.
-+-
 Reporter:  traumschule  |  Owner:  hiro
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  sandstorm  |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by hiro):

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


Comment:

 Hi,
 I get it now. This might be some JS bug sandstorm 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] #27820 [Webpages/Website]: Explain the different approaches to onionify a website

[Tor Bug Tracker & Wiki]

#27820: Explain the different approaches to onionify a website
--+-
 Reporter:  traumschule   |  Owner:  hiro
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:  #21952| Points:
 Reviewer:|Sponsor:
--+-
Changes (by hiro):

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


Comment:

 Hi,
 This information will be consolidated in the dev portal.

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

Re: [tor-bugs] #27833 [Webpages/Website]: Explain more why not to use other browsers with tor

[Tor Bug Tracker & Wiki]

#27833: Explain more why not to use other browsers with tor
--+-
 Reporter:  traumschule   |  Owner:  hiro
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  faq   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by hiro):

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


Comment:

 Hi,
 afaik we are consolidating all this information from the faq in the
 support portal plus lately the developer portal.

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

Re: [tor-bugs] #27911 [Internal Services/Service - trac]: be able to check a report on trac

[Tor Bug Tracker & Wiki]

#27911: be able to check a report on trac
--+
 Reporter:  gaba  |  Owner:  hiro
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


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

Re: [tor-bugs] #27998 [Community/Mirrors]: Find automatic solution to run the mirror script

[Tor Bug Tracker & Wiki]

#27998: Find automatic solution to run the mirror script
---+-
 Reporter:  traumschule|  Owner:  hiro
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Mirrors  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID:  #22182 | Points:
 Reviewer: |Sponsor:
---+-
Changes (by hiro):

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


Comment:

 Hi,
 after having discussed this for a while, we prefer not to automate the
 mirror process too much at the moment.
 Will reopen if we change our mind 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] #28151 [Internal Services/Service - sandstorm]: sandstorm: should never happen: anonymous, but no token either.

[Tor Bug Tracker & Wiki]

#28151: sandstorm: should never happen: anonymous, but no token either.
-+-
 Reporter:  traumschule  |  Owner:  hiro
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  sandstorm  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by traumschule):

 Replying to [comment:1 hiro]:
 > I do not quite understand. It's your token that sandstorm is giving you.
 Why is that an issue? Unless you are implying something else I cannot
 understand.
 Hi Hiro! {{{should never happen}}} sounds like the developer decided it is
 a bug, when this point is reached. Obviously there is a token but it is
 not recognized.

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

Re: [tor-bugs] #28151 [Internal Services/Service - sandstorm]: sandstorm: should never happen: anonymous, but no token either.

[Tor Bug Tracker & Wiki]

#28151: sandstorm: should never happen: anonymous, but no token either.
-+-
 Reporter:  traumschule  |  Owner:  hiro
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  sandstorm  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by hiro):

 * status:  new => needs_information


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

Re: [tor-bugs] #28151 [Internal Services/Service - sandstorm]: sandstorm: should never happen: anonymous, but no token either.

[Tor Bug Tracker & Wiki]

#28151: sandstorm: should never happen: anonymous, but no token either.
---+--
 Reporter:  traumschule|  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - sandstorm  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 Hi Traumschule,
 I do not quite understand. It's your token that sandstorm is giving you.
 Why is that an issue? Unless you are implying something else I cannot
 understand.
 -hiro

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

Re: [tor-bugs] #27104 [Core Tor/Tor]: report intermediate status when building application circuits

[Tor Bug Tracker & Wiki]

#27104: report intermediate status when building application circuits
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * type:  defect => enhancement


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

Re: [tor-bugs] #27103 [Core Tor/Tor]: report initial OR_CONN as the earliest boostrap phases

[Tor Bug Tracker & Wiki]

#27103: report initial OR_CONN as the earliest boostrap phases
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap, s8-errors|
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * type:  defect => enhancement


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

Re: [tor-bugs] #27102 [Core Tor/Tor]: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum values

[Tor Bug Tracker & Wiki]

#27102: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum values
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * type:  defect => enhancement


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

Re: [tor-bugs] #27167 [Core Tor/Tor]: track "first" OR_CONN

[Tor Bug Tracker & Wiki]

#27167: track "first" OR_CONN
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap, 035-deferred-20180930,   |
  s8-errors  |
Parent ID:  #27103   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * type:  task => enhancement


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

Re: [tor-bugs] #27691 [Core Tor/Tor]: reset bootstrap progress when enough things change

[Tor Bug Tracker & Wiki]

#27691: reset bootstrap progress when enough things change
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-master, 035-triaged-in-20180711,   |
  s8-bootstrap, 035-deferred-20180930|
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by catalyst):

 * type:  defect => enhancement


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

Re: [tor-bugs] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
---+--
 Reporter:  antonela   |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  sstevenson, steph  |Sponsor:
---+--
Changes (by steph):

 * cc: steph (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] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
---+--
 Reporter:  antonela   |  Owner:  hiro
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  sstevenson, steph  |Sponsor:
---+--
Changes (by steph):

 * reviewer:  sstevenson, stephw => sstevenson, steph


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

Re: [tor-bugs] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
+--
 Reporter:  antonela|  Owner:  hiro
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Webpages|Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  sstevenson, stephw  |Sponsor:
+--

Comment (by steph):

 We're hoping to make the banner stand out more.

 What do you think about trying mostly green and black with possibly small
 dabs of other colors? Are there shades that would work well with the style
 guide? We're wondering if that color scheme stood out more last year. I
 did a couple of very rough tests: https://share.riseup.net/#oo7F5D-
 68ys2jItF7sKvGw

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

Re: [tor-bugs] #28263 [Webpages/Website]: Update "Android" Experimental Tor Browser verion

[Tor Bug Tracker & Wiki]

#28263: Update "Android" Experimental Tor Browser verion
--+-
 Reporter:  sysrqb|  Owner:  hiro
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by hiro):

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


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

Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

[Tor Bug Tracker & Wiki]

#28181: spec: Add to pt-spec.txt control messages going back to main process 
(tor)
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 036-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by dgoulet):

 Then we should simply go with `LOG ` and ONLY in the PT 1.0 spec for
 now... I would prefer the PT 2.0 community to cherry pick this if they
 want and maybe improve but at least have a better discussion/analysis of
 this feature.

 It seems, without much more work, we can't really come up with a simple
 format that will apply to all current and future PTs. And, as you mention,
 the `level` is quite "Tor specific" and we (ahf and I) think it is a bad
 idea to require an PT to have knowledge of the tor's log level.

 The `` should be PT specific that is the format is decided by the PT
 itself like obfs4 might decide to have one format and meek another.

 In other words, for logging (which is what LOG is), Tor shouldn't care
 about the content of `` and simply log it at INFO level and send it
 to the control port with something like `PT_LOG  ` event
 (Tor knows what is the transport internally).

 I believe you are also right that we are not fixing the "connection issue"
 and thus should go with the SOCKS event instead.

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

Re: [tor-bugs] #28147 [Applications/Tor Browser]: [meta] Improve Tor Browser Content Process Sandbox

[Tor Bug Tracker & Wiki]

#28147: [meta] Improve Tor Browser Content Process Sandbox
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28146| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Replying to [comment:1 gk]:
 > Are there corresponding Mozilla bugs somewhere because it seems to me
 that this sandbox tightening is something (privacy-conscious) Firefox
 users (with proxy) would maybe want to have as well? E.g. should there be
 no way to steal Android device information that way from within the
 content process regardless of whether Tor is used or not.

 Generally, no.  So far all of the things I've listed here are things we've
 made to support some feature of another. It's possible (but unlikely) that
 they could be dead code that we could remove, but AFAIK there are no
 corresponding Mozilla bugs to do what Tor wants, because it's going to
 conflict with what Mozilla wants.

 My suggestion would be that as each sub-item is investigated, we see what
 the use of the item is in Firefox, and determine if there is a way to
 tighten the IPC layer in Firefox either generally or under certain
 (existing) preferences.  (With a fallback to some new preference or
 preferences.)  That would be the easiest way to upstream the behavior Tor
 wants.

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

Re: [tor-bugs] #27601 [Applications/Tor Browser]: growl a-like browser notifications are not working anymore on macOS with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27601: growl a-like browser notifications are not working anymore on macOS with
Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201810|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 This probably seems related to the permissions patch because I don't have
 any problem with it on Nightly with FPI enabled.

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

Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

[Tor Bug Tracker & Wiki]

#28181: spec: Add to pt-spec.txt control messages going back to main process 
(tor)
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 036-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by ahf):

 * cc: ahf (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] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
+--
 Reporter:  antonela|  Owner:  hiro
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Webpages|Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  sstevenson, stephw  |Sponsor:
+--

Comment (by antonela):

 sstevenson asked for:
 - removing the illustration
 - having a green button as a call to action

 
https://trac.torproject.org/projects/tor/attachment/ticket/28277/tpo.org%20-%20YE%20-%20strong%20-%20light%20-%20iteration2.png

 Once it gets approved, hiro will implement it.

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

Re: [tor-bugs] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
+--
 Reporter:  antonela|  Owner:  hiro
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Webpages|Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  sstevenson, stephw  |Sponsor:
+--
Changes (by antonela):

 * Attachment "tpo.org - YE - strong - light - iteration2.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] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
+--
 Reporter:  antonela|  Owner:  hiro
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Webpages|Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  sstevenson, stephw  |Sponsor:
+--
Changes (by antonela):

 * cc: sstevenson (added)
 * reviewer:   => sstevenson, stephw


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28277 [Webpages]: 2018 donation banner at torproject.org

[Tor Bug Tracker & Wiki]

#28277: 2018 donation banner at torproject.org
--+--
 Reporter:  antonela  |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This ticket is for stakeholders signing and for implementation track.

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

Re: [tor-bugs] #28253 [Webpages/Website]: Add Mozilla logo at Donate Button

[Tor Bug Tracker & Wiki]

#28253: Add Mozilla logo at Donate Button
--+-
 Reporter:  antonela  |  Owner:  hiro
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by hiro):

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


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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
---+---
 Reporter:  isabela|  Owner:  antonela
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor17
---+---

Comment (by antonela):

 Replying to gk:

 > Well, New Identity means that tabs won't reload: the browser will close
 and reopen as a blank slate. But, yes, we should provide that option with
 a similar wording.

 I that case "Restart to apply changes" is the safest suggestion we can do.

 > Well, as I said I am not clinging to the slider element, if we think we
 can transport our ideas better with, say, bullets as outlined in your
 prototype that's fine with me. One thing we should think about, though, is
 the amount of space our redesign should occupy. It seems to me the
 (horizontal) slider has some benefits here but I am sure we could come up
 with a similar "small" proposal if bullets are used instead (e.g. by
 collapsing text of security levels not being used currently).

 Cool. I think the radio button options will work better at the preferences
 section. Yes, we can collapse the details in the future.

 > Works for me. We could think about as well showing little icons directly
 in the URL bar but I am not sure how much energy and time we should spend
 on the per-site security settings anyway. My feeling is not so much,
 especially compared to making the overall experience better.[...] Yes,
 that would be one place. But as I said above, maybe URL bar icons would be
 smart as well? Or maybe we should not spend time optimizing for that
 corner case?

 Ok. I made a mockup for it. If we want to have the same userflow the Block
 Content feature have, then we will need an icon for "Javascript" and
 "Active Content." I'm using the permissions icon at the URL bar now to
 show that some permission have been granted. Two icons are not too much.
 Firefox has this scenario when you block the microphone and the camera at
 the same time, for example.

 > We still need to work on informing users that NoScript and
 HTTSEverywhere icons are available to be placed at the Top Nav via
 Menu/Customize. We could include a step/card explaining it at the new
 onboarding.

 Yep. Once the previous items are ready and approved, I'll move to the
 onboarding card.

 > Also, current about:preferences at FF60 doesn't have a [SAVE] button to
 confirm the action. Do you think we need to add an intermediate step for
 users to verify their radio option pick? May we need it for anything else?

 Yes, we need users to confirm the Restart to apply changes.

 > There is actually another item brought up in comment:29 to rename what
 we have to "Feature filter" while we are at it.

 I agree with roger about the behavior of the tool. But, I don't think this
 renaming improves user comprehension on what is happening.

 > One final thought: What do we do in the new design once a user flips a
 preference that is governed by our security controls essentially kicking
 themselves off that security level to something custom? Right now our UI
 gives the hint with the option to restore the default state. It seems to
 me we should keep that in the new UI as well.

 Yes, the next comment includes a 3.X section that contemplates that user
 story. Both, global and per-site settings.

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

Re: [tor-bugs] #27840 [Metrics/ExoneraTor]: Update translations

[Tor Bug Tracker & Wiki]

#27840: Update translations
+---
 Reporter:  irl |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 We discussed this in Mexico City: we'd like to have translations reviewed
 by Tor people before we merge them. And we should prioritize translations
 with the most impact for relay operators.

 Which translations can we get reviewed that would have enough impact to
 get the update process started?

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

Re: [tor-bugs] #28077 [Core Tor/Tor]: remove unsafe block from cstr! macro

[Tor Bug Tracker & Wiki]

#28077: remove unsafe block from cstr! macro
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 The Rust nightly Travis builder fails with:

 {{{
 error: toolchain 'nightly' is not installed
 }}}

 But all the other Travis builders are green, and the code looks good, so I
 think this is safe to get in.

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

Re: [tor-bugs] #27963 [Core Tor/Tor]: Undefined symbol: "timeradd", first referenced in src/lib/libtor-thread.a

[Tor Bug Tracker & Wiki]

#27963: Undefined symbol: "timeradd", first referenced in 
src/lib/libtor-thread.a
-+-
 Reporter:  Knut |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.2-alpha
 Severity:  Major| Resolution:
 Keywords:  undefined symbole timeradd   |  Actual Points:
  regression |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Nick, your changes in https://github.com/torproject/tor/pull/391  looks
 good, but it looks like Travis is unhappy with them for one of the
 builders, but that seems related to the rebinding test script which is
 entirely unrelated to this.

 I think this should be safe to get in.

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

[tor-bugs] #28276 [Metrics/Ideas]: towards an Exception Reports framework

[Tor Bug Tracker & Wiki]

#28276: towards an Exception Reports framework
-+---
 Reporter:  gman999  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Metrics/Ideas
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
 Currently, there's a number of pulse-checks of the network and its
 components  conducted. IRL's tickets #24070, #24071, #24073 raise a few
 more.

 However, I think we have to step back and start looking at an organized
 framework on this.

 Exception reports are basically overviews about significant changes in
 some routine/activity. We determine some baseline, say, the consensus
 weight of each bandwidth authorities, and note if there's a drastic
 change, maybe daily or twice-a-day, then notify the relevant parties.

 The basics would be this:

 * we determine the areas to address, such as public relays, exits-only,
 dirauths, bwauths, bridges, censorship, guards, etc.

 * we determine metrics we need to see, eg, changes in CW, bandwidth
 advertised, versions, TTL... and determine a baseline, maybe within a
 standard deviation or so.

 * then we figure out who needs to know when something is outside the
 baseline range.

 * we could also develop some automated or human-driven 'next-steps', eg,
 Call X bwauth and tell them to ping their upstream, file a track ticket,
 email some alias@ of people.

 * Another more interesting direction, yet vital, would be to incorporate
 the OONI data, which would be a much better detailed baseline of network
 health.

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

Re: [tor-bugs] #28077 [Core Tor/Tor]: remove unsafe block from cstr! macro

[Tor Bug Tracker & Wiki]

#28077: remove unsafe block from cstr! macro
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+

Comment (by ahf):

 The way I read the `default()` implementation for `CStr` is that it is:

 {{{
 #[stable(feature = "cstr_default", since = "1.10.0")]
 impl<'a> Default for &'a CStr {
 fn default() -> &'a CStr {
 const SLICE: &'static [c_char] = &[0];
 unsafe { CStr::from_ptr(SLICE.as_ptr()) }
 }
 }
 }}}

 Which seems to be what we are doing too, which means that to me it seems
 sensible to use the `unwrap_or_default()` method.

 Opened a PR to see what Travis says:
 https://github.com/torproject/tor/pull/466

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

Re: [tor-bugs] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  security, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by haxxpop):

 Since we cannot close only some RP circuits, we need to close all RP
 circuits or not close them at all.

 If we close all the circuits, all the clients will know that torrc is
 reloaded.
 If we don't close them at all, we don't have a real client revocation.

 Another option is to have a torrc option to let the service owners decide
 by themselves.

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

Re: [tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users

[Tor Bug Tracker & Wiki]

#11966: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for 
bridge
users
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, sponsor8-maybe,  |  Actual Points:
  bootstrap, 033-triage-20180320,|
  033-removed-20180320   |
Parent ID:  #25502   | Points:  1
 Reviewer:  arma |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  assigned => needs_revision


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

Re: [tor-bugs] #11966 [Core Tor/Tor]: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users

[Tor Bug Tracker & Wiki]

#11966: "Bootstrapped 20%: Asking for networkstatus consensus" is a lie for 
bridge
users
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, sponsor8-maybe,  |  Actual Points:
  bootstrap, 033-triage-20180320,|
  033-removed-20180320   |
Parent ID:  #25502   | Points:  1
 Reviewer:  arma |Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  needs_revision => assigned
 * cc: isis (removed)
 * cc: ahf, dgoulet (added)
 * owner:  isis => (none)
 * parent:   => #25502
 * milestone:  Tor: unspecified => Tor: 0.3.6.x-final


Comment:

 If we do this, I think it falls under #25502 ?  Apparently there is code
 here that we might be able to use.

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

Re: [tor-bugs] #26398 [Core Tor/Tor]: feature gate testing C code from Rust for now

[Tor Bug Tracker & Wiki]

#26398: feature gate testing C code from Rust for now
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.3.1-alpha
 Severity:  Normal| Resolution:  wontfix
 Keywords:  rust, tor-test, fast-fix, tor-ci  |  Actual Points:
Parent ID:  #25386| Points:  1
 Reviewer:  nickm |Sponsor:
  |  Sponsor8-can
--+
Changes (by nickm):

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


Comment:

 Now that we have alex's fixes, we don't need to make this change.

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

Re: [tor-bugs] #28184 [Core Tor/Tor]: Reload is additive with regards to new v3 HS client authorizations but it won't subtract deleted ones

[Tor Bug Tracker & Wiki]

#28184: Reload is additive with regards to new v3 HS client authorizations but 
it
won't subtract deleted ones
--+
 Reporter:  jchevali  |  Owner:  haxxpop
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by haxxpop):

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


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

Re: [tor-bugs] #27620 [Core Tor/Tor]: Use trunnel to parse and generate SOCKS wire format in tor-resolve

[Tor Bug Tracker & Wiki]

#27620: Use trunnel to parse and generate SOCKS wire format in tor-resolve
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat socks tor-|  Actual Points:
  resolve security   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm;

 (Needs autosquash)

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

Re: [tor-bugs] #27380 [Core Tor/Tor]: require torrc to be UTF-8

[Tor Bug Tracker & Wiki]

#27380: require torrc to be UTF-8
-+
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285  |  Actual Points:
Parent ID:  #24033   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:15 teor]:
 > Do you want to downgrade this error to a warning that the torrc may not
 work with future tor versions?

 This is a good idea. We can notify the user and tell them that UTF-8 is
 desirable and will get quite important in future versions.

 I pushed a fixup commit in `ticket27380_036_01`.
 See the PR: ​https://github.com/torproject/tor/pull/459

 Simply warning with a longer message and then continuing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28275 [Core Tor/Tor]: hs-v3: Rotate intro points and close RP circuits when removing client auth service side

[Tor Bug Tracker & Wiki]

#28275: hs-v3: Rotate intro points and close RP circuits when removing client 
auth
service side
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal|   Keywords:  security, tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On the service side (only), when a client authorization is removed and
 then tor is HUP, right now the service notices that and re-upload a new
 descriptor containing that new auth.

 However, the into points are most likely kept as is (if no normal rotation
 happened during re-build) which means that a revoked client can still
 access the service with their cached descriptor because the intro points
 are still valid...

 Furthermore, the RP circuits for that client aren't closed.

 Security wise, that is not ideal to have a "not really revoked client" ;).
 Fortunately, only applies to 0.3.5.1-alpha and onward so no need for a
 TROVE.

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

Re: [tor-bugs] #28184 [Core Tor/Tor]: Reload is additive with regards to new v3 HS client authorizations but it won't subtract deleted ones

[Tor Bug Tracker & Wiki]

#28184: Reload is additive with regards to new v3 HS client authorizations but 
it
won't subtract deleted ones
--+
 Reporter:  jchevali  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * milestone:  Tor: 0.3.5.x-final => Tor: unspecified


Comment:

 Oh also, cleaning up the descriptor client side seems wise choice 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

[tor-bugs] #28274 [Obfuscation/Obfsproxy]: Obfs4 Bridges Don't Working (W7 Working, Tails not working)

[Tor Bug Tracker & Wiki]

#28274: Obfs4 Bridges Don't Working (W7 Working, Tails not working)
--+---
 Reporter:  dalavere  |  Owner:  asn
 Type:  defect| Status:  new
 Priority:  Immediate |  Component:  Obfuscation/Obfsproxy
  Version:  Tor: 0.3.4.8  |   Severity:  Critical
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 Dear Tor Project Family,

 I am so sorry because of i opened two (2) tickets and i spelled TOR and i
 am fixing it in this ticket. I saw this post and thought i need to edit.

 Hope you are fine. I am living in Turkey and as you know in my country Tor
 is blocked. I am using Obfs4 bridges in Windows 7 and it is working. I was
 using Obfs4 bridges in Tails since yesterday. But today i can not connect
 Tor network via Tails with Obfs4 bridges. I am stuck at Establishing
 enrypted connection %10. I examined on the internet and my opinion is my
 ISP is blocking Tor bridge traffics but on the other hand Obfs4 bridges
 are working on Windows. I am confused and need your help. Let me explain
 what was i am doing everyday. I was connecting Tor with Windows and it
 automatically takes Obfs4 bridges and saving "torrc" file. I am taking
 them, pasting a text file and transfer with USB to the Tails and pasting
 in the "Tor is censored in my country" section and it was working but
 today i can not connect with Tails.

 Also i sent e-mail to help@… but i received return e-mail titled "Ticket
 creation failed". I didn't understand.

 Could you please help me about this issue? Because i love Tor, i love
 privacy, i love you..

 Thanks in advance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28273 [Obfuscation/Obfsproxy]: Obfs4 Bridges Don't Working (W7 Working, Tails not working)

[Tor Bug Tracker & Wiki]

#28273: Obfs4 Bridges Don't Working (W7 Working, Tails not working)
--+---
 Reporter:  dalavere  |  Owner:  asn
 Type:  defect| Status:  new
 Priority:  Immediate |  Component:  Obfuscation/Obfsproxy
  Version:  Tor: 0.3.4.8  |   Severity:  Critical
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 Dear Tor Project Family,

 I created a ticket #28272 but i couldn't see when i click View Tickets and
 i opened a new one.

 Hope you are fine. I am living in Turkey and as you know in my country TOR
 is blocked. I am using Obfs4 bridges in Windows 7 and it is working. I was
 using Obfs4 bridges in Tails since yesterday. But today i can not connect
 TOR network via Tails with Obfs4 bridges. I am stuck at Establishing
 enrypted connection %10. I examined on the internet and my opinion is my
 ISP is blocking TOR bridge traffics but on the other hand Obfs4 bridges
 are working on Windows. I am confused and need your help. Let me explain
 what was i am doing everyday. I was connecting TOR with Windows and it
 automatically takes Obfs4 bridges and saving "torrc" file. I am taking
 them, pasting a text file and transfer with USB to the Tails and pasting
 in the "Tor is censored in my country" section and it was working but
 today i can not connect with Tails.

 Also i sent e-mail to help@… but i received return e-mail titled "Ticket
 creation failed". I didn't understand.

 Could you please help me about this issue? Because i love TOR, i love
 privacy, i love you..

 Thanks in advance.

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

Re: [tor-bugs] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

#28229: Possible race condition opening SOCKS Port in test_rebind.py
--+
 Reporter:  teor  |  Owner:  rl1987
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by rl1987):

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


Comment:

 Will try to look into this in next few days.

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

Re: [tor-bugs] #27325 [Core Tor/Tor]: Rework NETINFO cell parsing and generation with trunnel

[Tor Bug Tracker & Wiki]

#27325: Rework NETINFO cell parsing and generation with trunnel
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat heartbleed-   |  Actual Points:
  safety security parsing|
Parent ID:  #27143   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_information


Comment:

 Replying to [comment:8 dgoulet]:
 > This is my main worry right now:
 https://github.com/torproject/tor/pull/370#pullrequestreview-167479209
 >

 In RELAY_RESOLVED there's also TTL value, which NETINFO does not have. I
 suppose we could define an object consisting of type-length-value sequence
 and use it in both cells. That would require to either: 1) Implement file
 include feature in trunnel (AFAIK it doesn't support that) or 2) have both
 RELAY_RESOLVED and NETINFO cells defined in the same trunnel file (e.g.
 cells.trunnel or handshake.trunnel or something).

 Or we could explicitly decouple wire formats of the two cells and decide
 that they are independently defined. RELAY_RESOLVED addresses can have one
 of the five types (hostname, IPv4, IPv6, transient error, non-transient
 error), but does the same apply for NETINFO? Does it make sense to ever
 send hostname in NETINFO cell during handshake? Error conditions can
 always happen, but does Tor protocol specify a way to signal them when
 NETINFO cell is needed?

 My code takes second path, but I think we need to take a step back and do
 a little bit of design work here and possibly a patch to tor-spec
 regarding how addresses are represented in Tor cells and whether or not
 there is/should be a dependency between common part of wire format in
 different cells.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28272 [Obfuscation/Obfsproxy]: Obfs4 Bridges Don't Working (W7 Working, Tails not working)

[Tor Bug Tracker & Wiki]

#28272: Obfs4 Bridges Don't Working (W7 Working, Tails not working)
--+---
 Reporter:  dalavere  |  Owner:  asn
 Type:  defect| Status:  new
 Priority:  High  |  Component:  Obfuscation/Obfsproxy
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 Dear Tor Project Family,

 Hope you are fine. I am living in Turkey and as you know in my country TOR
 is blocked. I am using Obfs4 bridges in Windows 7 and it is working. I was
 using Obfs4 bridges in Tails since yesterday. But today i can not connect
 TOR network via Tails with Obfs4 bridges. I am stuck at Establishing
 enrypted connection %10. I examined on the internet and my opinion is my
 ISP is blocking TOR bridge traffics but on the other hand Obfs4 bridges
 are working on Windows. I am confused and need your help. Let me explain
 what was i am doing everyday. I was connecting TOR with Windows and it
 automatically takes Obfs4 bridges and saving "torrc" file. I am taking
 them, pasting a text file and transfer with USB to the Tails and pasting
 in the "Tor is censored in my country" section and it was working but
 today i can not connect with Tails.

 Also i sent e-mail to h...@rt.torproject.org but i received return e-mail
 titled "Ticket creation failed". I didn't understand.

 Could you please help me about this issue? Because i love TOR, i love
 privacy, i love you..

 Thanks in advance.

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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24033   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM, but was missing tests for the new `no_bom` function. Other than
 that, looks sane and simple.

 I added some test in my branch `unicode-descriptors-dirauth2`.
 Also check out the PR: https://github.com/torproject/tor/pull/464
 (all new patches should come with a github PR).

 Marking as merge_ready.

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

Re: [tor-bugs] #27707 [Core Tor/Tor]: Improve some v3 onion logs

[Tor Bug Tracker & Wiki]

#27707: Improve some v3 onion logs
--+--
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs easy tor-logs  |  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+--
Changes (by asn):

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


Comment:

 Merged. 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] #27620 [Core Tor/Tor]: Use trunnel to parse and generate SOCKS wire format in tor-resolve

[Tor Bug Tracker & Wiki]

#27620: Use trunnel to parse and generate SOCKS wire format in tor-resolve
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat socks tor-|  Actual Points:
  resolve security   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #27620 [Core Tor/Tor]: Use trunnel to parse and generate SOCKS wire format in tor-resolve

[Tor Bug Tracker & Wiki]

#27620: Use trunnel to parse and generate SOCKS wire format in tor-resolve
-+-
 Reporter:  rl1987   |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  trunnel wireformat socks tor-|  Actual Points:
  resolve security   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by rl1987):

 Fixed in 38390604a7e3215483d4a53d7a18b45f93e76828.

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

Re: [tor-bugs] #28271 [Metrics/Onionperf]: Check OnionPerf instances from Nagios

[Tor Bug Tracker & Wiki]

#28271: Check OnionPerf instances from Nagios
---+--
 Reporter:  irl|  Owner:  irl
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Please let me know when you need a review and whether I should be doing
 that review or rather somebody else.

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

Re: [tor-bugs] #28136 [Metrics/Website]: OnionPerf graph handles missing data on 2018-10-01 in a weird way

[Tor Bug Tracker & Wiki]

#28136: OnionPerf graph handles missing data on 2018-10-01 in a weird way
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Replying to [comment:8 irl]:
 > I think there's still some confusion between the functions. One is
 ensuring that nulls are present, the other is ensuring that nulls are not
 present. This is addressed by the comments but I wonder if they could have
 better names in the future. We shouldn't hold up deploying this though,
 this is looking good.

 Okay. Merged and deployed. Closing. 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] #28267 [Core Tor/sbws]: Update spec version in the bandwidth file header

[Tor Bug Tracker & Wiki]

#28267: Update spec version in the bandwidth file header
---+-
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by juga):

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


Comment:

 Merged

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

Re: [tor-bugs] #28267 [Core Tor/sbws]: Update spec version in the bandwidth file header

[Tor Bug Tracker & Wiki]

#28267: Update spec version in the bandwidth file header
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by juga):

 https://github.com/juga0/sbws/tree/ticket28268_default_directories

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