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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:18 iwakeh]:
 > Test failure:

 Uhm, yes. Please find the fixup commit that I just pushed to the same
 branch. (I changed that test a couple of times, and it looks like it ended
 up being in a mixed state at the end.)

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

Re: [tor-bugs] #18691 [Applications/Tor Browser]: Switch rbm VMs for Windows to those used for our macOS cross-builds

[Tor Bug Tracker & Wiki]

#18691: Switch rbm VMs for Windows to those used for our macOS cross-builds
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201801  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 FWIW: my plan is to upgrade both binutils and GCC for the switch to ESR
 60, so if some of that helps with this bug, feel free to do changes during
 work on this bug that would benefit #16472 and #20301/#20302. There's a
 trade-off here, though: this bug is much more urgent as Canonical might
 plug the cable for Precise, which is EOL for a while now, any day. So, we
 should not get delayed here by issues popping up when solving #16472 and
 #20301.

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

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

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by iwakeh):

 Ah, tests work now; continuing review, 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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---
Changes (by Vort):

 * Attachment "tor_windows_upload_fix_v4.patch" added.


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

Re: [tor-bugs] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by Vort):

 Patch is updated to match 0.3.2.9 code.

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

Re: [tor-bugs] #24812 [Webpages/Website]: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists only two

[Tor Bug Tracker & Wiki]

#24812: Tor: T-shirt website says there are 3 ways to get a t-shirt but lists 
only
two
--+
 Reporter:  cypherpunks   |  Owner:  kat5
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:3 arma]:
 > Merged! Thanks.
 >
 > (I wonder what the third used to be.)
 The 3rd option was.
 {{{A large enough ($65+) donation to the Tor Project."}}}
 
http://web.archive.org/web/2015043419/https://www.torproject.org/getinvolved/tshirt.html

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

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Please find [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-22983-5&id=06e1ea68ae3fef4da93583c736b6bc08c54a2367
 commit 06e1ea6 in my task-22983-5 branch] with a couple of changes to your
 task-22983-4 branch. I hope I didn't break anything. Please check!

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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by karsten):

 * cc: karsten (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] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

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

Comment (by asn):

 OK! Answered the latest comments as well. Seems pretty good.

 I also pushed a small branch `bug23101-squashed-docs` with some small docs
 improvements.

 Perhaps we can proceed with merge request and merge_ready after squashing
 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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 Hi, sorry we missed this, it was in the wrong milestone,
 It should get reviewed in the next few weeks.

 Can you check if the patch applies to master?

 It's at:

 git clone https://git.torproject.org/tor.git

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

Re: [tor-bugs] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+--
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Seems like a duplicate to me: #22867

 Anyway, I have been for the past 4 months reporting URLs that get saved in
 my history https://trac.torproject.org/projects/tor/ticket/22867#comment:2
 (comment 2-3-5-8) if you find that useful to reproduce this issue (mostly
 happens with a clean TB install (I only use alpha) and usually in websites
 that try to launch popups when you click on a link, and sometimes on very
 "innocent" websites like blogspot (comment3), washingtonpost (comment5),
 but it's really difficult to reproduce)

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 All tests and checks pass and code looks ok.

 Shouldn't the new method parameter 'long now' (in various methods) be
 named differently to reflect the meaning of the milliseconds timestamp?
 Maybe 'long lastMeasurementMillis' or similar?

 How will the data be affected when deploying the fix?  The stored data
 timestamps might be more recent than the last seen value used in the new
 code.  Did you run system tests on a local instance?
 This should be clarified before deployment, but the code is merge ready.

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

[tor-bugs] #24869 [Metrics/Relay Search]: Put all map parameters in the URL

[Tor Bug Tracker & Wiki]

#24869: Put all map parameters in the URL
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I would like to be able to link to maps that have "Consensus weight vs
 bandwidth" selected. But I don't know if it's possible. For example,
 https://atlas.torproject.org/#map/flag:Exit shows exits, but if I want
 consensus weight vs bandwidth, I have to take a screenshot.

 If it is not, please provide a way to create a URL that goes straight to
 one of the map options.

 If it is, please make it more discoverable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24870 [Metrics/Onionoo]: Use java 8 date-time functionality in Onionoo

[Tor Bug Tracker & Wiki]

#24870: Use java 8 date-time functionality in Onionoo
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:  metrics-2018
Actual Points:   |  Parent ID:  #23752
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This affects documents and updater code.  The changes should strive to
 shorten existing code, make it more readable, and remove helper constants
 and classes currently used for time conversions/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] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:21 iwakeh]:
 > All tests and checks pass and code looks ok.

 Awesome!

 > Shouldn't the new method parameter 'long now' (in various methods) be
 named differently to reflect the meaning of the milliseconds timestamp?
 Maybe 'long lastMeasurementMillis' or similar?

 Good point. Let's go with `lastSeenMillis` which is what we use in
 `NodeStatus`, too. I'll change that before merging.

 > How will the data be affected when deploying the fix?  The stored data
 timestamps might be more recent than the last seen value used in the new
 code.  Did you run system tests on a local instance?
 > This should be clarified before deployment, but the code is merge ready.

 I'll run another local test before merging. Once that's done, let's
 coordinate deployment as usual.

 Thanks for the 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] #22798 [Core Tor/Tor]: Windows relay is several times slower than Linux relay

[Tor Bug Tracker & Wiki]

#22798: Windows relay is several times slower than Linux relay
---+---
 Reporter:  Vort   |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.11
 Severity:  Normal | Resolution:
 Keywords:  tor-relay performance windows  |  Actual Points:
Parent ID: | Points:  5
 Reviewer: |Sponsor:
---+---

Comment (by Vort):

 Applies and compiles good at
 
[https://gitweb.torproject.org/tor.git/commit/?id=c8c258a4333815e195097a59801397dd7a169828
 c8c258a4].
 Binary was not tested, but it should be fine too.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:267 cypherpunks]:
 > Read the title of this ticket. Sure you can't tie Cloudflare-thing to
 the security slider but you can tie "corporate MITM" to the security
 slider.

 You missed the point entirely, the Security Slider is a way to provide
 vulnerability surface reduction and so including "corporate MiTM" in it
 seems meaningless, https://www.torproject.org/projects/torbrowser/design/

 `In order to provide vulnerability surface reduction for users that need
 high security, we have implemented a "Security Slider" to allow users to
 make a tradeoff between usability and security while minimizing the total
 number of choices (to reduce fingerprinting). Using metrics collected from
 Mozilla's bug tracker, we analyzed the vulnerability counts of core
 components, and used information gathered from a study performed by iSec
 Partners to inform which features should be disabled at which security
 levels.`

 Replying to [comment:268 cypherpunks]:
 > Hey, why Tor Browser can't have one or two checkbox?
 It will make you even more fingerprintable. Imagine a website loading many
 tracking iframes some of whom are behind Cloudflare and get as a result
 blocked, wouldn't that make your fingerprint more unique?

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

Re: [tor-bugs] #24479 [Applications/Tor Browser]: NoScript shouldn't block local HTML5 video and audio files when security slider is set to safer or safest

[Tor Bug Tracker & Wiki]

#24479: NoScript shouldn't block local HTML5 video and audio files when security
slider is set to safer or safest
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 mcs says in #24421:
 > Another idea came to me while I was doing something else: maybe there
 are actually two copies of the NoScript code running, and *that* is
 causing problems. A quick `dump()` added to the end of NoScript's Main.js
 shows it is being loaded twice, but I am not sure if that is by design or
 not.
 could that be related to how when loading local media files in TB with
 Medium-High security setting, not only is the media instantly played, but
 there's in addition a click-to-play?

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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 some affected relays as of 2018-01-11 11:00

 {{{
 
+--+-+--+-+-+
 | nickname | tor_version | fingerprint
 | last_restarted  | running |
 
+--+-+--+-+-+
 | DeltaIV  | 0.3.1.9 |
 75CCC14FB38F2E473AC2C31F255355110FCE8D38 | 2018-01-06 21:01:47 |   0 |
 | TOris| 0.3.1.9 |
 A2888CB01CEAD3BBD84F63707F45318A7A71D141 | 2018-01-08 07:39:07 |   0 |
 | cosmicsurfin | 0.3.1.9 |
 4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05 | 2018-01-08 21:32:15 |   0 |
 | CalyxInstitute01 | 0.3.2.8-rc  |
 E4D1F25DFBE484208866BA4A1A958B73127CB0AD | 2018-01-11 05:56:56 |   1 |
 | k21hermes| 0.2.5.16|
 D01956B555BA59D422D994D41AC9634183974597 | 2018-01-11 07:02:53 |   1 |
 | pix2 | 0.2.5.16|
 3B53BC7A8F3B8917D1A06F85D2A83ECDE5517FA8 | 2018-01-11 07:20:07 |   1 |
 | mycatdied| 0.3.1.9 |
 8B643FE73FEC45EEB1D51B614E64C844C789A09C | 2018-01-11 08:03:20 |   1 |
 
+--+-+--+-+-+
 }}}

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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 Maybe it helps debug (times in UTC):

 grep logs for "cosmicsurfin":
 {{{
 Jan 10 06:54:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 10 08:25:15.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 10 09:56:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 10 11:26:15.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 10 12:57:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 10 14:28:15.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 10 15:59:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 10 17:30:15.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 10 19:01:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 10 20:32:15.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 10 22:03:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 10 23:34:15.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 11 01:05:15.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 11 02:36:16.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 11 04:07:16.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 11 05:38:16.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 11 07:08:16.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 11 08:39:16.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 Jan 11 10:10:16.000 [info] dirserv_add_descriptor(): Added descriptor from
 'cosmicsurfin' (source: 162.243.185.109): Valid server updated.
 Jan 11 11:41:16.000 [info] dirserv_add_descriptor(): Not replacing
 descriptor from $4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05~cosmicsurfin at
 162.243.185.109 (source: 162.243.185.109); differences are cosmetic.
 }}}

 grep logs for "4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05"

 {{{
 Jan 10 06:44:00.000 [info] connection_or_set_identity_digest(): Set
 identity digest for 0x5582f5b221a0 ([scrubbed]):
 4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05
 lqxhXMFy1ZPO7jAwEnFZbn8T2fUF3/Jcfi9ZwaFqg7w.
 Jan 10 06:50:01.000 [info] rep_hist_note_router_unreachable(): Router
 4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05 is still non-Running; it has been
 non-Running since 2018-01-08 04:50:01.
 Jan 10 07:05:20.000 [info] connection_or_set_identity_digest(): Set
 identity digest for 0x5582f6d981b0 ([scrubbed]):
 4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05
 lqxhXMFy1ZPO7jAwEnFZbn8T2fUF3/Jcfi9ZwaFqg7w.
 Jan 10 07:26:40.000 [info] connection_or_set_identity_digest(): Set
 identity digest for 0x5582f5c97010 ([scrubbed]):
 4A0242BED06138AD6BB1FE1

[tor-bugs] #24871 [Applications/Tor Browser]: When trying to make an account in GitBook it always redirects back to the signup page

[Tor Bug Tracker & Wiki]

#24871: When trying to make an account in GitBook it always redirects back to 
the
signup page
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Try to make an account here https://www.gitbook.com/join but it will
 always redirect you back to https://www.gitbook.com/join when you click on
 Create an account

 Looking at the console one sees:

 {{{
 x PJAX error:   vendor.js:23
 x redirect to /join  vendor.js:23
 }}}

 Not sure if this is a bug with TB.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24872 [- Select a component]: remove outdated tor relay security recommendations and update these wiki pages

[Tor Bug Tracker & Wiki]

#24872: remove outdated tor relay security recommendations and update these wiki
pages
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 While working on #24497 I wanted to link to existing security related
 recommendations and found:

 https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity
 https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity

 IMHO these are severely outdated and give bad advises.

 I'm proposing to remove some outdated content and if no one disagrees I'll
 proceed soon.
 I'll send email to tor-dev 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] #24497 [Webpages/Website]: Improve documentation for tor relay operators

[Tor Bug Tracker & Wiki]

#24497: Improve documentation for tor relay operators
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 As mentioned I proceeded with removing the WIP header.

 Alison, could you make the page read-only and writable to the subscribers
 of this trac ticket?

 I thought a bit about maintaining the guide: I'm happy to maintain the
 technical part of the guide but probably just if it can not be changed by
 anyone - since that would (probably) unnecessarily increase the effort
 required to maintain it. (i.e. if someone makes changes to configs)

 I'm aiming to add some security related recommendations or references and
 filed #24872

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

Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch 
for
at least 20s or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22341| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Okay.  If this turns out to be the case, we should add the sha3 module to
 the list of stuff we build without the expensive sanitizer flags.

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

Re: [tor-bugs] #24746 [HTTPS Everywhere/EFF-HTTPS Everywhere]: wizards.com ruleset

[Tor Bug Tracker & Wiki]

#24746: wizards.com ruleset
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Minor| Resolution:  fixed
 Keywords:  httpse-ruleset-bug   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 fixed in 4bae450

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

Re: [tor-bugs] #19058 [HTTPS Everywhere/EFF-HTTPS Everywhere]: IMDB photogalleries inaccesible

[Tor Bug Tracker & Wiki]

#19058: IMDB photogalleries inaccesible
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:  fixed
 Keywords:  imdb |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  new => 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] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 I'd say this is merge ready now.  All tests&checks pass, your changes are
 fine, and the current state of CollecTor's webstats development branch
 works with this metrics-lib version.

 Maybe, wait with the merge to master until the development changes for
 CollecTor are completed in case something needs to be altered here (which
 is very unlikely) or a bug is discovered during CollecTor development?

 Anyway, this is a huge step forward :-)

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

Re: [tor-bugs] #23894 [Webpages]: remove help desk email from bridges.torproject.org

[Tor Bug Tracker & Wiki]

#23894: remove help desk email from bridges.torproject.org
--+
 Reporter:  alison|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * cc: isis, mcs (added)


Comment:

 I happened to notice this ticket on #tor-bots (due to Alison's recent
 comment). Is this a website content issue or a change that needs to be
 made to BridgeDB? Since the ticket has no owner, no one is probably
 working on 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] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_review


Comment:

 I renamed `now` to `lastSeenMillis` in
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-16513-2&id=27794f7a7500783cd4b8f47f857b5e59c3c3fe61
 commit 27794f7], and I realized that we'll have to make similar changes to
 updating status which I did in
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-16513-2&id=7e99b95485529c6a1d22ef7ee0eff841a890a598
 commit 7e99b95]. Please take another look at least at that second commit.

 Right now I'm downloading omeiense's `status/` and `out/` directories and
 will run a local Onionoo server for a few hours, just to be really sure
 that it's doing the right thing.

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

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 Great! Let's squash and merge when CollecTor changes are done. Yay!

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

Re: [tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
--+---
 Reporter:  Eugene646 |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:  cpu, windows  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Eugene646):

 No, there is no pattern. It happens some days and may last from few
 minutes to few hours. Not necessarily at start. There is no reliable way
 of reproducing.

 Maybe I could enable some debug logging or like that?

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

Re: [tor-bugs] #24573 [Core Tor/Tor]: rewrite_node_address_for_bridge() should set IPv6 preferences even if there is no ri

[Tor Bug Tracker & Wiki]

#24573: rewrite_node_address_for_bridge()  should set IPv6 preferences even if
there is no ri
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-bridge-client, easy,   |  Actual Points:
  intro, review-group-28 |
Parent ID:  #20916   | Points:  0.5
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-

Comment (by nickm):

 Merged it this morning.  Please either unparent or close the child ticket
 as appropriate, so we can close 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] #24862 [Metrics/Consensus Health]: Add per-relay tor versions to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay tor versions to the consensus health detailed page
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by Sebastian):

 See #24864 for some dirauth logs (in short, not sure if there is a bug
 after all)

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [comment:4 karsten]:
 > Here's a possibly smarter idea. We add a 6 month history object with a
 data resolution of 1 day. And we skip graphs if the reported data interval
 of even a single data point is higher than the graph interval.

 irl, iwakeh, I'm curious what you think about this idea!

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

Re: [tor-bugs] #24593 [Webpages/Website]: Upload press clips to website

[Tor Bug Tracker & Wiki]

#24593: Upload press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kat5):

 * status:  assigned => 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] #24581 [Core Tor/Tor]: Don't crash when restarting Tor in the same process

[Tor Bug Tracker & Wiki]

#24581: Don't crash when restarting Tor in the same process
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api, review-group-28  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-must
-+-
Changes (by catalyst):

 * reviewer:   => catalyst


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

Re: [tor-bugs] #24572 [Core Tor/Tor]: rewrite_node_address_for_bridge() doesn't set rs IPv6 addresses

[Tor Bug Tracker & Wiki]

#24572: rewrite_node_address_for_bridge() doesn't set rs IPv6 addresses
-+-
 Reporter:  teor |  Owner:
 |  ffmancera
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.5-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, easy, intro, tor-bridge-   |  Actual Points:
  client |
Parent ID:  #24573   | Points:  0.5
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-
Changes (by ffmancera):

 * status:  needs_revision => 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] #24573 [Core Tor/Tor]: rewrite_node_address_for_bridge() should set IPv6 preferences even if there is no ri

[Tor Bug Tracker & Wiki]

#24573: rewrite_node_address_for_bridge()  should set IPv6 preferences even if
there is no ri
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.5-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ipv6, tor-bridge-client, easy,   |  Actual Points:
  intro, review-group-28 |
Parent ID:  #20916   | Points:  0.5
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-
Changes (by ffmancera):

 * status:  merge_ready => 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] #24153 [Metrics/Library]: Make DescriptorCollector resume previously aborted downloads

[Tor Bug Tracker & Wiki]

#24153: Make DescriptorCollector resume previously aborted downloads
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 iwakeh, does the above make sense? (I ran into this once again today while
 testing something.)

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:23 karsten]:
 > I renamed `now` to `lastSeenMillis` in
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-16513-2&id=27794f7a7500783cd4b8f47f857b5e59c3c3fe61
 commit 27794f7], and I realized that we'll have to make similar changes to
 updating status which I did in
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-16513-2&id=7e99b95485529c6a1d22ef7ee0eff841a890a598
 commit 7e99b95]. Please take another look at least at that second commit.

 Good that you thought of this!
 When taking another look at the tests, I'd say it's time to start using
 new DateTime classes.  For example:
 {{{
 diff --git
 a/src/test/java/org/torproject/onionoo/docs/WeightsStatusTest.java
 b/src/test/java/org/torproject/onionoo/docs/WeightsStatusTest.java
 index e28f989..7169aaa 100644
 --- a/src/test/java/org/torproject/onionoo/docs/WeightsStatusTest.java
 +++ b/src/test/java/org/torproject/onionoo/docs/WeightsStatusTest.java
 @@ -9,6 +9,8 @@ import static org.junit.Assert.assertTrue;

  import org.junit.Test;

 +import java.time.ZoneOffset;
 +import java.time.LocalDateTime;
  import java.util.Arrays;
  import java.util.Map;
  import java.util.SortedMap;
 @@ -101,7 +103,8 @@ public class WeightsStatusTest {
  }
  assertEquals("history: ", correctHistory,
 mapToString(ws.getHistory()));
  assertEquals(correctLines.length, ws.getHistory().size());
 -ws.compressHistory(1515670935476L);
 +ws.compressHistory(LocalDateTime.of(2017, 01, 01, 7, 15, 0, 0)
 +.toInstant(ZoneOffset.UTC).toEpochMilli());
  assertEquals("found: " + mapToString(ws.getHistory()), 1,
  ws.getHistory().size());
  assertEquals("[143103240, 143104320] : [-1.0, 1.78279826E-4,
 "
 }}}

 This is a bit longer, but will make the tests more readable and it will be
 immediately obvious what timestamp is used in a test.  Maybe, start at
 least with the newly introduced tests here?


 >
 > Right now I'm downloading omeiense's `status/` and `out/` directories
 and will run a local Onionoo server for a few hours, just to be really
 sure that it's doing the right thing.

 Tests and checks pass.  Ready for merge when the system test succeeds.

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

Re: [tor-bugs] #24861 [Core Tor/Tor]: Using %zu seems to break mingw :/

[Tor Bug Tracker & Wiki]

#24861: Using %zu seems to break mingw :/
+--
 Reporter:  nickm   |  Owner:  ffmancera
 Type:  defect  | Status:  needs_review
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  mingw compatibility regression  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by ffmancera):

 * status:  assigned => needs_review


Comment:

 Patch done but I didn't test it on minGW, so It would be cool if someone
 could test it properly.

 Please check my github [https://github.com/ffmancera/tor/tree/bug24861
 branch bug24861]. I hope everything is fine! :)

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

Re: [tor-bugs] #24584 [Core Tor/Tor]: Fix memory-leaked event_base_once() users.

[Tor Bug Tracker & Wiki]

#24584: Fix memory-leaked event_base_once() users.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-28  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


Comment:

 * For the beauty of well formed C files and to address any OCD issues some
 developers may have, I would add a new line after so it also matches the
 `shutdown_did_not_work_event` syntax. :)

 {{{
 /** Event to run initialize_periodic_events_cb */
 static struct event *initialize_periodic_events_event = NULL;
 }}}

 rest 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] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by karsten):

 Hmm, or should we replace all those milliseconds in the code with Java 8
 date/time constructs all in a single step? I have to admit, I can't
 believe that that's the most elegant way of converting seven numbers into
 one number, yet you may be right. But I'd want to read up on Java 8 things
 first before changing things. (We do have a ticket for that, right?) Happy
 to add a ISO string what the long number means as a comment next to that
 line.

 System tests have not even begun. I'm still working on downloading the
 `status/` directory from omeiense...

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

Re: [tor-bugs] #24153 [Metrics/Library]: Make DescriptorCollector resume previously aborted downloads

[Tor Bug Tracker & Wiki]

#24153: Make DescriptorCollector resume previously aborted downloads
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Yes.  The file should just be written anew no matter if a previous temp
 file existed, b/c that is in an undefined state anyway.  It might also be
 an option to use Files.createTempFile and friends?

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

Re: [tor-bugs] #24153 [Metrics/Library]: Make DescriptorCollector resume previously aborted downloads

[Tor Bug Tracker & Wiki]

#24153: Make DescriptorCollector resume previously aborted downloads
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 `Files.createTempFile` sounds promising! Want to write a patch or a quick
 sketch how that would work here?

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by nickm):

 I think it's okay for us to leave things as they are then with the fixes
 on this ticket above.  STACK-cleanness can be for master.

 GeKo sent me another warning, though: making a _new_ patch for that...

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

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

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by iwakeh):

 There is #24870 for Onionoo's date-time changes.  Just leave the code here
 as is and do all changes together.

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

Re: [tor-bugs] #24581 [Core Tor/Tor]: Don't crash when restarting Tor in the same process

[Tor Bug Tracker & Wiki]

#24581: Don't crash when restarting Tor in the same process
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api, review-group-28  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-must
-+-

Comment (by catalyst):

 The changes look good to me.  If this fix allows restarting in the same
 process where we didn't before, does restarting cause anything dangerous
 to happen with OpenSSL, like PRNG state?  Maybe we could document that
 there might be some security risks with restarting until we track them
 down.

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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 thank you for the logs, could you paste the same kind of data for the
 following relay:
 {{{
  CalyxInstitute01 | 0.3.2.8-rc  | E4D1F25DFBE484208866BA4A1A958B73127CB0AD
 }}}

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

Re: [tor-bugs] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by karsten):

 Replying to [comment:6 teor]:
 > Do you need more developer time, more disk, more CPU, or more RAM?
 > Because we can try to make these things happen.

 So, I wrote a quick hack of an Onionoo that downloads and reads votes in
 addition to all the other descriptors. Here's what I learned:

  - The local descriptor cache without votes is 569M. With votes it's 3.3G.
 That's an increase of 494%!
  - The time to read 3 days of descriptors in the hourly run without votes
 is 10 minutes. With votes it's 16 minutes. That's an increase of 60%. (But
 we typically only read 1 hour of descriptors per hour.)

 So, I'd say we'd need these things to make this happen:
  - Some more disk space on the Onionoo hosts, but not really much more RAM
 or CPUs. (Reading descriptors is still done in a single thread, so reading
 more descriptors simply takes more time.)
  - Some developer time to write a specification patch for this new Onionoo
 feature, an implementation, and tests.
  - Some review time.

 '''teor''': Would you want to work on that specification patch, so that we
 have a better idea what we're supposed to build here?

 If we want to do this properly, we should also resolve a few related
 issues that become a bit more important by adding this feature:
  - Ability to use compression when downloading descriptors from CollecTor
 using metrics-lib (no ticket yet)
  - Ability to process descriptors in parallel using metrics-lib (#21365 is
 related)
  - Ability to handle large descriptor files in metrics-lib (#20395)

 > (Another alternative for #24834 is that we build a quick stem script to
 export the data we need, and import it into Relay Search.)

 For a short-term thing, sure. But long-term this sounds like a maintenance
 nightmare. (After all, Onionoo is the tool to export the data we need and
 import it into Relay Search.)

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by nickm):

 Here's the remaining issue:

 {{{
 bug: anti-dce
 model: |
   sw.default.i:
   %.b.i =3D load i1* @networkstatus_get_flavor_name.warning_logged__, !dbg
 !1116
   br i1 %.b.i, label %if.end.i, label %if.then.i, !dbg !1121, !macro !1123
 stack:
   -
 
/home/thomas/Arbeit/hardening/stack/build36/tor_test/../../../../Tor/tor/src/or/networkstatus.c:2052:34
 ncore: 1
 core:
   -
 
/home/thomas/Arbeit/hardening/stack/build36/tor_test/../../../../Tor/tor/src/or/networkstatus.c:2049:28
 - buffer overflow
 }}}

 and here's the code, with the lines marked.

 {{{
   for (i=0; iconsensus)
   continue;
 if (networkstatus_check_consensus_signature(waiting->consensus, 0)>=0)
 {
   char *waiting_body = waiting->body; // 2049
   if (!networkstatus_set_current_consensus(
  waiting_body,
  networkstatus_get_flavor_name(i), // 2052
  NSSET_WAS_WAITING_FOR_CERTS,
  source_dir)) {
 tor_free(waiting_body);
   }
 }
 }}}

 What's I think is happening here is that the compiler sees that
 `waiting->body` is computed, and so realizes that "i" must be in range 0
 <= i < N_CONSENSUS_FLAVORS.  This could be used to eliminate the assertion
 and default case in networkstatus_get_flavor_name() when it's inlined.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by catalyst):

 * status:  needs_review => merge_ready
 * reviewer:   => catalyst


Comment:

 Looks good to me!  Commit message typo: s/requied/required/

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 The trivial workaround here is to compute the flavor name first as in my
 `stack_em_up` branch.  This doesn't actually change anything or fix
 anything real, so I'm not doing a changes file on 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] #18691 [Applications/Tor Browser]: Switch rbm VMs for Windows to those used for our macOS cross-builds

[Tor Bug Tracker & Wiki]

#18691: Switch rbm VMs for Windows to those used for our macOS cross-builds
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201801  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 I have been thinking about updating binutils to fix the issue, but it
 seems the fix is simple enough to do that separately.

 I have now been able to build the Windows 32 and 64 versions using Debian
 Jessie with the patch in branch `bug_18691_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_18691_v2&id=218dc2a5bffdb2bcadb4552659baf82e0043469c

 The main changes included in this patch are:
 - adding a patch to fix the binutils build
 - updating the libfaketime path
 - installing the wine package from the main jessie repository instead of
 the ubuntu ppa repository, so we are moving from wine 1.7.18 to 1.6.2. We
 could use version 1.8.7 from jessie-backports but it seems version 1.6.2
 is enough.
 - using `wine winepath`, `wine msiexec` and `wine wineboot` instead of
 `winepath`, `msiexec` and `wineboot` as they do not seem to work with this
 version of the wine package.

 I checked that both 32 and 64 bits builds are running correctly. However I
 did not check yet that the build is still reproducible.

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

Re: [tor-bugs] #24641 [Core Tor/Tor]: Simplify "did this option change" functions in config.c

[Tor Bug Tracker & Wiki]

#24641: Simplify "did this option change" functions in config.c
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-28  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

[tor-bugs] #24873 [- Select a component]: unable to open tor browser

[Tor Bug Tracker & Wiki]

#24873: unable to open tor browser
--+
 Reporter:  emperorofwashington   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Getting Window with this error

 Tor exited during startup. This might be due to an error in your torrc
 file, a bug in Tor or another program on your system, or faulty hardware.
 Until you fix the underlying problem and restart Tor, Tor Browser will not
 start.

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

Re: [tor-bugs] #24866 [Applications/Tor Browser]: Tor Browser remembering history for certain URLs even after restart

[Tor Bug Tracker & Wiki]

#24866: Tor Browser remembering history for certain URLs even after restart
--+---
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dcf):

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


Comment:

 Replying to [comment:2 cypherpunks]:
 > Seems like a duplicate to me: #22867

 You're right. I searched for duplicates but didn't find 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] #22867 [Applications/Tor Browser]: Some URLs are saved in the Tor Browser places.sqlite database as part of the browsing history

[Tor Bug Tracker & Wiki]

#22867: Some URLs are saved in the Tor Browser places.sqlite database as part of
the browsing history
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 #24866 is a duplicate. Extra information from that ticket:

 I experienced it with Tor Browser 7.0.11.

 The two URLs being remembered are similar to the ones previously reported:
  *
 !https://accounts.google.com/ServiceLogin?continue=https://www.blogger.com
 /comment-iframe.g[...]
  *
 
!https://id.rlcdn.com/463496.gif?credir=https%3A%2F%2Fsimage4.pubmatic.com%2FAdServer[...]

 The remembered URLs appear also in the ctrl+H history panel. When I open
 it, there are two entries corresponding to the months of the timestamps in
 the `moz_historyvisits` table. However it doesn't list any URLs: if I
 click the expander arrows, the arrows just disappear without expanding
 anything. But if I search for a string like "http", I can make the URLs
 appear.

 [[Image(ticket:24866:history-default.png)]] [[Image(ticket:24866:history-
 search.png)]]

 Ticket #23704 is potentially related; it's about the browser remembering
 tabs after upgrading. comment:3:ticket:23704 says "TBB 7.0.5/6 has
 `places.history.enabled` set to `true` by default. And now TBB 7.5a5 has
 it set to `false` as a non-default value for unknown reason!" For what
 it's worth, my about:config looks like this:
 ||=Preference Name =||=Status =||=Type =||=Value =||
 ||places.history.enabled ||default ||boolean ||true ||
 ||**places.history.expiration.transient_current_max_pages** ||**user set**
 ||**integer** ||**122334** ||

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by catalyst):

 You're saying STACK is warning about the `tor_fragile_assert()` in
 `networkstatus_get_flavor_name()` being eliminated as dead code as a
 consequence of a buffer overflow not occurring when looping over
 N_CONSENSUS_FLAVORS?  Is the problem partly that STACK doesn't see
 `tor_fragile_assert()` as intrinsically unreachable because by default
 it's nonfatal?

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by nickm):

 I honestly can't tell, but the warning is about the warning_logged__
 variable, which does seem to be part of the fragile assert.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by catalyst):

 Do we get this STACK warning if we build with `ALL_BUGS_ARE_FATAL`?  If
 not, I'm inclined to leave it as is and recommend that people run STACK
 with that defined.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by nickm):

 gk, question for you: ^

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

Re: [tor-bugs] #24581 [Core Tor/Tor]: Don't crash when restarting Tor in the same process

[Tor Bug Tracker & Wiki]

#24581: Don't crash when restarting Tor in the same process
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api, review-group-28  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-must
-+-

Comment (by nickm):

 good idea.  I'll add a note about possible security issues, and merge, if
 that's okay with you.  I'll look at PRNG in particular. Can you help me
 brainstorm other things to check for?

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

Re: [tor-bugs] #24584 [Core Tor/Tor]: Fix memory-leaked event_base_once() users.

[Tor Bug Tracker & Wiki]

#24584: Fix memory-leaked event_base_once() users.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  review-group-28  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Added blank line and merging!

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 fixed and squashed and merging; 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] #24641 [Core Tor/Tor]: Simplify "did this option change" functions in config.c

[Tor Bug Tracker & Wiki]

#24641: Simplify "did this option change" functions in config.c
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  review-group-28  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merging!

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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 {{{
 Jan 10 06:27:00.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 06:48:20.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 07:09:41.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 07:31:01.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 07:52:21.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 08:13:42.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 08:35:03.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 08:56:26.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 09:17:47.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 09:39:07.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 10:00:27.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 10:21:47.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 10:43:08.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 11:04:28.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 11:25:48.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 11:47:08.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 12:08:29.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 12:29:49.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 12:51:09.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 13:12:30.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 13:33:50.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 13:55:11.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 14:16:32.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitute01 at 162.247.72.7
 to be reachable at 162.247.72.7:443. Yay.
 Jan 10 14:37:53.000 [info] dirserv_orconn_tls_done(): Found router
 $E4D1F25DFBE484208866BA4A1A958B73127CB0AD~CalyxInstitu

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by cypherpunks):

 thanks for merging!

 Will you backport 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] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by nickm):

 Not planning to: we mostly don't backport documentation.  Maybe to 0.3.2?

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

Re: [tor-bugs] #24581 [Core Tor/Tor]: Don't crash when restarting Tor in the same process

[Tor Bug Tracker & Wiki]

#24581: Don't crash when restarting Tor in the same process
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 |  implemented
 Keywords:  tor-mobile, s8-api, review-group-28  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-must
-+-
Changes (by nickm):

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


Comment:

 merged to master, with an extra commit for openssl as
 42751e2123f6dcc87f3992d38c1889f7da981a7b.  The PRNG wasn't being left
 unseeded or anything, but we _were_ failing to re-seed on restart.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by cypherpunks):

 yes please at least to 0.3.2 :)

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

Re: [tor-bugs] #24833 [Core Tor/Tor]: DNS not reliably returning AAAA records

[Tor Bug Tracker & Wiki]

#24833: DNS not reliably returning  records
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  ipv6 tor-client tor-exit tor-dns  |  Actual Points:
Parent ID:  #21311| Points:
 Reviewer:|Sponsor:
--+

Comment (by Zakhar):

 Yes, it is possibly a duplicate, although this does not "ask as much".
 #21311: asks for  '''always'''.

 It could be perfectly reasonable to have "optimizations" so that when an
 exit knows a client will never need ipv6, not to return any  records.

 But when the client configured it's torrc like that:

 `DNSPort 172.16.0.1:9053 IPv6Traffic`
 `TransPort [fe80::10%vnet0]:9040`
 `ClientUseIPv6 1`

 ... the exit nodes should avoid optimizing out , because it becomes
 quite obvious the client intends to use ipv6 at some point in time!


 But since this does not ask as much as  #21311, '''"Mark as duplicate"'''
 is fine with me since solving #21311 will close that ticket too.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24874 [Core Tor/Tor]: Running out of disk space triggers BUG(ent == NULL) at consdiffmgr.c:1316

[Tor Bug Tracker & Wiki]

#24874: Running out of disk space triggers BUG(ent == NULL) at 
consdiffmgr.c:1316
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 Jan 11 03:30:10.350 [warn] Error writing to "freeBogatov/diff-cache/1090":
 No space left on device
 Jan 11 03:30:10.350 [warn] tor_bug_occurred_(): Bug:
 src/or/consdiffmgr.c:1316: store_multiple: Non-fatal assertion !(ent ==
 NULL) failed. (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: Non-fatal assertion !(ent == NULL) failed
 in store_multiple at src/or/consdiffmgr.c:1316. Stack trace: (on Tor
 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(log_backtrace+0x42)
 [0x7f8075292e82] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug:
 ../tor/src/or/tor(tor_bug_occurred_+0xca) [0x7f80752ae21a] (on Tor 0.3.3.0
 -alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x11b718)
 [0x7f8075223718] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x11b9cd)
 [0x7f80752239cd] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug:
 ../tor/src/or/tor(replyqueue_process+0x52) [0x7f80752b1272] (on Tor
 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x2014f4)
 [0x7f80753094f4] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x201805)
 [0x7f8075309805] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x201e95)
 [0x7f8075309e95] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug:
 ../tor/src/or/tor(event_base_loop+0x2c8) [0x7f807530a5f9] (on Tor 0.3.3.0
 -alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(do_main_loop+0x41b)
 [0x7f807515aa8b] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(tor_run_main+0x28b)
 [0x7f807515b06b] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(tor_main+0x43)
 [0x7f8075155953] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(main+0x19)
 [0x7f80751557e9] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f8073c78d1d] (on Tor 0.3.3.0
 -alpha-dev 943134e886d9cef2)
 Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(+0x4d6f9)
 [0x7f80751556f9] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
 }}}

 I hit the bug on master, but it looks like it is present in 0.3.2 and
 0.3.1 as well.

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

Re: [tor-bugs] #24874 [Core Tor/Tor]: Running out of disk space triggers BUG(ent == NULL) at consdiffmgr.c:1316

[Tor Bug Tracker & Wiki]

#24874: Running out of disk space triggers BUG(ent == NULL) at 
consdiffmgr.c:1316
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

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


Comment:

 This is a duplicate of #24859

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by Sebastian):

 * status:  closed => reopened
 * resolution:  implemented =>
 * severity:  Normal => Critical


Comment:

 Something went really wrong here. This is what the docs now say:

 {{{
 Do not list any bridge relay as it would compromise its concealment.
 [...]
 MyFamily **must** be set correctly if you run more than one relay or
 bridge. (That is, every relay should list all the others as described
 above.)
 }}}

 bridges should definitely not be mentioned below.

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

Re: [tor-bugs] #24497 [Webpages/Website]: Improve documentation for tor relay operators

[Tor Bug Tracker & Wiki]

#24497: Improve documentation for tor relay operators
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 I asked for feedback:
 https://lists.torproject.org/pipermail/tor-relays/2018-January/014110.html
 https://twitter.com/nusenu_/status/951538206067118080

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by cypherpunks):

 Yes, I mentioned that in comment 8 as well but it got ignored.

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

Re: [tor-bugs] #24834 [Metrics/Relay Search]: Map consensus weight vs bandwidth for each bandwidth authority's votes

[Tor Bug Tracker & Wiki]

#24834: Map consensus weight vs bandwidth for each bandwidth authority's votes
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24674| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 If there is a concrete plan and resources available for #16843, I could
 provide a short-term solution using Stem. I really don't want to do this
 unless I know it's going to be short-term though.

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

Re: [tor-bugs] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 As I've just commented on #24834, if there is a concrete plan for this and
 I can see there are the resources to make it happen, then I'm happy to
 produce a short term solution using Stem for adding bandwidth votes to
 Relay Search.

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

Re: [tor-bugs] #24869 [Metrics/Relay Search]: Put all map parameters in the URL

[Tor Bug Tracker & Wiki]

#24869: Put all map parameters in the URL
--+--
 Reporter:  teor  |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * owner:  metrics-team => irl
 * status:  new => accepted


Comment:

 Currently this is not possible. It shouldn't be too much work to add
 though.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by Sebastian):

 Trivial patch in myfamily in my repo. I also fixed the issue of saying
 that MyFamily **must** be set and then in parens say that it **should** be
 set.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by Sebastian):

 * status:  reopened => 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] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_review


Comment:

 Replying to [comment:3 mcs]:
 > Replying to [comment:2 dcf]:
 > > What do you need from me, a new tag with this bug fixed?
 >
 > Yes.

 The [https://gitweb.torproject.org/pluggable-
 transports/meek.git/log/?h=bug24642 bug24642] branch uses the `StdinPipe`
 idea.

 I'm not totally happy with it, because ideally according to pt-spec, we
 should keep track of the stdin handle, and close it before sending
 anything like SIGTERM to the subprocess. But that would require more
 rewriting and is more than you need right now.

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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions

[Tor Bug Tracker & Wiki]

#24864: directory authorities take a while to update  relays' Tor versions
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay, tor-dirauth  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_information
 * keywords:   => tor-relay, tor-dirauth
 * points:   => 1
 * milestone:   => Tor: 0.3.3.x-final


Old description:

> copy from
> ​https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html
>
> Hi,
>
> the goal of this email is to avoid a false positive warning for relay
> operators
> on atlas but the root cause might be in core tor.
>
> background:
> I really liked when irl added the big red warning to atlas when a tor
> relay
> runs an outdated (aka not running a "recommended") tor version
> because it actually triggered operators to upgrade, an important step
> toward a more healthy network.
> The problem is: This big red banner on atlas has false-positives which
> confuses operators [0].
>
> Originally this has been an onionoo bug which
> has been fixed in v1.8.0, but it happens again and Karsten had the
> feeling
> that tor dir auths do not update  the version information of a relay
> after it
> upgraded (and uploaded a new descriptor). I looked into one example and
> can confirm what Karsten suggested [1].
>
> Let me show you that example of FP
> 1283EBDEEC2B9D745F1E7FBE83407655B984FD66.
> Data has been provided by Karsten and is available here: [2].
>
> That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his
> first
> descriptor with 0.3.0.13 on:
>
> 2018-01-09 10:14:00,server,,0.3.0.13
>
> except for bastet dir auths did not care and still said this relay runs
> 0.3.0.10:
>
> 2018-01-09 11:00:00,consensus,,0.3.0.10
> 2018-01-09 11:00:00,vote,bastet,0.3.0.13   note
> 2018-01-09 11:00:00,vote,dannenberg,0.3.0.10
> 2018-01-09 11:00:00,vote,dizum,0.3.0.10
> 2018-01-09 11:00:00,vote,Faravahar,0.3.0.10
> 2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10
> 2018-01-09 11:00:00,vote,longclaw,0.3.0.10
> 2018-01-09 11:00:00,vote,maatuska,0.3.0.10
> 2018-01-09 11:00:00,vote,moria1,0.3.0.10
> 2018-01-09 11:00:00,vote,tor26,0.3.0.10
> 2018-01-09 12:00:00,consensus,,0.3.0.10
> 2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<
> 2018-01-09 12:00:00,vote,dannenberg,0.3.0.10
> 2018-01-09 12:00:00,vote,dizum,0.3.0.10
> 2018-01-09 12:00:00,vote,Faravahar,0.3.0.10
> 2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10
> 2018-01-09 12:00:00,vote,longclaw,0.3.0.10
> 2018-01-09 12:00:00,vote,maatuska,0.3.0.10
> 2018-01-09 12:00:00,vote,moria1,0.3.0.10
> 2018-01-09 12:00:00,vote,tor26,0.3.0.10
>
> even 6 hours later this is unchanged.
>
> Then the operator upgraded from 0.3.0.13 to 0.3.1.9
> and uploaded his first descriptor:
>
> 2018-01-09 16:39:01,server,,0.3.1.9
>
> this remained "unnoticed" by all dir auths until
> longclaw voted for the new version:
>
> 2018-01-09 23:00:00,consensus,,0.3.0.10
> 2018-01-09 23:00:00,vote,bastet,0.3.0.10
> 2018-01-09 23:00:00,vote,dannenberg,0.3.0.10
> 2018-01-09 23:00:00,vote,dizum,0.3.0.10
> 2018-01-09 23:00:00,vote,Faravahar,0.3.0.10
> 2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10
> 2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <
> 2018-01-09 23:00:00,vote,maatuska,0.3.0.10
> 2018-01-09 23:00:00,vote,moria1,0.3.0.10
> 2018-01-09 23:00:00,vote,tor26,0.3.0.10
>
> On 2018-01-10 02:38:07 the relay uploaded a second descriptor with
> v0.3.1.9 and almost all dir auths agreed immediately:
>
> 2018-01-10 02:38:07,server,,0.3.1.9
> 2018-01-10 03:00:00,consensus,,0.3.1.9
> 2018-01-10 03:00:00,vote,bastet,0.3.0.10
> 2018-01-10 03:00:00,vote,dannenberg,0.3.1.9
> 2018-01-10 03:00:00,vote,dizum,0.3.1.9
> 2018-01-10 03:00:00,vote,Faravahar,0.3.1.9
> 2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9
> 2018-01-10 03:00:00,vote,longclaw,0.3.1.9
> 2018-01-10 03:00:00,vote,maatuska,0.3.1.9
> 2018-01-10 03:00:00,vote,moria1,0.3.1.9
> 2018-01-10 03:00:00,vote,tor26,0.3.1.9
>

> So it took the operator 17 hours to convince enough
> dir auths that he upgraded.
> I can see multiple reasons why this can make sense (as the tor version
> is actually not that relevant consensus data) but maybe it was
> not clear what the side effects of not updating that field are.
>
> While I believe there is still another onionoo issue,
> this should also be improved.
>
> Thoughts?
>

>
> [0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html
> [1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11
> [2]
> https://trac.torproject.org/projects/to

Re: [tor-bugs] #24862 [Metrics/Consensus Health]: Add per-relay tor versions to the consensus health detailed page

[Tor Bug Tracker & Wiki]

#24862: Add per-relay tor versions to the consensus health detailed page
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Yes, see my comment:
 https://trac.torproject.org/projects/tor/ticket/24864#comment:6

 While versions would be useful, let's confirm this is not an Onionoo bug
 first.

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

Re: [tor-bugs] #22488 [Metrics/Onionoo]: Include relay version listed in consensus in addition to platform line from server descriptor

[Tor Bug Tracker & Wiki]

#22488: Include relay version listed in consensus in addition to platform line 
from
server descriptor
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  High |  Milestone:  Onionoo-1.8.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by teor):

 I did some analysis of the examples in the Core Tor ticket, Tor appears to
 be working fine:
 https://trac.torproject.org/projects/tor/ticket/24864#comment:6

 Perhaps this is just a bug in Onionoo?

 I am waiting for some more examples in the Core Tor ticket.

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

Re: [tor-bugs] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by karsten):

 Before making a plan we'd need to know what pieces of information we'd
 want to extract from votes in the near future. In particular, we'll have
 to decide whether we want to extract things from just the latest set of
 votes (like most things in details documents) or keep a history of vote
 parts over time (like bandwidth, weights, etc. documents).

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

Re: [tor-bugs] #22488 [Metrics/Onionoo]: Include relay version listed in consensus in addition to platform line from server descriptor

[Tor Bug Tracker & Wiki]

#22488: Include relay version listed in consensus in addition to platform line 
from
server descriptor
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  High |  Milestone:  Onionoo-1.8.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:13 teor]:
 > I did some analysis of the examples in the Core Tor ticket, Tor appears
 to be working fine:
 > https://trac.torproject.org/projects/tor/ticket/24864#comment:6
 >
 > Perhaps this is just a bug in Onionoo?

 Hmm, I don't see how Onionoo would be the issue here. The preliminary
 analysis that I did in comment 11 above is not based on Onionoo, but on a
 new analysis made using metrics-lib.

 > I am waiting for some more examples in the Core Tor ticket.

 Did you check the CSV file that is attached to this ticket? That just
 contains the relays above. I'm going to upload the full file with all
 relay fingerprints now and will post the link here in 10-20 minutes.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
---+---
 Reporter:  cypherpunks|  Owner:  nickm
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  tor-doc, man, review-group-28  |  Actual Points:
Parent ID:  #24497 | Points:
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:23 Sebastian]:
 > Trivial patch in myfamily in my repo. I also fixed the issue of saying
 that MyFamily **must** be set and then in parens say that it **should** be
 set.
 Thanks!  This patch looks good to me.  Sorry for missing the bridge thing
 the first time around.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24875 [Obfuscation/meek]: meek-client doesn't exit on close of stdin if there are no active handlers running

[Tor Bug Tracker & Wiki]

#24875: meek-client doesn't exit on close of stdin if there are no active 
handlers
running
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 If you give meek-client an EOF while it's not currently handling any
 connections, it says it is terminating but doesn't quite terminate.
 {{{
 $ TOR_PT_EXIT_ON_STDIN_CLOSE=1 TOR_PT_MANAGED_TRANSPORT_VER=1
 TOR_PT_CLIENT_TRANSPORTS=meek ./meek-client < /dev/null
 VERSION 1
 CMETHOD meek socks5 127.0.0.1:35831
 2018/01/11 22:03:23 listening on 127.0.0.1:35831
 CMETHODS DONE
 2018/01/11 22:03:23 synthesizing SIGTERM because of stdin close
 2018/01/11 22:03:23 got signal terminated
 2018/01/11 22:03:23 error in AcceptSocks: accept tcp 127.0.0.1:35831: use
 of closed network connection
 }}}
 It's stuck in this loop, because it only checks `numHandlers == 0` inside
 the loop and not before entering.
 {{{
 for n := range handlerChan {
 numHandlers += n
 if numHandlers == 0 {
 break
 }
 }
 }}}

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

Re: [tor-bugs] #22488 [Metrics/Onionoo]: Include relay version listed in consensus in addition to platform line from server descriptor

[Tor Bug Tracker & Wiki]

#22488: Include relay version listed in consensus in addition to platform line 
from
server descriptor
-+---
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  High |  Milestone:  Onionoo-1.8.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:14 karsten]:
 > [...] I'm going to upload the full file with all relay fingerprints now
 and will post the link here in 10-20 minutes.

 https://people.torproject.org/~karsten/volatile/task-22488-relay-versions-
 full.csv.xz

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Critical | Resolution:
 Keywords:  tor-doc, man, review-group-28,   |  Actual Points:
  security-low, 032-backport |
Parent ID:  #24497   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by teor):

 * keywords:  tor-doc, man, review-group-28 => tor-doc, man, review-
 group-28, security-low, 032-backport


Comment:

 Did the original patch get backported to 0.3.2?
 If it did, then we need to backport this fix to 0.3.2 as well, because
 bridge disclosure is a security issue.

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

Re: [tor-bugs] #24851 [Core Tor/Fallback Scripts]: create a script that generates the authority format from the authorities in the current consensus

[Tor Bug Tracker & Wiki]

#24851: create a script that generates the authority format from the 
authorities in
the current consensus
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-dirauth|  Actual Points:
Parent ID:  #24818 | Points:  0.5
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Here is the specification for the authority list:
 https://github.com/teor2345/torspec/blob/dir-list/dir-list-spec.txt#L254

 The data should be the same as the data in this list:
 https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n1079

 But it will end up looking a bit like this list:
 https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc#n27

 And we need to get the data from the current Tor consensus using stem, so
 it's easy to update when it changes:
 
https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.get_consensus

 It's ok to just get the fields right in a first draft, and then work out
 the exact order and formatting later.

 Replying to [ticket:24851 teor]:
 > We need to make sure we also:
 > * apply address overrides
 > * make sure the details match the current list

 The address overrides will become obvious when we check against the
 current list.

 > * check that all supported Tor versions can parse the list (existing
 unit tests)

 We can do this by replacing src/or/auth_dirs.inc with the generated list,
 then running Tor's "make check".
 This will only work once #24854 is completed.

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

Re: [tor-bugs] #24421 [Applications/Tor Browser]: "Temporarily allow all this page" and uploads get inherited when New Identity is chosen.

[Tor Bug Tracker & Wiki]

#24421: "Temporarily allow all this page" and uploads get inherited when New
Identity is chosen.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-newnym, TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ma1):

 Replying to [comment:13 mcs]:
 > A quick `dump()` added to the end of NoScript's Main.js shows it is
 being loaded twice, but I am not sure if that is by design or not.

 By Design. Both MainParent and MainChild are built as mix-ins with Main
 (which is common to both), and this gets loaded twice in the same process
 if you've got e10s disabled, because of IPC "emulation" (the
 MessageManager APIs try to show you the same multi-process view of the
 environment even if e10s is off and everything lives in a single actual
 process).

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

Re: [tor-bugs] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I'm happy to work on a spec patch. Where is the spec?

 Replying to [comment:9 karsten]:
 > Before making a plan we'd need to know what pieces of information we'd
 want to extract from votes in the near future. In particular, we'll have
 to decide whether we want to extract things from just the latest set of
 votes (like most things in details documents) or keep a history of vote
 parts over time (like bandwidth, weights, etc. documents).

 For #24834, we just need the latest bandwidth votes for each relay.
 Doing historical per-relay bandwidth votes would be cool, but also way out
 of scope.

 I can't think of anything else right now, maybe current votes for relay
 versions, if we confirm that the version bug is in Tor and not Onionoo?

 Karsten, irl, you might be more familiar with the kinds of vote data that
 people ask for?

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

Re: [tor-bugs] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 (I think we should focus on the map feature, and try not to duplicate
 functionality from consensus-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] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Having flags available in Onionoo for the latest votes would be useful,
 but the only advantage I can see over consensus-health is not having to
 load a huge page to see the flags for only one relay. There are some
 synthentic flags that are currently only possible in RS or in consensus-
 health as they both have different views of the data. In the future, we
 may have a consensus-health that uses Onionoo as a data source but this is
 a long way off. For now, we can just have bandwidth votes and maybe flags
 if karsten tells us that's not too much extra work/data
 storage/processing.

 I'd like to see something like:

 {{{
 {
   "votes": [
 {
   "authority": "authority_name",
   "flags": ["flag1", "flag2"],
   "measured_bandwidth": 100
 },
 ...
   ]
 }
 }}}

 or

 {{{
 {
   "votes": {
 "authority_name": {
   "flags": ["flag1", "flag2"],
   "measured_bandwidth": 100
 },
 ...
   }
 }
 }}}

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

Re: [tor-bugs] #24582 [Core Tor/Tor]: Memory leak in tor-resolve

[Tor Bug Tracker & Wiki]

#24582: Memory leak in tor-resolve
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  review-group-28  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me, and tests, spaces, changes pass, etc.

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

Re: [tor-bugs] #17224 [Core Tor/Tor]: Refactor common parts of parse_dir_authority_line and parse_dir_fallback_line

[Tor Bug Tracker & Wiki]

#17224: Refactor common parts of parse_dir_authority_line and
parse_dir_fallback_line
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, tor-client, refactor   |  Actual Points:
  technical-debt |
Parent ID:  #24818   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Oh, and we should update the dir-list-spec to note how these changes may
 affect the format of future fallback and authority lists.

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

Re: [tor-bugs] #24818 [Core Tor/Tor]: Make the hard-coded authorities into a separate include file with a standard format

[Tor Bug Tracker & Wiki]

#24818: Make the hard-coded authorities into a separate include file with a
standard format
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  torspec, tor-dirauth  |  Actual Points:
Parent ID:  #24786| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I updated the format to be more readable, precisely describe the format we
 intend to generate, and make the conditional parts of the format clearer.

 This affects #24851 and #24852.

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