Re: [tor-bugs] #23499 [Core Tor/Tor]: dir server responses should include a Date: header even when not responding 200

[Tor Bug Tracker & Wiki]

#23499: dir server responses should include a Date: header even when not 
responding
200
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  new => needs_review


Comment:

 My {{{bug23499}}} branch resolves this issue.

 The only tricky part is that it doesn't include the Date: header if you're
 not a relay or a bridge, since maybe we'll end up in this function through
 some sort of "go away, why are you asking me directory questions" path,
 and I don't want to tell people my Date then.

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

Re: [tor-bugs] #23499 [Core Tor/Tor]: dir server responses should include a Date: header even when not responding 200

[Tor Bug Tracker & Wiki]

#23499: dir server responses should include a Date: header even when not 
responding
200
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I am running the new code on moria1, and here is a sample output:
 {{{
 $ telnet 128.31.0.34 9031
 Trying 128.31.0.34...
 Connected to 128.31.0.34.
 Escape character is '^]'.
 GET / HTTP/1.0

 HTTP/1.0 404 Not found
 Date: Thu, 14 Sep 2017 03:26:56 GMT

 }}}

 Hopefully somebody can check whether that's legit http. :)

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

Re: [tor-bugs] #23509 [Metrics/Atlas]: implement family-level pages showing aggregated graphs

[Tor Bug Tracker & Wiki]

#23509: implement family-level pages showing aggregated graphs
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by cypherpunks):

 Replying to [comment:2 arma]:
 > Though heck, if we're thinking of it as an onionoo lookup, I wonder if
 there are already onionoo lookups for country and AS, and then we're done?

 yes there are, example for AS:
 https://atlas.torproject.org/#search/as:AS396507
 example for country:
 https://atlas.torproject.org/#search/country:tr

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

Re: [tor-bugs] #23499 [Core Tor/Tor]: dir server responses should include a Date: header even when not responding 200

[Tor Bug Tracker & Wiki]

#23499: dir server responses should include a Date: header even when not 
responding
200
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 Replying to [comment:3 arma]:
 > Hopefully somebody can check whether that's legit http. :)

 That looks fine.

 > The only tricky part is that it doesn't include the Date: header if
 you're not a relay or a bridge, since maybe we'll end up in this function
 through some sort of "go away, why are you asking me directory questions"
 path, and I don't want to tell people my Date then.

 This is fine for HTTP/1.0 which is what is used now.  If the daemon ever
 migrates to HTTP/1.1, the behavior will likely need revisiting (RFC 7231
 7.1.1.2).

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

Re: [tor-bugs] #15508 [Metrics/Atlas]: uptime sorting should be numeric and take the actual unit into account (was: bandwidth sorting should be numeric and take the actual unit into account)

[Tor Bug Tracker & Wiki]

#15508: uptime sorting should be numeric and take the actual  unit into account
---+-
 Reporter:  cypherpunks|  Owner:  phw
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Old description:

> Atlas bandwidth sorting is basically broken because it does not use
> numeric sorting.
>
> example:
> https://atlas.torproject.org/#search/contact:torservers
>
> shows:
> {{{
> 63.62 KB/s
> 512 KB/s
> 31.69 MB/s
> }}}

New description:

 Atlas bandwidth sorting is basically broken because it does not use
 numeric sorting.

 example:
 https://atlas.torproject.org/#search/contact:torservers

 shows:
 {{{
 63.62 KB/s
 512 KB/s
 31.69 MB/s
 }}}

 Update: Bandwidth and IP address sorting are now fixed, but uptime sorting
 still needs addressing.

--

Comment (by irl):

 The patch from comment:5 has been merged and deployed. Thanks. (:

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

Re: [tor-bugs] #23383 [Metrics/Website]: Apply Tor style guide to redesigned Tor Metrics website

[Tor Bug Tracker & Wiki]

#23383: Apply Tor style guide to redesigned Tor Metrics website
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Turns out it was not too hard to create the new tile files myself based on
 what I got from antonela earlier. Rebased, pushed, and
 [https://metrics.torproject.org/ deployed] everything. That concludes this
 ticket. Thanks to everyone 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] #23025 [Applications/Tor Browser]: Flags to increase hardening on macOS

[Tor Bug Tracker & Wiki]

#23025: Flags to increase hardening on macOS
--+---
 Reporter:  arthuredelstein   |  Owner:  arthuredelstein
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709R |  Actual Points:
Parent ID:  #21448| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 Hm. I am a bit hesitant using `CPPFLAGS` here as they are (strictly
 speaking) not preprocessor related. Would you mind putting the flags into
 something like `HARDENING_FLAGS` adding it as we add `FLAGS`?

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

Re: [tor-bugs] #23160 [Metrics/Atlas]: Adding flag makes list empty while seach result contains the flag

[Tor Bug Tracker & Wiki]

#23160: Adding flag makes list empty while seach result contains the flag
---+-
 Reporter:  qbi|  Owner:  irl
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by irl):

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


Comment:

 It actually appears that all of the filters are broken.

 I'm going to close this issue, and open a more general one.

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

Re: [tor-bugs] #20955 [Applications/Tor Browser]: Tor Browser memory hardening

[Tor Bug Tracker & Wiki]

#20955: Tor Browser memory hardening
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 FreeGuard entered the scene recently: https://arxiv.org/pdf/1709.02746.pdf
 (with comparisons of Die Harder and the OpenBDS allocator).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23510 [Metrics/Atlas]: Filters in search results table always return no results

[Tor Bug Tracker & Wiki]

#23510: Filters in search results table always return no results
---+-
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Options include:

 * Fix them
 * Just disable them

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

Re: [tor-bugs] #23296 [Metrics/Atlas]: atlas web (mpdile) "Effective Family Members" window is too small

[Tor Bug Tracker & Wiki]

#23296: atlas web (mpdile) "Effective Family Members" window is too small
---+
 Reporter:  toralf |  Owner:  irl
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Trivial| Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Large redesign of Atlas is pending, to integrate with the Metrics website.
 As such, issues with the existing design (CSS, etc) will not be given any
 priority. I will ensure that the relevant testing is done for the new
 design once it is nearing completion.

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

Re: [tor-bugs] #22591 [Applications/Tor Browser]: Clicking on a comment does not directly jump to it (although the blog seems to try)

[Tor Bug Tracker & Wiki]

#22591: Clicking on a comment does not directly jump to it (although the blog 
seems
to try)
--+--
 Reporter:  gk|  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-usability-website
 * component:  Webpages/Blog => Applications/Tor Browser
 * parent:  #22013 =>


Comment:

 Replying to [comment:28 hiro]:
 > Gk I have disabled JS in the dev blog for the normal template. However
 if you are logged in, the drupal toolbar loads some javascript libraries,
 and so does the admin template.
 >
 > This means it might be an issue w/ how firefox loads some function of
 underscorejs.org (and other libraries loaded by trac.tpo and other
 websites) or w/ firefox itself.
 >
 > Also could it be something that is solved in newer versions of firefox?

 That's still an issue in the latest Firefox nightly.

 > Also please let me know what we should do regarding this ticket. I do
 not think we should track this as a blog issue, but I'd be happy to debug
 it more if we really think it could be useful.

 If you feel that's not blog business but Tor Browser/Firefox one I am fine
 setting the component accordingly. In fact let me do that right away.

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

Re: [tor-bugs] #22591 [Applications/Tor Browser]: Clicking on a comment does not directly jump to it (although the blog seems to try)

[Tor Bug Tracker & Wiki]

#22591: Clicking on a comment does not directly jump to it (although the blog 
seems
to try)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  reopened => assigned
 * owner:  hiro => tbb-team


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

Re: [tor-bugs] #22591 [Applications/Tor Browser]: Clicking on a comment does not directly jump to it (although the blog seems to try)

[Tor Bug Tracker & Wiki]

#22591: Clicking on a comment does not directly jump to it (although the blog 
seems
to try)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hiro):

 Hi gk, I am not sure it is a blog issue, but I am not sure it's a firefox
 issue either. Might be something to do with some function in that library.

 Maybe, before investigating this as a browser bug, I can try replace that
 w/ standard jquery, or remove it completely (better option) as JS is only
 used to submit comments. What do you think?

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

Re: [tor-bugs] #22805 [Core Tor/Tor]: Remove or_circuit_t.is_first_hop, because it's not accurate any more

[Tor Bug Tracker & Wiki]

#22805: Remove or_circuit_t.is_first_hop, because it's not accurate any more
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, security-review, |  Actual Points:  .3
  review-group-23|
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by asn):

 Hello. I'm not very experienced with this channel stuff, so I might be
 wrong but here are my review comments:

 - In comment:1, teor said `we don't want to flag CREATE_FAST users as
 clients any more.`. However, I see that in `command_process_create_cell()`
 we unconditionally call `channel_mark_client(chan);` if we receive a
 `CREATE_FAST` cell. It also contains a comment to that effect, which might
 be outdated given what teor said above. Does it also need a
 `connection_or_digest_is_known_relay(chan->identity_digest)` like the call
 above it? Or perhaps it's ok as is?

 - The comment in `circuit_expire_old_circuits_serverside()` is now
 outdated since it still mentions `create_fast` as an identifier.

 - The branch contains `aa83959ce5` on top which seems to be related to the
 merged #21585. It seemed unrelated to this ticket so I didn't review it.
 Let me know if I should take a look please.

 FWIW, running `test-full` succeeds with the branch.

 Marking this as needs_revision just for the minor comment fix 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] #21636 [Metrics/Atlas]: Add a NoEdConsensus flag to Atlas

[Tor Bug Tracker & Wiki]

#21636: Add a NoEdConsensus flag to Atlas
---+
 Reporter:  teor   |  Owner:  RaBe
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 I have written a patch that uncomments the code and uses the question mark
 icon we already had. The tooltip text seems to reflect what is in dir-
 spec.

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

Re: [tor-bugs] #21958 [Metrics/Atlas]: add first_seen field to relay and search results page

[Tor Bug Tracker & Wiki]

#21958: add first_seen field to relay and search results page
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Fixed in git, deploying shortly

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

Re: [tor-bugs] #22185 [Metrics/Atlas]: add red unmeasured icon to properties

[Tor Bug Tracker & Wiki]

#22185: add red unmeasured icon to properties
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by irl):

 Any chance of a 16x16 PNG icon for this?

 Probably doesn't need to be red. In my mind, red icons are only for "calls
 to action" from the operator where it's something they need to fix
 themselves.

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

Re: [tor-bugs] #22146 [Metrics/Atlas]: move platform and consensus weight before family lists

[Tor Bug Tracker & Wiki]

#22146: move platform and consensus weight before family lists
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Fixed in git, will deploy shortly

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

Re: [tor-bugs] #9814 [Metrics/Atlas]: Atlas should make clear when relay details come from outdated consensus

[Tor Bug Tracker & Wiki]

#9814: Atlas should make clear when relay details come from outdated consensus
---+--
 Reporter:  wfn|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

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


Comment:

 I believe we have actually fixed this. We have "Last Known" inserted when
 it's not running and we have the red/green indicators. Feel free to re-
 open if you disagree.

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

Re: [tor-bugs] #6787 [Metrics/Atlas]: Make homepage more informative/intuitive

[Tor Bug Tracker & Wiki]

#6787: Make homepage more informative/intuitive
---+-
 Reporter:  ioerror|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by irl):

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


Comment:

 I believe we'll fix this when we merge with the metrics website, for now
 this ticket doesn't really serve much purpose.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23511 [Metrics/Atlas]: Add top 10 relays per country

[Tor Bug Tracker & Wiki]

#23511: Add top 10 relays per country
---+-
 Reporter:  irl|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Requested via twitter:
 https://twitter.com/yawnbox/status/907466172689297408

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile (was: Neuter NetworkInformatin API on Tor Browser Mobile)

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  task   | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

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

Re: [tor-bugs] #22591 [Applications/Tor Browser]: Clicking on a comment does not directly jump to it (although the blog seems to try)

[Tor Bug Tracker & Wiki]

#22591: Clicking on a comment does not directly jump to it (although the blog 
seems
to try)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:31 hiro]:
 > Hi gk, I am not sure it is a blog issue, but I am not sure it's a
 firefox issue either. Might be something to do with some function in that
 library.
 >
 > Maybe, before investigating this as a browser bug, I can try replace
 that w/ standard jquery, or remove it completely (better option) as JS is
 only used to submit comments. What do you think?

 Well, I have the same problem with Trac (see comment:27). Once I disable
 JS the jumping works but with it on there are issues as well. That said, I
 am happy to have less JS on the blog (and/or on Trac), so go for that if
 you can. :)

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

Re: [tor-bugs] #23485 [Webpages/Website]: Update alternative donation page for 2017.

[Tor Bug Tracker & Wiki]

#23485: Update alternative donation page for 2017.
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  crowdfunding  |  Actual Points:
Parent ID:  #23482| Points:
 Reviewer:|Sponsor:
--+

Comment (by hiro):

 Also while we are at this. The donation page uses some 3rd-party services
 for collecting donations. These services use cookies. Should we add a
 message warning our users according to the EU cookie policy?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-bug-bounty, congestion-attack,
 Severity:  Normal   |  research, watermark, tor-stats, guard-discovery
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We received a tor bug bounty report from `jaym` about a congestion attack
 variant that can cause  bandwidth stats watermark.

 The bug uses the fact that Tor increments the ''read bytes counter''
 before adding the cell to the output buffer: If the circuit gets killed
 before the cell gets relayed to the next hop, then the ''write bytes
 counter'' will never be updated, making the ''read bytes counter'' having
 a higher value than the ''write bytes counter''. The attacker could
 exploit this assymetry to find relays using their bandwidth graph.

 The attacker can kill the circuit using the OOM killer by saturating its
 output queue with cells until `circuits_handle_oom()` gets called and
 kills the circuit.

 We should figure out whether this attack is practical (the paper claims it
 is) and whether it's worthwhile fixing it. Just fixing this issue won't
 solve the general issue of congestion attacks, and it might even allow
 other kinds of attacks.

 The most practical fix right now seem to be to hack circuit_handle_oom()`
 to actually decrement the read counters before killing a circuit. However,
 that's a very specific fix that might solve this very specific bug, but
 leave the rest of the bug class open.

 Another approach would be removing the bandwidth graphs, or aggregating
 them over a greater period of time, or adding noise. We should consider
 these approaches carefully since bandwidth graphs see great use by
 academic papers and also by relay operators (to gauge their contribution).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23513 [Applications/Tor Browser]: When there is an error while starting a container, we don't clean up the container files

[Tor Bug Tracker & Wiki]

#23513: When there is an error while starting a container, we don't clean up the
container files
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201709
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 When there is an error starting a container (for instance due to #23039),
 we exit with many lines of errors such as:
 {{{
 cannot unlink file for /home/user/tor-browser-build/tmp/rbm-ZSCgVC/rbm-
 
containers/5974d3088083038cf834dd21ae48552798cf288bc8949e376e617583dc8c2886/rootfs/lib/x86_64
 -linux-gnu/libnss_files.so.2: Permission denied at
 /usr/share/perl5/vendor_perl/File/Temp.pm line 1616.
 cannot restore permissions to 0120777 for /home/user/tor-browser-build/tmp
 /rbm-ZSCgVC/rbm-
 
containers/5974d3088083038cf834dd21ae48552798cf288bc8949e376e617583dc8c2886/rootfs/lib/x86_64
 -linux-gnu/libnss_files.so.2: Permission denied at
 /usr/share/perl5/vendor_perl/File/Temp.pm line 1616.
 cannot unlink file for /home/user/tor-browser-build/tmp/rbm-ZSCgVC/rbm-
 
containers/5974d3088083038cf834dd21ae48552798cf288bc8949e376e617583dc8c2886/rootfs/lib/x86_64
 -linux-gnu/libncursesw.so.5: Permission denied at
 /usr/share/perl5/vendor_perl/File/Temp.pm line 1616.
 }}}

 And the files from the container are not removed.

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

Re: [tor-bugs] #23077 [Core Tor/Tor]: Channelpadding tests rely on actual time; can fail

[Tor Bug Tracker & Wiki]

#23077: Channelpadding tests rely on actual time; can fail
--+
 Reporter:  nickm |  Owner:  mikeperry
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  unittest, channelpadding  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 No problem, Mike!  Merged to 0.3.1 and forward.

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

Re: [tor-bugs] #23505 [Webpages/Website]: Update torproject.org title / tab

[Tor Bug Tracker & Wiki]

#23505: Update torproject.org title / tab
--+
 Reporter:  steph |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by hiro):

 Do we have to change all the pages from "Tor Project: " to
 "Tor Project | "? I assume we should but I'd just like to
 confirm 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] #23493 [Core Tor/Tor]: IPv6 v3 Single Onion Services fail with a bug warning

[Tor Bug Tracker & Wiki]

#23493: IPv6 v3 Single Onion Services fail with a bug warning
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:4 teor]:
 > Replying to [comment:2 dgoulet]:
 > > Oh dear... hmmm proposal 224 makes IPv4 *mandatory* in order to extend
 to the relay and seems in this case you have IPv6 only?...
 >
 > The single onion service in this test can only make IPv6 connections.
 > This works for v2, but not v3.
 >
 > > Is this something we want to allow right now or should I say simply
 possible to have NO IPv4 for a relay?
 >
 > We can make IPv6 work with single-hop client and service connections to
 intro and rend points. It works for v2 single onion services. We talked
 about it for v3, but it never made it into the prop224 spec.

 Yeah, it will make it with #23502. Spec and code change for that matter.
 Basically, any link specifiers for the IP (in descriptor) and RP (in INTRO
 cell) were requiring an IPv4 else you couldn't use the relay.

 >
 > Edit: I opened #23507 with a list of steps we can add to the spec. We
 should implement them in this ticket!
 >
 > I don't see how #23502 is a dependency. Initiating clients/services
 should always include IPv4 and IPv6, even if they wouldn't use them (step
 0). And responding clients/services should use a direct connection if
 available, or a 3-hop connection if not (steps 1 & 2).

 In this scenario, no IPv4 were available with this chutney test so the
 code was just saying "nope" and you wouldn't pass step 0 which is what
 #23502 is addressing.

 Then considering the above fixed, you are right that if the chosen IP
 can't be reached via a direct connection, we fallback to 3-hop, see
 `pick_intro_point()`. However, for the RP, I'm not sure there is a
 fallback, even for v2... See `pick_rendezvous_node()`, that fallback
 concept is only if `ENABLE_TOR2WEB_MODE`.

 The second thing here that I want to raise is that including both IPv4 and
 IPv6 is *not* possible right now within tor and the reason is that from a
 `node_t`, we create an `extend_info_t` object used for opening a circuit
 and that object can only take one type of address, v4 or v6 (`tor_addr_t
 addr`). Furthermore, the `extend_cell_format()` simply doesn't care at all
 about IPv6. (#22810 is probably relevant and should be expanded to IPv6
 also).

 So, IPv6 can only be used in a direct connection really and is entirely
 ignored for 3-hop.

 If you can confirm the above, we should open tickets about all that.

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

[tor-bugs] #23514 [Internal Services/Tor Sysadmin Team]: Please update my PGP public key

[Tor Bug Tracker & Wiki]

#23514: Please update my PGP public key
-+-
 Reporter:  gk   |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Another year, another subkey update. Please fetch the new subkeys for
 LDAP.

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

Re: [tor-bugs] #23513 [Applications/Tor Browser]: When there is an error while starting a container, we don't clean up the container files

[Tor Bug Tracker & Wiki]

#23513: When there is an error while starting a container, we don't clean up the
container files
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by boklm):

 * Attachment "0001-Bug-23513-run-remote_finish-when-there-was-an-
 error-.patch" added.


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

Re: [tor-bugs] #23513 [Applications/Tor Browser]: When there is an error while starting a container, we don't clean up the container files

[Tor Bug Tracker & Wiki]

#23513: When there is an error while starting a container, we don't clean up the
container files
+--
 Reporter:  boklm   |  Owner:  boklm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm, TorBrowserTeam201709 => tbb-rbm,
   TorBrowserTeam201709R
 * status:  assigned => needs_review


Comment:

 I attached a patch for `rbm.git` fixing this issue.

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

Re: [tor-bugs] #23506 [Core Tor/Tor]: clock_skew_warning should be a bootstrap event

[Tor Bug Tracker & Wiki]

#23506: clock_skew_warning should be a bootstrap event
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID:  #23508 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 This looks fine to me, except for some minor function documentation
 issues.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   |   Keywords:  doc
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 doc/HACKING/GettingStarted.md says "you might like reading doc/HACKING",
 which is reader obviously is already doing :)

 Let' remove the paragraph containing this line as it adds no information
 at all.

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

Re: [tor-bugs] #23347 [Core Tor/Tor]: Using bridges is not working anymore with tor on master

[Tor Bug Tracker & Wiki]

#23347: Using bridges is not working anymore with tor on master
--+
 Reporter:  gk|  Owner:  teor
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bootstrap, tor-bridge-client  |  Actual Points:  1
Parent ID:| Points:  0.5
 Reviewer:  isis  |Sponsor:
--+
Changes (by nickm):

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


Comment:

 I ran into a crash bug here: if you have Bridge lines in your
 configuration, but UseBridges is 0, then the download_status_reset() in
 1b5e34badb06bb1a844a6e70164fc5c894d95d0a will fail.  I'm going to comment
 it out for now so that my Tor works.  I commented it out in
 63af663b8c83d771ed8fd29802e9a4c5cb074c70

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by merge):

 * Attachment "0001-doc-remove-unnecessary-paragraph-in-
 GettingStarted.m.patch" added.


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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by merge):

 * 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] #23499 [Core Tor/Tor]: dir server responses should include a Date: header even when not responding 200

[Tor Bug Tracker & Wiki]

#23499: dir server responses should include a Date: header even when not 
responding
200
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 dcd0aea85e9315c53a6b70a4a2b62ec65d539896 seems unnecessary.  we weren't
 logging reason_phrase, but instead were logging `reason_phrase ?
 reason_phrase : "OK"`. Doesn't seem like a terrible problem though.  I'm
 going to turn that conditional into IF_BUG_ONCE.

 Also I think we should renamed write_http_status_line(), since it doesn't
 actually write a line any more.

 I've done both of these in `bug23499` in my repository, based on top of
 yours.  I think this can go in 0.3.2 if you like.  What do  you think of
 the changes?

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

[tor-bugs] #23516 [Core Tor/Tor]: entrynodes.c: fix syntax error

[Tor Bug Tracker & Wiki]

#23516: entrynodes.c: fix syntax error
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  syntax
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The brackets in entrynode.c's line 2388 are misplaced in this if
 statement. Let's fix 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] #23516 [Core Tor/Tor]: entrynodes.c: fix syntax error

[Tor Bug Tracker & Wiki]

#23516: entrynodes.c: fix syntax error
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  syntax|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by merge):

 * 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] #23516 [Core Tor/Tor]: entrynodes.c: fix syntax error

[Tor Bug Tracker & Wiki]

#23516: entrynodes.c: fix syntax error
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  syntax|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by merge):

 * Attachment "0001-entrynodes.c-fix-syntax-error-around-BUG-
 statement.patch" added.


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

Re: [tor-bugs] #23508 [Core Tor/Tor]: large clock skews cause numerous bootstrap UX issues

[Tor Bug Tracker & Wiki]

#23508: large clock skews cause numerous bootstrap UX issues
---+---
 Reporter:  catalyst   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID: | 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] #23502 [Core Tor/Tor]: prop224: Don't make IPv4 mandatory because one day we'll have IPv6 only relays

[Tor Bug Tracker & Wiki]

#23502: prop224: Don't make IPv4 mandatory because one day we'll have IPv6 only
relays
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tor-relay, tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+--
Changes (by nickm):

 * cc: teor (added)


Comment:

 Seems okay to me.  What does teor think about this? I know he has a deep
 understanding on IPv6 issues, and I wonder if we're about to do something
 wise or foolish.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23517 [Metrics/Atlas]: Add aggregated results table for relays grouped by country and/or AS

[Tor Bug Tracker & Wiki]

#23517: Add aggregated results table for relays grouped by country and/or AS
---+-
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 This feature request is inspired by #23509, which, IIUC, is about
 displaying aggregated data on a single page. However, I believe that the
 feature that I'm describing here is sufficiently different to deserve its
 own ticket. If that's not the case, feel free to merge tickets!

 It would be cool to be able to group relays in the results table by
 country, by AS, or even by both. (Not by family, because grouping by
 family can be really tricky.)

 The most common use case would be that somebody wants to learn which are
 the top 10 countries contributing to the network. Or the top 10 ASes. And
 then they might want to include only relays with the Exit flag. Or filter
 by a given country and group by AS.

 Basically, this feature would make Compass obsolete, AFAICS. The only part
 in Compass that this would not implement is the "(almost) fast exit"
 distinction, and that's not a loss.

 This feature might be combined with #23509 by including a link from an
 aggregated results table entry to an aggregated details page that would be
 implemented in #23509. But that's not a requirement. The aggregated
 results table in itself is an improvement.

 Regarding links, there could be "Top 10 Countries" and "Top 10 ASes" links
 next to the existing "Top 10 Relays" link.

 Regarding the implementation, I think that we could start with an
 implementation in Atlas and only consider adding another document type for
 this to Onionoo if the implementation in Atlas does not scale. Atlas would
 request a details document with only the fields to be aggregated and
 displayed in the table, but for all relays. That's a potentially quite
 large document (though it's much smaller when using the fields parameter).
 But it's probably quite easy to cache that on the server and in the
 browser (for different aggregations by country or AS). Atlas would then
 perform all aggregations and subsequent sorting in the browser.

 What do you think? Did I miss anything that makes this feature a lot more
 difficult than it sounds in my description 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] #23509 [Metrics/Atlas]: implement family-level pages showing aggregated graphs

[Tor Bug Tracker & Wiki]

#23509: implement family-level pages showing aggregated graphs
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Please also find #23517 for a related idea.

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

Re: [tor-bugs] #23019 [Core Tor/Tor]: prop224: Validate received onion addresses on the client side

[Tor Bug Tracker & Wiki]

#23019: prop224: Validate received onion addresses on the client side
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 squashed and merged!

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

Re: [tor-bugs] #1116 [Core Tor/Tor]: 'Stable' flag assignment inconsistant

[Tor Bug Tracker & Wiki]

#1116: 'Stable' flag assignment inconsistant
--+
 Reporter:  StrangeCharm  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  0.2.1.19
 Severity:  Normal| Resolution:  None
 Keywords:  tor-dirauth mtbf data-export  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by merge):

 I don't have any new idea, but let's update this issue:

 Among the relays with 90+ days uptime, I see around 15 relays without the
 stable flag. Of course they have outdated tor versions, but nevertheless
 the stable flag doesn't seem to be as reliable as can be. A few examples:

 0F12 5FE6 14BF 3E5D 3910 1F7A 9C78 F5B3 74EB 0FF9
 DD6F 0796 240C 03E6 1BAC 87B0 B384 E675 25C7 E3D0
 CD1C 81E4 B0C9 2BE9 2A73 5DE2 FC60 9DF6 48D7 9152
 9092 050F 63BE B196 12EC ED2E 98FE A066 447E 2207
 A5A7 38F0 45ED DE9A 7EB9 4A44 7ECB 5F53 FD41 6452
 1380 0C84 2784 3491 3889 80FF 9991 7180 7BB7 E737
 79DE B4E0 2FD0 8AE1 AEB4 D859 4AAB 0823 75E9 062D
 A5E3 D05A 4F44 A915 C429 BF71 2334 A4E2 8E46 A10C
 23C1 585A 1214 D4BB 0945 8829 72BE EC1A 025C B36A
 EB41 A0C0 1EEC D85A A692 ADC6 60B9 1B5D 5B85 48A3
 4DDF E360 220A 80F2 0A30 7152 186B 87B5 9D88 3536
 242E 1E2E A7C4 1310 AD87 5935 6070 0BBC 2F9F 790B

 what they seem to have in common is quite varying traffic over time, or
 being very slow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23518 [Metrics/Atlas]: Turn Atlas into page on Tor Metrics

[Tor Bug Tracker & Wiki]

#23518: Turn Atlas into page on Tor Metrics
---+-
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 We briefly discussed this before, but I didn't find a ticket for it, so I
 made this one.

 Let's consider turning Atlas into a page on Tor Metrics. It could live
 under "Home >> Operation >> Atlas".

 From a technical perspective I think we could add Atlas as Git submodule
 and copy its index.html into a JSP, so that we can include the Tor Metrics
 banner and footer. And we'd copy over all required JS files.

 It would certainly help to get rid of Atlas' navbar and footer and make
 sure that it works well with [https://gitweb.torproject.org/metrics-
 web.git/tree/website/src/main/resources/web/css/style.css Metrics' style
 file].

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

Re: [tor-bugs] #23518 [Metrics/Atlas]: Turn Atlas into page on Tor Metrics

[Tor Bug Tracker & Wiki]

#23518: Turn Atlas into page on Tor Metrics
---+-
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by irl):

 karsten: I'm going to need to have some idea of how to set up a dev
 environment for this. Will things just work if I tell Eclipse to do Tomcat
 things with metrics-web?

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

Re: [tor-bugs] #23518 [Metrics/Atlas]: Turn Atlas into page on Tor Metrics

[Tor Bug Tracker & Wiki]

#23518: Turn Atlas into page on Tor Metrics
---+-
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 irl: It's complicated! :) I'd say don't worry about the technical
 integration part. Better import Metrics' CSS file into Atlas and make sure
 the page looks okay there (though without banner and footer). I'll happily
 do the rest.

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

Re: [tor-bugs] #23506 [Core Tor/Tor]: clock_skew_warning should be a bootstrap event

[Tor Bug Tracker & Wiki]

#23506: clock_skew_warning should be a bootstrap event
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:
   |  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID:  #23508 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by catalyst):

 * status:  needs_revision => needs_review


Comment:

 Updated the merge request with function documentation fixes, along with a
 changes file.

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

Re: [tor-bugs] #23506 [Core Tor/Tor]: clock_skew_warning should be a bootstrap event

[Tor Bug Tracker & Wiki]

#23506: clock_skew_warning should be a bootstrap event
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:
   |  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID:  #23508 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by catalyst):

 It would probably be good to backport this so it can get into deployed
 versions of Tor Browser.

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by catalyst):

 Yeah that does seem redundant.  However, I think the more detailed
 information dump that the existing text intends to refer to is actually
 the torguts repository. (which arguably should be under doc/ in the tor
 repository rather than its own repository)

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

Re: [tor-bugs] #23506 [Core Tor/Tor]: clock_skew_warning should be a bootstrap event

[Tor Bug Tracker & Wiki]

#23506: clock_skew_warning should be a bootstrap event
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
   |  implemented
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID:  #23508 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #23506 [Core Tor/Tor]: clock_skew_warning should be a bootstrap event

[Tor Bug Tracker & Wiki]

#23506: clock_skew_warning should be a bootstrap event
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
   |  implemented
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID:  #23508 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 I'm leaning towards no-backport; it's very close to a new feature in my
 book, and we should have 0.3.2.1-alpha out some time next week

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

Re: [tor-bugs] #23506 [Core Tor/Tor]: clock_skew_warning should be a bootstrap event

[Tor Bug Tracker & Wiki]

#23506: clock_skew_warning should be a bootstrap event
---+---
 Reporter:  catalyst   |  Owner:  catalyst
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
   |  implemented
 Keywords:  bootstrap clock-skew usability ux  |  Actual Points:
Parent ID:  #23508 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 (but if you disagree, please reopen and put it in needs_review for 0.3.1?)

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by merge):

 The torguts repo is a great read. I think it really should move inside
 tor's doc directory. It would probably be a little better maintained that
 way too.

 Tor doesn't yet use git modules for external repositories, so I guess that
 would add totally unnecessary complexity.

 If simply adding doc/torguts/ with the current torguts files, we'd have to
 make sure, the current torguts repo is deleted.

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

Re: [tor-bugs] #23516 [Core Tor/Tor]: entrynodes.c: fix syntax error

[Tor Bug Tracker & Wiki]

#23516: entrynodes.c: fix syntax error
--+
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  implemented
 Keywords:  syntax|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => implemented
 * milestone:   => Tor: 0.3.0.x-final


Comment:

 This isn't technically a syntax error, since BUG()  is a macro that
 expands to something parenthesized, but it sure does look like one, and
 it's worth fixing.

 merged to 0.3.0 and forward.

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

Re: [tor-bugs] #23310 [Core Tor/Tor]: test: prop224 client unit tests

[Tor Bug Tracker & Wiki]

#23310: test: prop224 client unit tests
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, test-unit  |  Actual Points:
Parent ID:  #23300  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 OK I think we now have enough unittests collected here that warrants its
 own patch and merge time.

 Please check branch `bug23310` in my repo for a branch based on latest
 master, that encorporates all the above branches together:
 a) An expansion pack for `test_client_service_hsdir_set_sync()`.
 b) A unittest for HSDir index computation including a python test vector.
 c) A unittest for clients picking intro points, plus a memleak fix
 (75d85d6078).
 d) A unittest for turning link specifier sets to `extend_info_t`.

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

Re: [tor-bugs] #23310 [Core Tor/Tor]: test: prop224 client unit tests

[Tor Bug Tracker & Wiki]

#23310: test: prop224 client unit tests
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  merge_ready
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, test-unit  |  Actual Points:
Parent ID:  #23300  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by asn):

 * status:  new => merge_ready


Comment:

 Setting this to `merge_ready` I will soon compute new test coverage
 metrics for master.

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by catalyst):

 A related ticket is #22911, but I'm not sure we have a ticket for moving
 the rest of torguts into the main tor repository.

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

Re: [tor-bugs] #23310 [Core Tor/Tor]: test: prop224 client unit tests

[Tor Bug Tracker & Wiki]

#23310: test: prop224 client unit tests
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, test-unit  |  Actual Points:
Parent ID:  #23300  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by asn):

 * status:  merge_ready => needs_review


Comment:

 Putting it on needs_review for some dgoulet validation.

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by merge):

 ok. strictly speaking moving torguts to tor/doc is a seperate issue. In
 case that'd be done, of course some texts will link to it.

 Or was this "you might like reading doc/HACKING" really meant to say "you
 might like reading https://gitweb.torproject.org/user/nickm/torguts.git/ ?

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

[tor-bugs] #23519 [- Select a component]: Please pin the gettorbrowser repository in your official Github account for better visibility

[Tor Bug Tracker & Wiki]

#23519: Please pin the gettorbrowser repository in your official Github account 
for
better visibility
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Pinning repositories has been introduced in Github long ago
 https://help.github.com/articles/pinning-repositories-to-your-profile/

 Also don't know which component to choose but I cc'ed the gettor
 maintainer :]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23520 [Core Tor/Tor]: Assume iat-mode=0 if the input is unknown instead of failing

[Tor Bug Tracker & Wiki]

#23520: Assume iat-mode=0 if the input is unknown instead of failing
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 How to reproduce:

 1. Get an obfs4 bridge from BridgeDB http://z5tfsnikzulwicxs.onion/
 2. In `torrc` change `iat-mode=0` or `iat-mode=1` or `iat-mode=2` with
 `iat-mode=मस्तेआपकै`.
 3. Relaunch tor, it should fail.

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

Re: [tor-bugs] #23520 [Obfuscation/Obfsproxy]: Assume iat-mode=0 if the input is unknown instead of failing

[Tor Bug Tracker & Wiki]

#23520: Assume iat-mode=0 if the input is unknown instead of failing
---+-
 Reporter:  cypherpunks|  Owner:  asn
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by nickm):

 * owner:  (none) => asn
 * component:  Core Tor/Tor => Obfuscation/Obfsproxy


Comment:

 I think obfs handles this option, not tor?

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

Re: [tor-bugs] #23520 [Obfuscation/Obfsproxy]: Assume iat-mode=0 if the input is unknown instead of failing

[Tor Bug Tracker & Wiki]

#23520: Assume iat-mode=0 if the input is unknown instead of failing
---+-
 Reporter:  cypherpunks|  Owner:  asn
 Type:  enhancement| Status:  closed
 Priority:  Low|  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by yawning):

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


Comment:

 Malformed input being rejected is perfectly reasonable behavior.

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:5 merge]:
 > Or was this "you might like reading doc/HACKING" really meant to say
 "you might like reading
 https://gitweb.torproject.org/user/nickm/torguts.git/ ?

 Yes, at least until we decide to move the torguts content into the tor
 repository.  `doc/HACKING/README.1st.md` also mentions torguts.git under a
 "X also describe" heading, but I'm not sure that needs to change as
 part of this ticket.

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

Re: [tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint

[Tor Bug Tracker & Wiki]

#10969: Set of guard nodes can act as a linkability fingerprint
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-guard, XKEYSCORE,|  Actual Points:
  prop259, SponsorU-deferred, QUICKANT   |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Hi isis, I'm again reopening this ticket because the fundamental problem
 in the title and description ("set of guard nodes can act as a linkability
 fingerprint") remains unfixed.

 I just checked a friend's laptop (Debian stable, tor 0.2.9.11-1~deb9u1)
 and when it got online it immediately connected to four guards. I don't
 know why, but I suspect it's because (like most laptops) it is sometimes
 not connected to the internet. (Some time later, it remained connected to
 two of them.)

 I'm well aware of other possible infoleaks and fingerprinting vectors, and
 I am even beta-testing a DHCP client that implements RFC7844. But even for
 casual users without a randomized MAC address and restrictive firewall, it
 seems obvious that tracking a person as they change locations is much
 simpler when there's a unique set of IPs which they (and only they)
 connect to, doesn't it?

 Btw, your fork of tordyguards which you linked above is
 [https://github.com/isislovecruft/tordyguards/compare/master...leewoboo:master
 currently missing three commits from upstream from 2014] so I think I'll
 stick with that version for now.

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

Re: [tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint

[Tor Bug Tracker & Wiki]

#10969: Set of guard nodes can act as a linkability fingerprint
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, tor-guard, XKEYSCORE,|  Actual Points:
  prop259, SponsorU-deferred, QUICKANT   |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Replying to [comment:40 cypherpunks]:
 > Hi isis, I'm again reopening this ticket because the fundamental problem
 in the title and description ("set of guard nodes can act as a linkability
 fingerprint") remains unfixed.
 >
 > I just checked a friend's laptop (Debian stable, tor 0.2.9.11-1~deb9u1)
 and when it got online it immediately connected to four guards. I don't
 know why, but I suspect it's because (like most laptops) it is sometimes
 not connected to the internet. (Some time later, it remained connected to
 two of them.)

 Sorry but that doesn't disprove what Isis said, Prop271 was implemented in
 Tor 0.3.0.x and not 0.2.9.x which your laptop's friend had.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23521 [Core Tor/Tor]: detect if clock skew is probably really time zone misconfiguration

[Tor Bug Tracker & Wiki]

#23521: detect if clock skew is probably really time zone misconfiguration
--+-
 Reporter:  catalyst  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  bootstrap clock-skew ux
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Many times when a tor client has clock skew, it's offset from the network
 by a round number of hours (or half hours), implying a time zone
 misconfiguration of some kind.  We might want to detect these situations
 and either automatically compensate, or report a better warning to the
 user than we do currently.

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

Re: [tor-bugs] #22985 [Applications/Tor Browser]: Can we simplify and clarify click-to-play of audio/video?

[Tor Bug Tracker & Wiki]

#22985: Can we simplify and clarify click-to-play of audio/video?
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-security, ux- |  Actual Points:
  team   |
Parent ID:  #23150   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 FWIW this is the relevant noscript.net forum post:
 https://forums.informaction.com/viewtopic.php?f=10&t=23273

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

Re: [tor-bugs] #22729 [Core Tor/TorDNSEL]: Revisit relay read/write history resolution (for onion services)

[Tor Bug Tracker & Wiki]

#22729: Revisit relay read/write history resolution (for onion services)
-+
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/TorDNSEL|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, guard-discovery  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by mikeperry):

 See #23512 for an instance where these stats revealed too much information
 and aided in a deanonymization attack.

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 My current thinking is that this ticket should be about the specific fix,
 and we should include more general fixes in #22729 or subtickets.

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by merge):

 the torguts repo is directly linked a few lines below though, in the very
 same file, GettingStarted.md; number 2 of "Getting your first patch into
 Tor". Wouldn't it be unnecessary to have it on top too?

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

Re: [tor-bugs] #23039 [Applications/Tor Browser]: Make the rbm build system work with runc 1.0.0

[Tor Bug Tracker & Wiki]

#23039: Make the rbm build system work with runc 1.0.0
+--
 Reporter:  boklm   |  Owner:  boklm
 Type:  task| Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709R  |  Actual Points:
Parent ID:  #17379  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  new => needs_review
 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201709R


Comment:

 Branch `bug_23039` has a patch fixing this:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23039&id=6e1b94b490a872ac287aad8102e5ec5270f48275

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

Re: [tor-bugs] #22943 [Core Tor/Stem]: Add Travis CI configuration so that Github forks receive CI coverage

[Tor Bug Tracker & Wiki]

#22943: Add Travis CI configuration so that Github forks receive CI coverage
-+-
 Reporter:  patrickod|  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  continuous-integration ci unit-  |  Actual Points:
  testing testing new-developers travis best-|
  practice   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

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


Comment:

 Thanks! Merged.

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

Re: [tor-bugs] #23505 [Webpages/Website]: Update torproject.org title / tab

[Tor Bug Tracker & Wiki]

#23505: Update torproject.org title / tab
--+
 Reporter:  steph |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 Replying to [comment:1 hiro]:
 > Do we have to change all the pages from "Tor Project: " to
 "Tor Project | "? I assume we should but I'd just like to
 confirm this.

 Yes, the formula I see other sites using is flipped " | Tor
 Project"

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

Re: [tor-bugs] #23519 [- Select a component]: Please pin the gettorbrowser repository in your official Github account for better visibility

[Tor Bug Tracker & Wiki]

#23519: Please pin the gettorbrowser repository in your official Github account 
for
better visibility
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * type:  enhancement => task


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

Re: [tor-bugs] #23519 [Applications/GetTor]: Please pin the gettorbrowser repository in your official Github account for better visibility

[Tor Bug Tracker & Wiki]

#23519: Please pin the gettorbrowser repository in your official Github account 
for
better visibility
-+-
 Reporter:  cypherpunks  |  Owner:  ilv
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * owner:  (none) => ilv
 * component:  - Select a component => Applications/GetTor


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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+--
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by catalyst):

 I think it's fine to mention it both up top and later on in "Getting your
 first patch into Tor", but only provide the full repository URL in one
 place.

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

Re: [tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint

[Tor Bug Tracker & Wiki]

#10969: Set of guard nodes can act as a linkability fingerprint
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, tor-guard, XKEYSCORE,|  Actual Points:
  prop259, SponsorU-deferred, QUICKANT   |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 Replying to [comment:41 cypherpunks]:
 > Replying to [comment:40 cypherpunks]:
 > > Hi isis, I'm again reopening this ticket because the fundamental
 problem in the title and description ("set of guard nodes can act as a
 linkability fingerprint") remains unfixed.

 This is actually fair. The new guard algorithm, as you're probably aware,
 has a concept of `SAMPLED_GUARDS` which is a subset of all the available
 guards in the consensus, and tor (>=0.3.x) will only connect to those. At
 any given point, a client will only have one guard. However, there's
 probably some super weird edge-cases, like "if your guard has stopped
 answering EXTEND cells but it's still behaving properly for circuits
 you've already created" then maybe tor could be tricked into keeping the
 circuits that still work while using a new, different guard for the other
 circuits. (Although, this more-fingerprintable state—if it's
 possible—wouldn't exist for long.)

 Anyway, I guess what I mean to say is that this specific issue with guard
 linkability shouldn't be an issue anymore, but there's definitely still
 improvements which could be made to the guard algorithm.

 > > I just checked a friend's laptop (Debian stable, tor
 0.2.9.11-1~deb9u1) and when it got online it immediately connected to four
 guards. I don't know why, but I suspect it's because (like most laptops)
 it is sometimes not connected to the internet. (Some time later, it
 remained connected to two of them.)
 >
 > Sorry but that doesn't disprove what Isis said, Prop271 was implemented
 in Tor 0.3.0.x and not 0.2.9.x which your laptop's friend had.

 nickm and asn and I talked about this ticket a bit in IRC, and I think the
 general consensus was to make a new tracking ticket for guard algorithm
 issues/improvements, with specific child tickets that only discuss post-
 prop271 tor behaviours, since this ticket was originally about a part of
 the code that has been nearly entirely replaced.

 I have a slight preference for a new ticket, but I'll happily defer to
 whatever other people think is the logical thing to do.

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

Re: [tor-bugs] #21816 [Core Tor/Tor]: Add support for Pluggable Transports 2.0

[Tor Bug Tracker & Wiki]

#21816: Add support for Pluggable Transports 2.0
-+-
 Reporter:  chelseakomlo |  Owner:
 |  dasyatid1
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-pt, tor-bridge,  |  Actual Points:
  design, pt2, review-group-23   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.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] #22909 [Core Tor/Tor]: Our Rust code is always built in debug mode

[Tor Bug Tracker & Wiki]

#22909: Our Rust code is always built in debug mode
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  rust, rust-pilot, tor-build  |  Actual Points:
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:  SponsorZ
-+-
Changes (by isis):

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


Comment:

 Replying to [comment:8 infinity0]:
 > I should have been explicit earlier but this ticket really should be
 closed, it is invalid.
 >
 > debug mode is `[profile.debug]`, i.e. what happens when you leave out
 `--release` when invoking `cargo`.
 >
 > `debug = true` is ''not'' "debug mode", it is to tell rustc to add
 DWARF2 debuginfo to the ELF binaries and is equivalent to `-g` flags to C
 compilers.

 Ah, I'm sorry, I understand what you meant now. `-g` just means it's
 passing `-C debuginfo=2`. Closing as invalid.

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

Re: [tor-bugs] #23521 [Core Tor/Tor]: detect if clock skew is probably really time zone misconfiguration

[Tor Bug Tracker & Wiki]

#23521: detect if clock skew is probably really time zone misconfiguration
-+
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew ux  |  Actual Points:
Parent ID:   | 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] #23310 [Core Tor/Tor]: test: prop224 client unit tests

[Tor Bug Tracker & Wiki]

#23310: test: prop224 client unit tests
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, prop224, test-unit  |  Actual Points:
Parent ID:  #23300  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Ooook so #23502 has almost the equivalency of
 `extend_info_from_lspecs` in that branch, I didn't realized that I had
 made a test previously in this branch.

 So I suggest we remove that test from the branch. Furthermore, maybe can
 you rebase it on latest master?

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

Re: [tor-bugs] #23515 [Core Tor/Tor]: remove inappropriate paragraph in GettingStarted.md

[Tor Bug Tracker & Wiki]

#23515: remove inappropriate paragraph in GettingStarted.md
--+
 Reporter:  merge |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Very Low  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Trivial   | Resolution:
 Keywords:  doc   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


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

Re: [tor-bugs] #22769 [Core Tor/Tor]: Investigate the reproducibility of Rust binaries

[Tor Bug Tracker & Wiki]

#22769: Investigate the reproducibility of Rust binaries
+
 Reporter:  isis|  Owner:  (none)
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust, SponsorZ  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:  SponsorZ
+

Comment (by cypherpunks):

 > and soon (ESR 58?)

 typo I guess it's ESR 59 :)

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

Re: [tor-bugs] #23499 [Core Tor/Tor]: dir server responses should include a Date: header even when not responding 200

[Tor Bug Tracker & Wiki]

#23499: dir server responses should include a Date: header even when not 
responding
200
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  needs_review => merge_ready


Comment:

 Your patches look good! Thanks. (check-spaces might have something to say
 to you.)

 (I spent a little while thinking about whether we could refactor the
 "write the status code and date header" part out to its own thing, since
 write_http_response_header_impl() essentially do that too, but I didn't
 hit upon a satisfactory way. If you find one, please feel free. :)

 Oh, and as for whether dcd0aea8 is unnecessary, look right below it to
 where we
 {{{
   log_debug(LD_DIRSERV,"Wrote status 'HTTP/1.0 %d %s'", status,
 reason_phrase);
 }}}
 That's the log I meant.

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

Re: [tor-bugs] #23499 [Core Tor/Tor]: dir server responses should include a Date: header even when not responding 200

[Tor Bug Tracker & Wiki]

#23499: dir server responses should include a Date: header even when not 
responding
200
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  clock-skew|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Thanks! And sorry for missing that log.  Who runs at debug anyway? ;)

 Merging to master.

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

Re: [tor-bugs] #23519 [Applications/GetTor]: Please pin the gettorbrowser repository in your official Github account for better visibility

[Tor Bug Tracker & Wiki]

#23519: Please pin the gettorbrowser repository in your official Github account 
for
better visibility
-+-
 Reporter:  cypherpunks  |  Owner:  ilv
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ilv):

 I do not see this option in TPO profile. This should be done by someone
 with administrator access. Maybe hellais knows who.

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

Re: [tor-bugs] #23383 [Metrics/Website]: Apply Tor style guide to redesigned Tor Metrics website

[Tor Bug Tracker & Wiki]

#23383: Apply Tor style guide to redesigned Tor Metrics website
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by linda):

 Replying to [comment:14 karsten]:
 > Turns out it was not too hard to create the new tile files myself based
 on what I got from antonela earlier. Rebased, pushed, and
 [https://metrics.torproject.org/ deployed] everything. That concludes this
 ticket. Thanks to everyone involved!

 o/

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

Re: [tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint

[Tor Bug Tracker & Wiki]

#10969: Set of guard nodes can act as a linkability fingerprint
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, tor-guard, XKEYSCORE,|  Actual Points:
  prop259, SponsorU-deferred, QUICKANT   |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:42 isis]:
 > Replying to [comment:41 cypherpunks]:
 > > Replying to [comment:40 cypherpunks]:
 > > > Hi isis, I'm again reopening this ticket because the fundamental
 problem in the title and description ("set of guard nodes can act as a
 linkability fingerprint") remains unfixed.
 ...
 > > > I just checked a friend's laptop (Debian stable, tor
 0.2.9.11-1~deb9u1) and when it got online it immediately connected to four
 guards. I don't know why, but I suspect it's because (like most laptops)
 it is sometimes not connected to the internet. (Some time later, it
 remained connected to two of them.)
 > >
 > > Sorry but that doesn't disprove what Isis said, Prop271 was
 implemented in Tor 0.3.0.x and not 0.2.9.x which your laptop's friend had.

 It is likely that at least 2 of the 4 "guards" are:
 * directory authorities
 * fallback directory mirrors
 * directory guards

 That's why your client disconnected from 2 of them after downloading the
 consensus, certificates, and descriptors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23522 [Metrics/Atlas]: tooltip on dns name field (and maybe title) could need improvement

[Tor Bug Tracker & Wiki]

#23522: tooltip on dns name field (and maybe title) could need improvement
---+-
 Reporter:  irl|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 #18342 has a discussion on the semantics of the host_name field.

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

Re: [tor-bugs] #22146 [Metrics/Atlas]: move platform and consensus weight before family lists

[Tor Bug Tracker & Wiki]

#22146: move platform and consensus weight before family lists
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

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


Comment:

 platform is still below family lists (both are in the configuration
 column)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23523 [Core Tor/Tor]: Handle extreme values better in add_laplace_noise()

[Tor Bug Tracker & Wiki]

#23523: Handle extreme values better in add_laplace_noise()
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.14-alpha
 Severity:  Normal|   Keywords:  tor-relay, privcount
Actual Points:|  Parent ID:  #23061
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 We think it's impossible to get values this large, but we should still
 check for them and handle them appropriately.

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

Re: [tor-bugs] #23523 [Core Tor/Tor]: Handle extreme values better in add_laplace_noise()

[Tor Bug Tracker & Wiki]

#23523: Handle extreme values better in add_laplace_noise()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privcount  |  Actual Points:
Parent ID:  #23061| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review
 * version:  Tor: 0.2.2.14-alpha => Tor: 0.2.6.2-alpha
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Please see my branch bug23523.

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

Re: [tor-bugs] #19130 [Core Tor/Tor]: Seg fault in round_int64_to_next_multiple_of()

[Tor Bug Tracker & Wiki]

#19130: Seg fault in round_int64_to_next_multiple_of()
---+
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Critical   | Resolution:  fixed
 Keywords:  TorCoreTeam201605  |  Actual Points:  .3
Parent ID:  #23414 | Points:  .3
 Reviewer:  teor   |Sponsor:  SponsorS-can
---+
Changes (by teor):

 * parent:   => #23414


Comment:

 We need a working round_int64_to_next_multiple_of() for #23414.

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:
 tor-relay, security-low, privcount, 031-backport, 030-backport,
 029-backport, 028-backport-maybe, 026-backport-maybe
 =>
 tor-relay, security-low, privcount, 031-backport, 030-backport,
 029-backport, 028-backport


Comment:

 I made a new branch at bug23414-v4, and split off some unrelated changes
 into #23323.

 It needs a working round_int64_to_next_multiple_of(), which also needs to
 be backported to 0.2.8 and later. There is a possible fix in #19130 (which
 we closed by deleting the buggy function).

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