[tor-bugs] #22227 [Applications/Tor Browser]: Netmonitor Gives the Wrong Remote Address

[Tor Bug Tracker & Wiki]

#7: Netmonitor Gives the Wrong Remote Address
--+--
 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:|
--+--
 TorBrowser 6.5.2 on Linux

 === To reproduce:
 1. Open Inspect Element -> Network
 2. Visit a new site, e.g. https://trac.torproject.org/
 3. Click on the request entry for the initial request in the inspector.

 === Expected:
 The "Remote address" field shows the IP address of the site returned by
 the DNS query. This is the behaviour in Firefox.

 === Actual:
 Remote address is always shown as 0.0.0.0

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

Re: [tor-bugs] #22226 [Applications/Tor Browser]: Exploiting the TOR-Browser reporting security bugs issues

[Tor Bug Tracker & Wiki]

#6: Exploiting the TOR-Browser reporting security bugs issues
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 The blog post is wrong about the list: it does exist, it's just not
 accessible using the mailman interface. We want to publish it on our
 website, but in a way that doesn't attract user support requests (see
 #22163).

 I will leave the rest of the issues reported in that blog post for the tor
 browser team.
 But I don't think Tor Browser is designed to be undetectable when compared
 with other browsers.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22226 [Applications/Tor Browser]: Exploiting the TOR-Browser reporting security bugs issues

[Tor Bug Tracker & Wiki]

#6: Exploiting the TOR-Browser reporting security bugs issues
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This security researcher has multiple tor browser security
 vulnerabilities, but is unable to successfully report them. Torproject
 should make it much easier and much simpler to report security bugs, like
 having a single well know security reporting email. Here is his blog post
 with the security vulnerability and with the problems explained.

 http://www.hackerfactor.com/blog/index.php?/archives/761-Exploiting-the-
 TOR-Browser.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] #20822 [Core Tor/Tor]: Follow-up tasks for prop271 (new guard API) implementation

[Tor Bug Tracker & Wiki]

#20822: Follow-up tasks for prop271 (new guard API) implementation
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, triaged-out-20170124, |  Actual Points:
  031-reach, TorCoreTeam201705   |
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (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] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+

Comment (by catalyst):

 Replying to [comment:11 teor]:
 > All bridges are directory mirrors.
 >
 > But there will always be a tradeoff when all our primary guards aren't
 working between:
 > * fail (and be more secure), and
 > * try another guard/bridge/fallback/directory authority (and be more
 usable).
 >
 > Looks like we set the bar too low. Or there is another bug.

 I think maybe we should be more lenient about trying other guards when we
 have no (or very limited) reachability information (e.g., during
 bootstrapping from zero state) than when we have fresh reachability
 information, especially when bridges are involved.

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+

Comment (by teor):

 Replying to [comment:10 catalyst]:
 > Replying to [comment:9 teor]:
 >
 > > IMO, the right fix here is to fall back to a fallback directory
 mirror. It's what they are there for.

 This comment was about unrestricted entry guard settings, not bridges.

 > I'm not sure I understand what this means.  If a working bridge is a
 directory mirror, why is that not sufficient?  Or maybe all of the (non-
 guard) working bridges fail to be directory mirrors?

 All bridges are directory mirrors.

 But there will always be a tradeoff when all our primary guards aren't
 working between:
 * fail (and be more secure), and
 * try another guard/bridge/fallback/directory authority (and be more
 usable).

 Looks like we set the bar too low. Or there is another bug.

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

Re: [tor-bugs] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by ahf):

 * status:  accepted => needs_review


Comment:

 I think I could use some feedback on this now:
 https://gitlab.com/ahf/tor/merge_requests/11?expand_all_diffs=1

 I'm missing two essentials: lift my usage of `srv_meth_pref_precompressed`
 into a separate constant and deny LZMA during request negotiation for the
 dynamic endpoints. I'll add these changes as fixups.

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+

Comment (by catalyst):

 Replying to [comment:9 teor]:

 > IMO, the right fix here is to fall back to a fallback directory mirror.
 It's what they are there for.

 I'm not sure I understand what this means.  If a working bridge is a
 directory mirror, why is that not sufficient?  Or maybe all of the (non-
 guard) working bridges fail to be directory mirrors?

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

Re: [tor-bugs] #22225 [Core Tor/Chutney]: Make chutney run multiple verification rounds

[Tor Bug Tracker & Wiki]

#5: Make chutney run multiple verification rounds
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:  0.1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 Merged as f020fb9.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22225 [Core Tor/Chutney]: Make chutney run multiple verification rounds

[Tor Bug Tracker & Wiki]

#5: Make chutney run multiple verification rounds
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Chutney opens all its verification streams simultaneously.
 But sometimes we want to run multiple verification rounds sequentially.

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

Re: [tor-bugs] #22221 [Core Tor/Tor]: CID 1405983 test_channelpadding.c dead code

[Tor Bug Tracker & Wiki]

#1: CID 1405983 test_channelpadding.c dead code
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Ah, yes. This test was originally written to exercise a timer layer that
 limited the number of pending libevent timers. Since Nick added the timing
 wheel code, that layer was no longer needed and was removed. But it is
 still a good idea to exercise adding timers out of order, and adding
 timers with firing times before the currently scheduled batch. Fixing this
 loop order makes sure that happens, so this is good to go.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22224 [Core Tor/Chutney]: chutney mixed networks never test old clients or hidden services

[Tor Bug Tracker & Wiki]

#4: chutney mixed networks never test old clients or hidden services
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Because they use the tags [b]cOLD and hOLD.

 We can fix this by adding client and hidden_service flags to n._env, like
 the existing exit flag, and then tagging all the nodes in all the
 networks. (We might want to do this for authorities, bridge relays, bridge
 clients, and any other nodes, if they don't already have a tag.)

 We can then do a check that each node has at least one tag.

 {{{
 client_list = filter(lambda n:
  n._env['tag'] == 'c' or n._env['tag'] == 'bc',
  network._nodes)
 exit_list = filter(lambda n:
('exit' in n._env.keys()) and n._env['exit'] == 1,
network._nodes)
 hs_list = filter(lambda n:
  n._env['tag'] == 'h',
  network._nodes)
 }}}

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

Re: [tor-bugs] #22213 [Core Tor/Tor]: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed

[Tor Bug Tracker & Wiki]

#22213: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  new => needs_review


Comment:

 My {{{cleanup22213}}} branch does 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] #22222 [User Experience/Website]: Update text and link on tshirt page

[Tor Bug Tracker & Wiki]

#2: Update text and link on tshirt page
-+-
 Reporter:  kat5 |  Owner:  hiro
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

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


Comment:

 Merged!

 Please reopen if I broke 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] #22213 [Core Tor/Tor]: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed

[Tor Bug Tracker & Wiki]

#22213: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:1 nickm]:
 > unless we think we're likely to want it in the future for some reason.

 I think we're not likely to use it. In the NOTIFY_GENERATOR case, we do:
 {{{
 if (r == ROUTER_ADDED_NOTIFY_GENERATOR) {
   /* Accepted with a message. */
   [...]
   write_http_status_line(conn, 400, msg);
 }}}

 but in the "else" case, we do:
 {{{
 } else {
   [...]
   write_http_status_line(conn, 400, msg);
 }}}

 So, we already have (and are using) a way to send a 400 response along
 with a message.

 The comment where it says we accepted the descriptor seems to be at odds
 with the 400 response code. In conclusion, I think this is a halfbaked
 mistake from many years ago. :)

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

Re: [tor-bugs] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 (In the future, "diff -u" is your (and our :) friend.)

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

Re: [tor-bugs] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * status:  new => 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

[tor-bugs] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor |   Keywords:  doc easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://lists.torproject.org/pipermail/tor-dev/2017-May/012249.html

 I wanted to help improve the man page section for MyFamily in the light
 of today's MyFamily change [1].

 I sometimes contact relay operators about their MyFamily configuration
 and a common request is: "Please send me an example"

 So I added an example to the man page (including the new multiline
 support in 031)

 - replaced "node" with "fingerprint"
 (no one is using nicknames anymore, or onionoo does not display
 fingerprints?) Are nicknames still supported? (Roger started to remove
 remaining bits of the past Named "world" so this might be another place?)
 - made clear that you can still have multiple fingerprints in a single
 line (if this will be deprecated at some point I can add a deprecation
 info)
 - added info that the fingerprint can be prefixed with $
 - changed "This option can be repeated many times, for multiple families"
 to
 "This option can be repeated many times, for multiple fingerprints"
 (from one relay's view there is only one family)

 nusenu

 inline patch below (I can paste it to trac if you like)

 [1]
 
https://gitweb.torproject.org/tor.git/commit/?id=d76cffda601eed40d6a81eadb1240d98ee1e70a2
 https://trac.torproject.org/projects/tor/ticket/4998#comment:11

 {{{
 1735c1735
 < [[MyFamily]] **MyFamily** __node__::
 ---
 > [[MyFamily]] **MyFamily** __fingerprint__,__fingerprint__,__...__::
 1738,1739c1738,1741
 < their identity fingerprints. This option can be repeated many
 times, for
 < multiple families. When two servers both declare that they are in
 the
 ---
 > their (possibly $-prefixed) identity fingerprints.
 > This option can be repeated many times, for
 > multiple fingerprints, all fingerprints in all MyFamily lines will
 be merged.
 > When two servers both declare that they are in the
 1745,1746c1747,1753
 < When listing a node, it's better to list it by fingerprint than by
 < nickname: fingerprints are more reliable.
 ---
 > Example: +
 > MyFamily
 
,
 +
 > MyFamily  +
 >  +
 > is identical to: +
 >  +
 > MyFamily
 
,,
 }}}

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

Re: [tor-bugs] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  assigned => needs_review


Comment:

 Proposed patch in https://gitlab.com/argonblue/tor/merge_requests/11
 Should we also update the ticket summary and description?

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

Re: [tor-bugs] #20395 [Metrics/metrics-lib]: metrics-lib should be able to handle large descriptor files

[Tor Bug Tracker & Wiki]

#20395: metrics-lib should be able to handle large descriptor files
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Great ideas above!  And I think we should implement them, because they
 clearly improve memory consumption.

 Going into more details, your second assumption makes sense to me.  I
 didn't think of that before, but I agree that we can make that assumption.

 However, your first assumption is unfortunately wrong.  I just
 concatenated all votes from May 1, 2017 to a single file with a size of
 0.8G.  I passed that to metrics-lib to read and parse it, which consumed
 4.1G of memory in total for parsed descriptors and contained raw
 descriptor bytes.  I then modified `DescriptorImpl` to avoid storing raw
 descriptor bytes in memory, which led to memory consumption of 3.3G.  The
 difference is precisely the 0.8G of the original file.  But the 3.3G still
 remain, and that number will grow with the number of descriptors we put in
 a file.  Like, 72 hours of votes from an initial CollecTor sync with all
 votes concatenated to a single file would consume 9.9G, plus a few G more
 while parsing.  No, the suggestion above is certainly an improvement, but
 it still does not scale.

 But I could see us making these suggested improvements anyway, and they'll
 help us going forward.  Some thoughts:
  - We could modify `Descriptor#getRawDescriptorBytes()` to use its file
 reference and start and end position to retrieve the bytes from disk and
 return them to the caller.  That is, rather than bothering the user to do
 that.  This would even make this change backward-compatible.
  - We should avoid calling that new `Descriptor#getRawDescriptorBytes()`
 ourselves at all costs while parsing and instead pass the bytes around
 directly.  I'm mentioning this explicitly, because I found uses of that
 method where we could have passed around these bytes as parameters
 instead.
  - We need to be careful to write the reading-files-in-chunks logic in a
 way that detects descriptor starts and ends across chunk boundaries.
 Think of tiny descriptors like microdescriptors.
  - And we should avoid scanning chunks repeatedly when a descriptor covers
 many, many such chunks.  Think of huge descriptors like votes.

 Once we're there, let's talk more about avoiding to keep potentially huge
 lists of parsed descriptors in memory.

 Do you want to start hacking on your suggestions above?

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 Merged `prop275_minimal_029` into maint-0.2.9

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 In fact, I was pondering either a world where we merge something like my
 hack1 branch, and then relays wouldn't need to look at the microdesc
 consensus published_on values anymore.

 Or a world where we design some new hack where we put all the timestamps
 to the same future value, *except* for the ones that are sufficiently old
 to trigger the "is quite old" hack.

 I'm going to try to track down the "woah that's a lot of descriptor
 publish attempts" bug more in the meantime.

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 Replying to [comment:25 nickm]:
 > But I still think we can safely merge the prop275_minimal_029 part.
 Y/N?

 Yes!

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

Re: [tor-bugs] #10286 [Applications/Tor Browser]: Touch events leak absolute screen coordinates

[Tor Bug Tracker & Wiki]

#10286: Touch events leak absolute screen coordinates
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  ff52-esr, tbb-testcase, tbb-firefox-patch, |
  tbb-7.0-must-alpha, TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 This looks good to me.

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

Re: [tor-bugs] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:  catalyst
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * owner:  ahf => 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] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 Okay, I'm convinced that we shouldn't merge prop275_more_031 now, until we
 have a fix for the "version listed in consensus is quite old" bug.  I
 think that means we can return to this in 0.3.2.  But I still think we can
 safely merge the prop275_minimal_029 part.  Y/N?

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

Re: [tor-bugs] #21779 [Applications/Tor Browser]: Non-admin users can't access Tor Browser on macOS

[Tor Bug Tracker & Wiki]

#21779: Non-admin users can't access Tor Browser on macOS
--+
 Reporter:  teor  |  Owner:  mcs
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201705R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 Hm, maybe. The patch looks good to me, though, and I took it for `master`
 (commit f27d2cab4ed80a4c7b4f594b593b6b90f6148a82). I'll close the ticket
 for now and keep an eye on this while signing. I doubt I get to a test
 signature before building the alphas. If there is indeed an issue with the
 signing setup I hope I can fix it ad hoc.

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 Replying to [comment:23 nickm]:
 > That's 15/>9000 uploads, though?  It seems like it might not matter a
 great deal then.  I think we can also merge these patches now, and
 investigate how to fix the "version listed in consensus is quite old" bug
 before we actually change the published logic.  Agreed?

 Alas, disagree. I think those "not specified" uploads represent a bug
 where some relays upload when they don't need to (i.e. they didn't mark
 their descriptor dirty in any way before uploading), and where nearly all
 of those uploads are discarded because they have only cosmetic changes.

 Here's the stat after 12.5 hours:
 {{{
 $ grep "New descriptor post, because:" moria1-info|cut -d: -f5-|sort|uniq
 -c
1324  bandwidth has changed
 279  config change
   3  configured managed proxies
 436  DirPort found reachable
   2  dns resolvers back
   2  IP address changed
3434  not listed in consensus
  421560  not specified
1120  ORPort found reachable
 674  rotated onion key
4003  time for new descriptor
 868  version listed in consensus is quite old
 }}}

 And out of the "is quite old", we have
 {{{
 $ grep -A1 "is quite old" moria1-info|grep "Added descriptor"|cut -d\'
 -f2-|sort|uniq -c|wc -l
 426
 }}}

 So 426 of our ~7300 relays stayed in the consensus in the last 12.5 hours
 because of this hack.

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

Re: [tor-bugs] #21879 [Applications/Tor Browser]: OSX: default bookmarks not used

[Tor Bug Tracker & Wiki]

#21879: OSX: default bookmarks not used
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good, thanks. Applied to `master` as commit
 57f088b981a0292d5370b3c56c6d7e5a18f95aca.

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

Re: [tor-bugs] #21569 [Applications/Tor Browser]: Investigate and neuter fingerprinting potential of Permissions API

[Tor Bug Tracker & Wiki]

#21569: Investigate and neuter fingerprinting potential of Permissions API
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

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


Comment:

 Looks good to me. I cherry-picked this on `tor-browser-52.1.0esr-7.0-2`
 (commit d8b12ca703cd530b5c7684be00d5979fb1543705).

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

Re: [tor-bugs] #21779 [Applications/Tor Browser]: Non-admin users can't access Tor Browser on macOS

[Tor Bug Tracker & Wiki]

#21779: Non-admin users can't access Tor Browser on macOS
--+--
 Reporter:  teor  |  Owner:  mcs
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201705R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201705 => TorBrowserTeam201705R
 * status:  assigned => needs_review


Comment:

 Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-browser-
 bundle.git/commit/?h=bug21779-01=1472ef020fb709226bda7cf234a42f3b928c08ed

 Unfortunately, we could not reproduce the original problem in the test
 builds that Kathy and I made. We are not sure why not. Is it possible that
 a repackaging step that occurs after the initial dmg is produced is
 changing file permissions somehow, e.g., during OSX code signing?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22222 [User Experience/Website]: Update text and link on tshirt page

[Tor Bug Tracker & Wiki]

#2: Update text and link on tshirt page
-+--
 Reporter:  kat5 |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We made a new wiki page to show which tshirt colors, styles, and sized are
 currently available. The tshirt page
 (https://www.torproject.org/getinvolved/tshirt.html) needs to be updated
 to point to it.

 Please remove this text:

 The nice people at torservers.net are handling the tshirt requests. They
 have a variety of colors, shapes, and sizes, using the great new "roots"
 design that Leiah Jansen made for us.

 and replace it with this:

 There are a variety of colors, shapes, and sizes available in the great
 roots design that Leiah Jansen made for  us, as well as some older
 designs.

 And please link "variety of colors, shapes, and sizes" to:

 https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Tshirts

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

Re: [tor-bugs] #21779 [Applications/Tor Browser]: Non-admin users can't access Tor Browser on macOS

[Tor Bug Tracker & Wiki]

#21779: Non-admin users can't access Tor Browser on macOS
--+--
 Reporter:  teor  |  Owner:  mcs
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201705  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * owner:  tbb-team => mcs
 * status:  new => assigned
 * cc: gk (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] #22221 [Core Tor/Tor]: CID 1405983 test_channelpadding.c dead code

[Tor Bug Tracker & Wiki]

#1: CID 1405983 test_channelpadding.c dead code
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  new => 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] #21569 [Applications/Tor Browser]: Investigate and neuter fingerprinting potential of Permissions API

[Tor Bug Tracker & Wiki]

#21569: Investigate and neuter fingerprinting potential of Permissions API
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 r=brade, r=mcs
 Kathy and I are far from experts on this aspect of Firefox, but the
 patches look good and we successfully ran the tests on OSX.  We also ran
 the tests without the other portion of the patch and saw that 2 tests
 failed due to lack of isolation (as expected).

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

Re: [tor-bugs] #22221 [Core Tor/Tor]: CID 1405983 test_channelpadding.c dead code

[Tor Bug Tracker & Wiki]

#1: CID 1405983 test_channelpadding.c dead code
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 Proposed patch in https://gitlab.com/argonblue/tor/merge_requests/10
 mikeperry, would you please comment on whether this reordering will cause
 a problem for the test case?

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 Replying to [comment:19 nickm]:
 > Fixed in 8266d193a608

 I'm not going to re-open this, but the behavior is still wrong in certain
 cases.

 Specifically, an error (or a double compressed payload) should be returned
 when the `.z` request contains an `Accept-Encoding` header that specifies
 anything other than `identity`/`deflate`.  This may be contrived and not
 worth worrying about, but the correct behavior (especially in the former
 case) isn't that hard.

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

Re: [tor-bugs] #21109 [Core Tor/Tor]: apparent inconsistency in prop264

[Tor Bug Tracker & Wiki]

#21109: apparent inconsistency in prop264
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  torspec   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 You're correct; the required/recommended protocols should have listed
 HSDir=1, after all the renumberings.  (And they do; see latest consensus
 and/or dirserv.c code to fill in the fields.)

 I've amended tor-spec.txt with 8692de910d3b56da27f17f890472ec91cf2014e7:
 Now that proposal 264 is closed, tor-spec.txt is the canonical location
 for subprotocol documentation.

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

Re: [tor-bugs] #21666 [Core Tor/Tor]: Prop278: Code to decide whether we want to request and/or provide CPU-intensive compression methods

[Tor Bug Tracker & Wiki]

#21666: Prop278: Code to decide whether we want to request and/or provide CPU-
intensive compression methods
+--
 Reporter:  ahf |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  4
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

 * cc: ahf (added)


Comment:

 Can we close this? We've moved all precomputed compression out of the main
 thread, and we've decided that expensive compression should _never_ be
 done while streaming.  Is that enough?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22221 [Core Tor/Tor]: CID 1405983 test_channelpadding.c dead code

[Tor Bug Tracker & Wiki]

#1: CID 1405983 test_channelpadding.c dead code
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Coverity found this dead code in `test_channelpadding.c` recently.  It
 looks like the `CHANNELS_TO_TEST/3` loop never runs because the
 `CHANNELS_TO_TEST/2` loop runs before it?  Is the right thing to do here
 to switch the sequence of those two loops?

 {{{

 299/* This loop should add timers to the first position in the
 timerslot
 300 * array, since its timeout is before all other timers. */
 at_least: At condition i < 33, the value of i must be at least 50.
 dead_error_condition: The condition i < 33 cannot be true.
 301for (; i < CHANNELS_TO_TEST/3; i++) {

 CID 1405983 (#1 of 1): Logically dead code (DEADCODE)
 dead_error_begin: Execution cannot reach this statement:
 chans[i]->next_padding_time
 302  chans[i]->next_padding_time_ms = monotime_coarse_absolute_msec()
 + 1;
 303  decision = channelpadding_decide_to_pad_channel(chans[i]);
 304  tt_int_op(decision, OP_EQ, CHANNELPADDING_PADDING_SCHEDULED);
 305  tt_assert(chans[i]->pending_padding_callback);
 306  tt_int_op(tried_to_write_cell, OP_EQ, 0);
 307

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

Re: [tor-bugs] #20395 [Metrics/metrics-lib]: metrics-lib should be able to handle large descriptor files

[Tor Bug Tracker & Wiki]

#20395: metrics-lib should be able to handle large descriptor files
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 I hope I didn't overlook anything:

 `DescriptorFile#getDescriptors()` and
 `DescriptorParser#parseDescriptors()` don't access files.  They receive
 Descriptor objects or bytes and will have to keep the bytes, but these
 methods don't cause an oom unless their caller provides too much.

 The problem lies in the implementation of
 `DescriptorReaderImpl$DescriptorReaderRunnable` (which - as an aside -
 should be a separate class).  There the `readFile` method attempts to read
 an entire file and chokes when encountering a huge file.
 `DescriptorReaderRunnable` should check the file size before opening in
 order to handle the files according to their size.  The oom is caused by
 reading the entire file into memory and then operating on it in-memory
 creating all the Descriptor objects (possibly copying the raw bytes, I
 didn't verify) in-memory.  Memory usage could be reduced
 1. by only reading parts of the huge file and also
 2. by not adding the bytes to the descriptor objects and instead simply
 keeping the file path and position inside the file in-memory.

 Assumptions:
 * many Descriptor objects w/o bytes occupy way less space than the
 Descriptor objects do currently
 * the descriptor containing files are available as long as there are
 Descriptor objects referring to them

 A sketch of changes:

 * Introduce descriptors that either hold their bytes in-memory or have a
 file path and in-file position(s) for accessing raw bytes, but don't store
 the bytes.
 * `DescriptorImpl` parses bytes and produces a list of the adapted
 Descriptor objects.
 * `DescriptorReaderRunnable` needs to read a certain chunk of a large
 file, parse enough to determine the next descriptor, and provide the
 parser also with the beginning and end positions in the file.

 This stays very closely to the current implementation, the details need
 some more work, and it might be necessary to change more.

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

Re: [tor-bugs] #21120 [Core Tor/Tor]: evdns_get_orig_address: tor_fragile_assert() warning for unknown rtype.

[Tor Bug Tracker & Wiki]

#21120: evdns_get_orig_address: tor_fragile_assert() warning for unknown rtype.
--+
 Reporter:  mr-4  |  Owner:
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:  0
Parent ID:| Points:  0
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => closed
 * points:  1 => 0
 * resolution:   => duplicate
 * actualpoints:   => 0


Comment:

 After a bit of investigation -- I am pretty sure this is a duplicate of
 #19869, fixed in 0.2.9.5-alpha.

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

Re: [tor-bugs] #22000 [Applications/Tor Browser]: update OSX browser sandbox profile for e10s

[Tor Bug Tracker & Wiki]

#22000: update OSX browser sandbox profile for e10s
-+-
 Reporter:  brade|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-security, tbb- |  Actual Points:
  sandboxing, tbb-e10s,tbb-7.0-must- |
  alpha,TorBrowserTeam201705 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by mcs):

 * keywords:  ff52-esr, tbb-security, tbb-sandboxing, tbb-e10s,
 TorBrowserTeam201705 =>
 ff52-esr, tbb-security, tbb-sandboxing, tbb-e10s,tbb-7.0-must-
 alpha,TorBrowserTeam201705


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

Re: [tor-bugs] #21879 [Applications/Tor Browser]: OSX: default bookmarks not used

[Tor Bug Tracker & Wiki]

#21879: OSX: default bookmarks not used
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705 =>
 ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705R
 * status:  assigned => needs_review


Comment:

 Mozilla changed the location of the default bookmarks within
 browser/omni.ja and also added them to the language packs. Here is a
 patch:
 https://gitweb.torproject.org/user/brade/tor-browser-
 bundle.git/commit/?h=bug21879-01=57f088b981a0292d5370b3c56c6d7e5a18f95aca

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

Re: [tor-bugs] #21879 [Applications/Tor Browser]: OSX: default bookmarks not used

[Tor Bug Tracker & Wiki]

#21879: OSX: default bookmarks not used
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: gk, arthuredelstein (added)
 * status:  new => assigned
 * owner:  tbb-team => mcs


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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 That's 15/>9000 uploads, though?  It seems like it might not matter a
 great deal then.  I think we can also merge these patches now, and
 investigate how to fix the "version listed in consensus is quite old" bug
 before we actually change the published logic.  Agreed?

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

Re: [tor-bugs] #22211 [Core Tor/Tor]: mistaken comment in routerstatus_parse_entry_from_string()

[Tor Bug Tracker & Wiki]

#22211: mistaken comment in routerstatus_parse_entry_from_string()
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Sounds right to me; fixed in ee3ccd2facb2

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

Re: [tor-bugs] #4998 [Core Tor/Tor]: MyFamily as a list

[Tor Bug Tracker & Wiki]

#4998: MyFamily as a list
+--
 Reporter:  weasel  |  Owner:  Jigsaw52
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.3.11-alpha
 Severity:  Normal  | Resolution:  implemented
 Keywords:  tor-relay lorax easy intro  |  Actual Points:
Parent ID:  #15060  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 Excellent; merged to master.  Thanks for the patches!

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Fixed in 8266d193a608

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

Re: [tor-bugs] #22219 [Core Tor/Tor]: channelpadding: "error: conflicting types for 'event_base_get_method'" on OpenBSD

[Tor Bug Tracker & Wiki]

#22219: channelpadding: "error: conflicting types for 'event_base_get_method'" 
on
OpenBSD
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Thanks; applied as 5dab99d6a814!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22220 [Core Tor/Tor]: hs: Move cell encoding/decoding out of hs_intropoint.c to hs_cell.c

[Tor Bug Tracker & Wiki]

#0: hs: Move cell encoding/decoding out of hs_intropoint.c to hs_cell.c
--+
 Reporter:  dgoulet   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:  SponsorR-can  |
--+
 The `hs_cell.c` file is added by #20657 so once it's merged, let's do this
 so we don't have cell mangling in different files everywhere.

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 Works for me.

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

[tor-bugs] #22219 [Core Tor/Tor]: channelpadding: "error: conflicting types for 'event_base_get_method'" on OpenBSD

[Tor Bug Tracker & Wiki]

#22219: channelpadding: "error: conflicting types for 'event_base_get_method'" 
on
OpenBSD
--+-
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Build fails on OpenBSD:

 In file included from src/or/channelpadding.c:23:
 /usr/include/event.h:300: error: conflicting types for
 'event_base_get_method'
 /usr/local/include/event2/event.h:372: error: previous declaration of
 'event_base_get_method' was here
 /usr/include/event.h:626: error: conflicting types for 'event_pending'
 /usr/local/include/event2/event.h:982: error: previous declaration of
 'event_pending' was here
 Error 1 in . (Makefile:5155 'src/or/channelpadding.o': @echo "  CC
 " src/or/channelpadding.o;depbase=`echo src/or/channelpadding.o ...)

 This should fix it:

 {{{
 diff --git a/src/or/channelpadding.c b/src/or/channelpadding.c
 index 412165156..f5248e896 100644
 --- a/src/or/channelpadding.c
 +++ b/src/or/channelpadding.c
 @@ -20,7 +20,7 @@
  #include "rephist.h"
  #include "router.h"
  #include "compat_time.h"
 -#include 
 +#include 

  STATIC int channelpadding_get_netflow_inactive_timeout_ms(const channel_t
 *);
  STATIC int channelpadding_send_disable_command(channel_t *);
 diff --git a/src/test/test_channelpadding.c
 b/src/test/test_channelpadding.c
 index cffc8d084..6a05fc89b 100644
 --- a/src/test/test_channelpadding.c
 +++ b/src/test/test_channelpadding.c
 @@ -11,7 +11,7 @@
  #include "channelpadding.h"
  #include "compat_libevent.h"
  #include "config.h"
 -#include 
 +#include 
  #include "compat_time.h"
  #include "main.h"
  #include "networkstatus.h"
 }}}

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

Re: [tor-bugs] #22209 [Core Tor/Tor]: Channelpadding tests fail on kevent-based systems

[Tor Bug Tracker & Wiki]

#22209: Channelpadding tests fail on kevent-based systems
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 95fa7d1cf82c68d7d39f423cf71fa8e097662de3 in master fixes these failures on
 OSX for me, by adding the event_reinit() call.

 I'm leaving this ticket open, though, until we do something about the
 stack trace that the missing event_reinit() had caused.

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

Re: [tor-bugs] #21183 [User Experience]: Basic Usability Issues

[Tor Bug Tracker & Wiki]

#21183: Basic Usability Issues
+-
 Reporter:  ninavizz|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  User Experience |Version:
 Severity:  Normal  | Resolution:
 Keywords:  UX, UI, torbrowser  |  Actual Points:
Parent ID:  #20843  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by mcs):

 * cc: brade, mcs (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] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Let's go with the smaller one for now?  I think that, by using Accept-
 Encoding, we're moving to deprecate the use of .z and other extensions.

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 My initial patch was more or less like that, except that I toggled the
 `ZLIB_METHOD` in the branch where the `Accept-Encoding` header value was
 read.

 I added the flag to the `parse_accept_encoding_header()` in case we wanted
 to do ".zstd", ".gz", and ".lzma" at some point in the future, which
 should make that more trivial to do. I'm OK with either solutions 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] #22218 [Internal Services/Service - trac]: Rename Metrics/Torflow and Metrics/pytorctl to Core Tor/*

[Tor Bug Tracker & Wiki]

#22218: Rename Metrics/Torflow and Metrics/pytorctl to Core Tor/*
--+
 Reporter:  karsten   |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
  |  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by karsten):

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


Comment:

 Renamed, closing.

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

[tor-bugs] #22218 [Internal Services/Service - trac]: Rename Metrics/Torflow and Metrics/pytorctl to Core Tor/*

[Tor Bug Tracker & Wiki]

#22218: Rename Metrics/Torflow and Metrics/pytorctl to Core Tor/*
--+-
 Reporter:  karsten   |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I looked through the list of Trac subcomponents under Metrics/ the other
 day and wondered whether Metrics/Torflow and Metrics/pytorctl really
 belong there or rather under Core Tor/.

 My idea here is that Metrics/* subcomponents all do something with Tor
 network data but that Core Tor/* subcomponents are for anything that keeps
 the Tor network running.  If all Metrics/* subcomponents would disappear
 tonight, the Tor network would still be running, we'd just fly blind.  But
 if Metrics/Torflow disappeared, the Tor network would suddenly be damaged
 a lot, because clients would again need to rely on relays to be honest,
 and we know how that doesn't work out.  It just happens to do measurements
 in order to do its job.

 Regarding Metrics/pytorctl, the main reason for moving that to Core Tor/*
 would be that nothing else in Metrics/* uses it but only Metrics/Torflow
 does.  So if we move one we should move both.

 I discussed this with the component owners, and neither of them objected
 to this change.

 I'll rename components in a minute, right after creating this ticket to
 document 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] #20395 [Metrics/metrics-lib]: metrics-lib should be able to handle large descriptor files

[Tor Bug Tracker & Wiki]

#20395: metrics-lib should be able to handle large descriptor files
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Hmm, can you explain that plan a bit more?  How would we implement
 `DescriptorFile#getDescriptors()` and
 `DescriptorParser#parseDescriptors()` that both return a
 `List` without having read the bytes from the file system?

 And when would the reading and parsing happen and by whom?  Would that not
 be done by the background parsing thread (or in the future threads)
 anymore?

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

Re: [tor-bugs] #20333 [Metrics/metrics-lib]: add descriptor digest to vote and streamline method name

[Tor Bug Tracker & Wiki]

#20333: add descriptor digest to vote and streamline method name
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Great, thanks for the review!  Cherry-picked and pushed.  Closing.

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

Re: [tor-bugs] #22216 [Metrics/CollecTor]: Decide whether to sanitize padding-counts lines

[Tor Bug Tracker & Wiki]

#22216: Decide whether to sanitize padding-counts lines
---+-
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * milestone:  metrics-lib 1.7.0 => CollecTor 1.2.0


Comment:

 Ah, this is unrelated to metrics-lib.  But I agree that we should do this
 really soon.  Moving to the next CollecTor milestone.

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

Re: [tor-bugs] #22140 [Metrics/metrics-lib]: Store raw descriptor contents as UTF-8 encoded Strings rather than byte[]

[Tor Bug Tracker & Wiki]

#22140: Store raw descriptor contents as UTF-8 encoded Strings rather than 
byte[]
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Please, refer to #20395 for the 'lazy reading/providing of bytes' approach
 in order to just have one place for the discussion.

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

Re: [tor-bugs] #20395 [Metrics/metrics-lib]: metrics-lib should be able to handle large descriptor files

[Tor Bug Tracker & Wiki]

#20395: metrics-lib should be able to handle large descriptor files
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Lazy reading/providing of bytes could leave the code referred to in #22140
 and #22141 as is?
 Maybe worth a try; the descriptor only stores the file location and
 position and provides raw bytes only on request by accessing the file
 system and not from memory?

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

Re: [tor-bugs] #22141 [Metrics/metrics-lib]: Deprecate `DescriptorFile` and add relevant information to `Descriptor`

[Tor Bug Tracker & Wiki]

#22141: Deprecate `DescriptorFile` and add relevant information to `Descriptor`
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Trying to keep the topic's discussion in one place, see #20395 comment:5

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

Re: [tor-bugs] #22140 [Metrics/metrics-lib]: Store raw descriptor contents as UTF-8 encoded Strings rather than byte[]

[Tor Bug Tracker & Wiki]

#22140: Store raw descriptor contents as UTF-8 encoded Strings rather than 
byte[]
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Another caveat is that not all writing is yet done through the persistence
 mechanism (cf. #20518).

 But, I think (as suggested in #20395 the FileChannel approach) that maybe
 lazy reading/providing of bytes could leave the code here as is?

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

Re: [tor-bugs] #22216 [Metrics/CollecTor]: Decide whether to sanitize padding-counts lines

[Tor Bug Tracker & Wiki]

#22216: Decide whether to sanitize padding-counts lines
---+---
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by iwakeh):

 * milestone:   => metrics-lib 1.7.0


Comment:

 As the related ticket #22217 this should be in the planning for 1.7.0

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

Re: [tor-bugs] #19607 [Metrics/metrics-lib]: avoid repeated keyword strings

[Tor Bug Tracker & Wiki]

#19607: avoid repeated keyword strings
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * owner:  karsten => iwakeh
 * status:  needs_revision => accepted


Comment:

 I can continue 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] #20333 [Metrics/metrics-lib]: add descriptor digest to vote and streamline method name

[Tor Bug Tracker & Wiki]

#20333: add descriptor digest to vote and streamline method name
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks fine, all checks and tests pass.
 The renaming makes sense; and the decision for a scheme that uses the
 algorithm name as argument could be revisited when there are more
 algorithms to choose from.

 Merge ready!

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

Re: [tor-bugs] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #12898| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

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


Comment:

 Triaging to 0.3.2. Feel free to put it in 0.3.1 if you feel we should do
 it faster.

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

Re: [tor-bugs] #22211 [Core Tor/Tor]: mistaken comment in routerstatus_parse_entry_from_string()

[Tor Bug Tracker & Wiki]

#22211: mistaken comment in routerstatus_parse_entry_from_string()
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.1.x-final


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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: mikeperry (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] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #12898| Points:
 Reviewer:|Sponsor:
--+-
Changes (by nickm):

 * parent:   => #12898


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

Re: [tor-bugs] #19607 [Metrics/metrics-lib]: avoid repeated keyword strings

[Tor Bug Tracker & Wiki]

#19607: avoid repeated keyword strings
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:9 iwakeh]:
 > Replying to [comment:8 karsten]:
 > > Looks good!
 > >
 > > Just one question/suggestion: what do you think about moving
 `serverAtMostOnce` and other parts that are only relevant for parsing
 server descriptors to `ServerDescriptorImpl`?
 >
 > My reasoning was: if a new field is added in `Key` the sets for at-most,
 exactly, etc. are immediately in sight and the new key could be added to
 the appropriate set(s).  But, I don't feel strongly about it; just had to
 make a choice while coding.

 Okay, in that case I'd prefer if we keep descriptor-related things in the
 respective descriptor classes.  Both would work, but that seems
 potentially less confusing in the long run.

 > > Other than that, I'm not entirely sure what you mean by "additional
 lines will go away" in your comment above.  Which lines do you mean?
 >
 > Sounds a little cryptic :-) The lines listed as new in the git stats.
 I'm referring to `protected void check*Keywords(Set keywords)`
 methods, which could be replaced by `protected void check*Keys(Set
 keys)` eventually.

 Makes more sense!

 How do we proceed?  Do you want to apply these changes to all descriptors,
 and I review those changes, or the other way 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

Re: [tor-bugs] #22213 [Core Tor/Tor]: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed

[Tor Bug Tracker & Wiki]

#22213: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 We can, unless we think we're likely to want it in the future for some
 reason.

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Why this approach in particular, and not something more like:
 {{{
 diff --git a/src/or/directory.c b/src/or/directory.c
 index 67c28e1f3e22e4..c1db40ef22cfc2 100644
 --- a/src/or/directory.c
 +++ b/src/or/directory.c
 @@ -3516,8 +3516,9 @@ directory_handle_command_get,(dir_connection_t
 *conn, const char *headers,
  tor_free(header);
} else {
  compression_methods_supported = (1u << NO_METHOD);
 -if (zlib_compressed_in_url)
 -  compression_methods_supported |= (1u << ZLIB_METHOD);
 +  }
 +  if (zlib_compressed_in_url) {
 +compression_methods_supported |= (1u << ZLIB_METHOD);
}

/* Remove all methods that we don't both support. */
 }}}

 (This is a question, not a suggestion -- I'm trying to understand what the
 pros and cons of the two approaches are.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22217 [Metrics/metrics-lib]: Parse new padding-counts lines

[Tor Bug Tracker & Wiki]

#22217: Parse new padding-counts lines
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 As found in today's CollecTor logs:

 {{{
 2017-05-10 06:09:07,711 WARN o.t.c.b.SanitizedBridgesWriter:1212
 Unrecognized line 'padding-counts 2017-05-10 01:48:43 (86400 s) bin-
 size=1 write-drop=1 write-pad=1 write-total=1 read-
 drop=1 read-pad=1 read-total=7 enabled-read-pad=0 enabled-
 read-total=0 enabled-write-pad=0 enabled-write-total=0 max-chanpad-
 timers=0'. Skipping.
 }}}

 We should provide support for parsing these lines in relay descriptors and
 in bridge descriptors if we keep those lines there (#22216).

 Optimistically aiming for 1.7.0.

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

[tor-bugs] #22216 [Metrics/CollecTor]: Decide whether to sanitize padding-counts lines

[Tor Bug Tracker & Wiki]

#22216: Decide whether to sanitize padding-counts lines
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I found this message in CollecTor's logs today:

 {{{
 2017-05-10 06:09:07,711 WARN o.t.c.b.SanitizedBridgesWriter:1212
 Unrecognized line 'padding-counts 2017-05-10 01:48:43 (86400 s) bin-
 size=1 write-drop=1 write-pad=1 write-total=1 read-
 drop=1 read-pad=1 read-total=7 enabled-read-pad=0 enabled-
 read-total=0 enabled-write-pad=0 enabled-write-total=0 max-chanpad-
 timers=0'. Skipping.
 }}}

 We need to decide whether it's okay to keep these lines in sanitized
 bridge descriptors, and if not, how to sanitize them.  I believe it's okay
 to keep them, but I'd like to get confirmation on that.

 Note that we should make this decision soon, because we're currently not
 sanitizing descriptors containing these lines.  That means those bridges
 cannot be found in Atlas and won't be included in any statistics.

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

Re: [tor-bugs] #22190 [Metrics/metrics-lib]: DescriptorIndexCollector does not delete extraneous local files if remote paths with leading /

[Tor Bug Tracker & Wiki]

#22190: DescriptorIndexCollector does not delete extraneous local files if 
remote
paths with leading /
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Looks good, merged!  (In the future, please also provide a change log
 entry.  I might feel the urge to rephrase that to use the same writing
 style for all change log entries, but rewriting is often easier than
 writing.)  Thanks!  Closing.

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

Re: [tor-bugs] #22062 [Metrics/Onionoo]: Bad requests do not add the Access-Control-Allow-Origin header

[Tor Bug Tracker & Wiki]

#22062: Bad requests do not add the Access-Control-Allow-Origin header
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 Replying to [comment:1 karsten]:
 > Before I try out whether this works and what it might break in
 unexpected ways: what's the use case for including these headers in
 responses to bad requests?
 I can't speak about the Cache-Control header but including the Access-
 Control-Allow-Origin header for responses to bad requests would allow
 browsers to fully load the response and prevent CORS errors from showing
 up in the console.

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 Possible fix available in
 https://gitlab.com/ahf/tor/merge_requests/10/diffs

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

Re: [tor-bugs] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

[Tor Bug Tracker & Wiki]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
+
 Reporter:  asn |  Owner:  asn
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224 ed25519  |  Actual Points:
Parent ID:  #21888  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+
Changes (by asn):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

[Tor Bug Tracker & Wiki]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
+
 Reporter:  asn |  Owner:  asn
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224 ed25519  |  Actual Points:
Parent ID:  #21888  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+

Comment (by asn):

 Here is a review by Yawning:
 {{{
 12:46 < Yawning> the donna code will crash when built with sse2
 12:48 < asn> how do i build with sse2?
 12:49 < Yawning> you do a 32 bit intel build on something modern
 12:49 < Yawning> iirc
 12:49 < Yawning> I don't remember what I did
 12:50 < Yawning> #if defined(__SSE2__) && !defined(CPU_X86_64)
 12:51 < Yawning> or you could add ALIGN(16) in the right place to `
 ge25519 Point, Result;`
 12:52 < Yawning> or since modern x86 has fast unaligned load/stores anyway
 12:52 < Yawning> you could go and change the places that would cause it to
 crash, so the alignment requirement isn't there
 12:53 < Yawning> though I guess people building tor for 32 bit intel are
 running on potatos
 12:54 < Yawning> does doing the validation as part of
 `ed25519_public_from_base64` mean that when parsing the consensus it will
 eventually do
  several thousand scalar multiplys
 }}}

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

Re: [tor-bugs] #21183 [User Experience]: Basic Usability Issues

[Tor Bug Tracker & Wiki]

#21183: Basic Usability Issues
+-
 Reporter:  ninavizz|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  User Experience |Version:
 Severity:  Normal  | Resolution:
 Keywords:  UX, UI, torbrowser  |  Actual Points:
Parent ID:  #20843  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arma):

 * cc: linda (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] #22190 [Metrics/metrics-lib]: DescriptorIndexCollector does not delete extraneous local files if remote paths with leading /

[Tor Bug Tracker & Wiki]

#22190: DescriptorIndexCollector does not delete extraneous local files if 
remote
paths with leading /
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review my [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/log/?h=task-22190 task-22190 branch] (three commits).

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

Re: [tor-bugs] #22063 [Metrics/Onionoo]: Document that only the first qualified search term applies

[Tor Bug Tracker & Wiki]

#22063: Document that only the first qualified search term applies
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  task | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

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

Re: [tor-bugs] #22210 [Core Tor/Tor]: circuit_is_acceptable is slow due to IP and fingerprint parsing

[Tor Bug Tracker & Wiki]

#22210: circuit_is_acceptable is slow due to IP and fingerprint parsing
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.12
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:22210 teor]:
 > 43.76 s   34.7%   1.30 s connection_ap_can_use_exit
 > 39.51 s   31.3%   574.00 ms   node_get_by_nickname
 > 38.93 s   30.9%   764.00 msnode_get_by_hex_id

 This case happens because they're hidden service descriptor lookups, so
 they're general (exit) streams yet they have conn->chosen_exit_name set.

 That's a surprising amount of time in hex_digest_nickname_decode(), but I
 guess with all the strlcpy's, etc, that it does, it shouldn't be that
 surprising.

 You're right that it's inefficient here, since the logic is "consider a
 given circuit, and then reparse what exit node this conn says it's for,
 and then see if that circuit ends at that exit node", and in theory we
 don't need to keep reparsing. I would be tempted to try to take a step
 farther back though and figure out if there's a way to call the broader
 "how's it going, are any streams ready to be attached to circuits yet"
 function more sparingly.

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

Re: [tor-bugs] #22214 [Core Tor/Tor]: When authority certificates expire, give a better error message (was: Certificate downloads are broken)

[Tor Bug Tracker & Wiki]

#22214: When authority certificates expire, give a better error message
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * cc: ahf (removed)
 * severity:  Major => Normal
 * milestone:  Tor: 0.3.1.x-final => Tor: unspecified


Comment:

 Oops, turns out we started the test network a year ago, and so the
 authority certificates have expired. The log message could be easier to
 understand.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+-
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 {{{
   /* Is it marked as owned-by-someone-else? */
   if (networkstatus_nickname_is_unnamed(nickname)) {
 log_info(LD_GENERAL, "The name %s is listed as Unnamed: there is some
 "
  "router that holds it, but not one listed in the current "
  "consensus.", escaped(nickname));
 return NULL;
   }
 }}}

 The Unnamed flag is long gone from the world, now that proposal 235 has
 been merged. So we can simplify node_get_by_nickname() by getting rid of
 this function, plus the discussions about the Named flag.

 If we want to get adventuresome, I also see
 {{{
 int *named_flag; /* Index of the flag "Named" for votes[j] */
 int *unnamed_flag; /* Index of the flag "Unnamed" for votes[j] */
 }}}
 in networkstatus_compute_consensus(). And more generally,
 {{{
 $ grep Named *.c
 circuitbuild.c: * If verbose_names is false, give nicknames for
 Named routers and hex
 dirserv.c:/* 1  Historically used to indicate Named */
 dirvote.c:int *named_flag; /* Index of the flag "Named" for votes[j]
 */
 dirvote.c:if (!strcmp(fl, "Named"))
 dirvote.c:/* Named and Unnamed get treated specially */
 dirvote.c:if (!strcmp(fl, "Named")) {
 networkstatus.c: * nickname, but the Named flag isn't set for that router.
 */
 nodelist.c: * nickname, but the Named flag isn't set for that router. */
 nodelist.c: "but none is listed as Named in the directory
 consensus. "
 routerparse.c:  else if (!strcmp(tok->args[i], "Named"))
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22214 [Core Tor/Tor]: Certificate downloads are broken

[Tor Bug Tracker & Wiki]

#22214: Certificate downloads are broken
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On master, I have a test directory authority on i386 macOS 10.12 which
 can't download certificates. The directory authority had been down
 (asleep) for a while, and on update to the new master, it said:

 {{{
 May 10 19:02:28.645 [notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83)
 running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11,
 Liblzma N/A, and Libzstd N/A.
 ...
 May 10 19:03:15.000 [warn] Got a certificate for lemonpeasy, but we
 already have it. Maybe they haven't updated it. Waiting for a while.
 May 10 19:03:15.000 [warn] Got a certificate for triplepeak, but we
 already have it. Maybe they haven't updated it. Waiting for a while.
 May 10 19:03:15.000 [warn] Got a certificate for Betty, but we already
 have it. Maybe they haven't updated it. Waiting for a while.
 May 10 19:03:15.000 [warn] Got a certificate for Evelyn, but we already
 have it. Maybe they haven't updated it. Waiting for a while.
 May 10 19:03:15.000 [warn] Got a certificate for albert, but we already
 have it. Maybe they haven't updated it. Waiting for a while.
 May 10 19:03:15.000 [warn] Got a certificate for missionary, but we
 already have it. Maybe they haven't updated it. Waiting for a while.
 ...
 May 10 19:04:16.000 [warn] Looks like we need to download a new
 certificate from authority 'triplepeak' at ...
 May 10 19:04:16.000 [warn] Looks like we need to download a new
 certificate from authority 'Betty' at ...
 }}}

 I suspect this bug might have been introduced in 0.3.1. Or, it might be
 due to the fact our test network consensus is broken. Or it could be
 because we're on mixed versions (which should work).

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

Re: [tor-bugs] #22210 [Core Tor/Tor]: circuit_is_acceptable is slow due to IP and fingerprint parsing

[Tor Bug Tracker & Wiki]

#22210: circuit_is_acceptable is slow due to IP and fingerprint parsing
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.12
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:1 arma]:
 > {{{
 > const int family = tor_addr_parse(,
 conn->socks_request->address);
 > }}}

 It looks like we could pretty easily only do that tor_addr_parse call in
 the two places below it where we would actually use the value of family --
 that is,
 * (a) for a one-hop circuit where we've set chosen_exit_name and we don't
 have a digest for the exit, which should be rare if it ever happens, and
 * (b) when origin_circ->prepend_policy is set, meaning we've already
 received a surprising exit policy failure on that circuit and called
 adjust_exit_policy_from_exitpolicy_failure() 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] #22190 [Metrics/metrics-lib]: DescriptorIndexCollector does not delete extraneous local files if remote paths with leading /

[Tor Bug Tracker & Wiki]

#22190: DescriptorIndexCollector does not delete extraneous local files if 
remote
paths with leading /
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  assigned => accepted


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

Re: [tor-bugs] #22190 [Metrics/metrics-lib]: DescriptorIndexCollector does not delete extraneous local files if remote paths with leading /

[Tor Bug Tracker & Wiki]

#22190: DescriptorIndexCollector does not delete extraneous local files if 
remote
paths with leading /
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * owner:  metrics-team => iwakeh
 * status:  new => assigned


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

Re: [tor-bugs] #22210 [Core Tor/Tor]: circuit_is_acceptable is slow due to IP and fingerprint parsing

[Tor Bug Tracker & Wiki]

#22210: circuit_is_acceptable is slow due to IP and fingerprint parsing
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.12
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:22210 teor]:
 > 2.10 min  100.0%  6.26 scircuit_is_acceptable
 > 58.93 s   46.7%   1.05 s tor_addr_parse

 > 1. Parsing IP addresses from strings out of node descriptors

 To be precise, it looks like this one is from
 {{{
 const int family = tor_addr_parse(,
 conn->socks_request->address);
 }}}
 which is actually parsing IP addresses from strings in the socks request,
 not the node descriptor.

 For how that code came to be that way, see commit 2b22c0ae from #7582.

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

Re: [tor-bugs] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:11 karsten]:
 > [snip]
 > > > How about this: whenever we can't parse a descriptor, we include a
 `Descriptor` instance with the raw contents we cannot parse in the
 descriptor queue.  And we include a new method `Descriptor#getException()`
 that returns the `DescriptorParseException` that we ran into, or `null` if
 we didn't run into an exception while parsing.
 > > >
 > > > Similarly, if we run into an exception while downloading files from
 a remote server or while reading files from the file system, so before
 splitting contents into descriptor-sized chunks and attempting to parse
 those, we include a `Descriptor` instance without descriptor contents and
 with just the exception.
 > >
 > > If we were using java8, I'd suggest using
 java.util.Optional.
 >
 > It seems like we won't have Java 8 in the near future (see #19622), but
 can you elaborate how that would help here?

 I didn't sink to much time into the possible design options.  It'll also
 mean a change from the blocking method calls to always returning
 something.   Actually, that would be achievable with `Future`s much
 better, where the API user decides when to wait.  But, just some random
 thoughts here, no change proposal intended.

 >
 > > Actually your suggestions goes in that direction, too.
 > > Maybe, a new descriptor class InvalidDescriptor could be useful here?
 It would be accessible via the instanceof-method and have limited
 information: at least the Exception and maybe also its origin (url, path),
 in case of a file also bytes.
 >
 > I briefly thought about such a new type for this case, too.  But the
 only reason I found was that there wouldn't be a method
 `Descriptor#getException()` that sometimes returns `null`.  However,
 adding such a type would mean that whoever is interested in
 exceptions/errors would have to do another `instanceof` check and
 downcast.  Are there other aspects?

 Yes, the usefulness of one or the other approach depends on the
 programming style of the API using client.  I don't feel strongly about
 either.

 Regarding the methods returning a collection type (like unrecognized
 fields for torperf/onionperf or the get-exception method above), I think
 it would be more convenient to return an empty (immutable) collection of
 the wanted type (like
 
[https://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#emptySet%28%29
 emptySet] instead of `null`.

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

Re: [tor-bugs] #19607 [Metrics/metrics-lib]: avoid repeated keyword strings

[Tor Bug Tracker & Wiki]

#19607: avoid repeated keyword strings
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:8 karsten]:
 > Looks good!
 >
 > Just one question/suggestion: what do you think about moving
 `serverAtMostOnce` and other parts that are only relevant for parsing
 server descriptors to `ServerDescriptorImpl`?

 My reasoning was: if a new field is added in `Key` the sets for at-most,
 exactly, etc. are immediately in sight and the new key could be added to
 the appropriate set(s).  But, I don't feel strongly about it; just had to
 make a choice while coding.

 >
 > Other than that, I'm not entirely sure what you mean by "additional
 lines will go away" in your comment above.  Which lines do you mean?

 Sounds a little cryptic :-) The lines listed as new in the git stats.  I'm
 referring to `protected void check*Keywords(Set keywords)`
 methods, which could be replaced by `protected void check*Keys(Set
 keys)` eventually.

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

Re: [tor-bugs] #20683 [Applications/Tor Browser]: Integrate selfrando into the alpha Linux 64bit builds

[Tor Bug Tracker & Wiki]

#20683: Integrate selfrando into the alpha Linux 64bit builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, GeorgKoppen201704, |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

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


Comment:

 Okay, I added support for the signed tag (commit
 8fe0e322b950efa2456502428bee66dde8b4948a) and bumped the `elfutils`
 version for our alphas as well (commit
 3e752843dfa39beec844822c9f6c3dd1f80355ea). I think we are done 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] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 Replying to [comment:16 arma]:
 > So if we do the next step, which would be setting the timestamp to 2037
 or whatever, we will disable this hack. Are we still using the hack much?

 It turns out we have a way to check -- when relays publish a new
 descriptor, they can include a header:
 {{{
 case DIR_PURPOSE_UPLOAD_DIR: {
   const char *why = router_get_descriptor_gen_reason();
 [...]
   if (why) {
 smartlist_add_asprintf(headers, "X-Desc-Gen-Reason: %s\r\n", why);
   }
 }}}

 So I instrumented moria1 like so:
 {{{
 diff --git a/src/or/directory.c b/src/or/directory.c
 index 67c28e1..4eb461f 100644
 --- a/src/or/directory.c
 +++ b/src/or/directory.c
 @@ -4462,6 +4462,12 @@ directory_handle_command_post,(dir_connection_t
 *conn, co
  const char *msg = "[None]";
  uint8_t purpose = authdir_mode_bridge(options) ?
ROUTER_PURPOSE_BRIDGE : ROUTER_PURPOSE_GENERAL;
 +{
 +  char *genreason = http_get_header(headers, "X-Desc-Gen-Reason: ");
 +  log_info(LD_DIRSERV,
 +   "New descriptor post, because: %s",
 +   genreason ? genreason : "not specified");
 +}
  was_router_added_t r = dirserv_add_multiple_descriptors(body,
 purpose,
   conn->base_.address, );
  tor_assert(msg);
 }}}

 Over the course of about 15 minutes, I see:
 {{{
 $ grep "New descriptor post, because:" moria1-info|cut -d: -f5-|sort|uniq
 -c
  24  bandwidth has changed
   5  config change
  10  DirPort found reachable
  88  not listed in consensus
9017  not specified
  20  ORPort found reachable
   9  rotated onion key
  79  time for new descriptor
  15  version listed in consensus is quite old
 }}}

 So, initial conclusion is "yes, it's still used".

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

Re: [tor-bugs] #20761 [Applications/Tor Launcher]: Tor Browser 6.5a4 is ignoring additional SocksPorts

[Tor Bug Tracker & Wiki]

#20761: Tor Browser 6.5a4 is ignoring additional SocksPorts
---+
 Reporter:  gk |  Owner:  mcs
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201705   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+
Changes (by gk):

 * keywords:  TorBrowserTeam201705R => TorBrowserTeam201705
 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #22192 [User Experience/Website]: Update tor-mirrors.csv / mirror site

[Tor Bug Tracker & Wiki]

#22192: Update tor-mirrors.csv / mirror site
-+---
 Reporter:  Samdney  |  Owner:  Sebastian
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by Samdney):

 * 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