[tor-bugs] #28309 [Core Tor/Tor]: Log the rust version when printing other library versions

[Tor Bug Tracker & Wiki]

#28309: Log the rust version when printing other library versions
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  rust, 036-roadmap-proposed
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 tor --library-versions prints the versions of Tor's library dependencies.

 Would it be useful for it to print the rust version as well?
 Or the versions of our rust library dependencies?

 Tor also prints the OS version and library versions when it starts up. We
 could add the rust version and significant rust library versions to that
 log message.

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

Re: [tor-bugs] #28308 [Core Tor/Tor]: Log the Tor version before running the unit tests

[Tor Bug Tracker & Wiki]

#28308: Log the Tor version before running the unit tests
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #28096| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_review
 * reviewer:   => asn


Comment:

 This can be reviewed in #28096.

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

Re: [tor-bugs] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.34
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.2
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 These pull requests are unchanged:

 Replying to [comment:3 teor]:
 > My bug28096-029 merges cleanly from maint-0.2.9 to maint-0.3.4.
 > https://github.com/torproject/tor/pull/429
 >
 > My bug28096-035 merges cleanly from maint-0.3.5 to master.
 > https://github.com/torproject/tor/pull/430
 >
 > (See https://github.com/teor2345/tor.git for the branches.)

 I did a minor refactor and implemented #28308 in bug28096-ticket28308-035:
 https://github.com/torproject/tor/pull/472

 Since it just has test changes and refactoring, we can merge
 bug28096-ticket28308-035 to 0.3.5 or master.

 There's also bug28096-ticket28308-master if we want to merge the new test
 code to 0.3.6:

 https://github.com/torproject/tor/pull/471

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28308 [Core Tor/Tor]: Log the Tor version before running the unit tests

[Tor Bug Tracker & Wiki]

#28308: Log the Tor version before running the unit tests
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fast-fix
Actual Points:|  Parent ID:  #28096
   Points:|   Reviewer:
  Sponsor:|
--+
 This feature is useful by itself. It also tests get_uname() for #28096.

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

Re: [tor-bugs] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.34
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.2
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:6 asn]:
 > Patch looks good in principle:
 >
 > Two things:
 > a) Do you think we can add a unittest for this `get_uname()` function to
 test that the new table entries work and will work correctly?

 I don't think we can mock the Windows API function GetVersionEx(), so that
 makes it hard to unit test get_uname(). But we do call get_uname() as part
 of test_dir_formats().

 We also call get_uname() every time tor is launched:

 
https://github.com/torproject/tor/blob/67351f672450d5f13754294405243a59ddd86de9/src/app/main/main.c#L606

 I would like to print the same string for the unit tests, I'll open a
 child ticket and update the pull request.

 > b) Should we change `Windows 8` to `Windows 8 or later` even tho the
 info remains the same? Could there be scripts that break on this?

 Any scripts that expect `Windows 8` are already broken, because Tor will
 return `Windows 8` on Windows 8, 8.1, and 10.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28307 [- Select a component]: DisableNetwork is set

[Tor Bug Tracker & Wiki]

#28307: DisableNetwork is set
---+--
 Reporter:  Cyber 404  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  - Select a component
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 when i try to open tor i see this log

 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control
 network connections. Shutting down all existing connections.

 and this

 Delaying directory fetches: DisableNetwork is set.

 and i don't see  any disable network words in any torcc file, how can i
 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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Thanks neel!
 Let us know if you need some help.

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by neel):

 I decided that I will add the unit tests as well and do #27086.

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

Re: [tor-bugs] #27086 [Core Tor/Tor]: Write unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#27086: Write unit tests for fascist_firewall_choose_address_ls() and
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23588   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

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


Comment:

 From the discussion in #23588, I'll take 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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 I wonder if it's more than a rounding error.

 How is frac calculated?

 I wonder if you're choosing a point in time to calculate the consensus
 weight fraction.

 What happens if relays that submit statistics are offline at that point in
 time?
 But it submits statistics later, when it comes back online?

 If that relay has a weight N, and 100% of relays submit, then your frac
 calculation will be:

100 the relays that submitted statistics
 -
 (100 - N)  the relays that were online at the point in time you chose

 When it should be:

 100 the relays that submitted statistics
 ---
 100 all the relays that could have submitted statistics

 I can't find the codebase or the metrics statistics explanation to check.
 (I tried searching for the code online. And I tried the metrics wiki
 pages.)

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

Re: [tor-bugs] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 036-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Note for the review assigner:

 ahf wants to review tor bandwidth authority patches.

 Note for the reviewer:

 Let's get a simple version of this patch working first. The simplest
 version sends the bandwidth file that is on disk right now.

 Then we can follow up with:
 * #27047: authorities should keep recent consensuses, votes, and bandwidth
 files
 * #26797: read the file once per vote, and use the cached file for votes
 and bandwidth file requests
 * #26698: put a hash of the bandwidth file in the vote

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

Re: [tor-bugs] #26797 [Core Tor/Tor]: DirAuths should only read the V3BandwidthsFile once per vote

[Tor Bug Tracker & Wiki]

#26797: DirAuths should only read the V3BandwidthsFile once per vote
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth  |  Actual Points:
Parent ID:  #27047| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #21377 => #27047


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

Re: [tor-bugs] #26904 [Core Tor/Tor]: Work out if we need to round scanner measured bandwidths to protect individual client usage

[Tor Bug Tracker & Wiki]

#26904: Work out if we need to round scanner measured bandwidths to protect
individual client usage
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #21377 =>


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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:54 dgoulet]:
 > @teor, should we still merge this. I'm a bit confused about the fact
 that we have concerns but still merge it? :S...

 I would like this new code to have unit tests (#27086) before we merge it.

 The other related tickets would be nice to have, but they're optional.

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

Re: [tor-bugs] #24000 [Core Tor/Tor]: circuit_send_intermediate_onion_skin() and extend_cell_format() should check for IPv6

[Tor Bug Tracker & Wiki]

#24000: circuit_send_intermediate_onion_skin() and extend_cell_format() should
check for IPv6
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, 034-triage-20180328, merge-|  Actual Points:
  deferred, 035-triaged-in-20180711  |
Parent ID:  #24403   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:13 dgoulet]:
 > Replying to [comment:9 teor]:
 > > I am risk-averse and don't think we should merge this until we're
 ready to actually send IPv6 link specifiers. Because I don't know if this
 patch helps with bugs where we accidentally send IPv6 extends. And we
 can't really test it.
 > >
 > > ln5 is working on a proposal for IPv6 extends, so we should be able to
 merge this in 0.3.5 or 0.3.6.
 > >
 >
 > Moving this out of `merge_ready`. Lets figure this out `^`. Maybe point
 to a ticket or sth?

 When we do IPv6 reachability checks on relays in #24403, we can merge this
 code.

 We don't really have a status for that, so I'll put it in
 "needs_revision", because we need to add more code to this branch before
 it's mergeable.

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

Re: [tor-bugs] #27974 [Applications/Tor Browser]: Make SEARX the Default Search Engine

[Tor Bug Tracker & Wiki]

#27974: Make SEARX the Default Search Engine
--+--
 Reporter:  nicwow|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * owner:  (none) => tbb-team
 * component:  Internal Services => Applications/Tor Browser


Comment:

 looks like TB stuff

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28306 [Internal Services/Tor Sysadmin Team]: Please add signing keys to db.torproject.org

[Tor Bug Tracker & Wiki]

#28306: Please add signing keys to db.torproject.org
-+-
 Reporter:  traumschule  |  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:   |
-+-
 Not entirely sure of this is in the scope of db.torproject.org:

 For #22637 it would be useful to have all keys in the db which are listed
 on
 https://www.torproject.org/docs/signing-keys.html.en

 Then we could link to it instead of pgp.mit.edu which sometimes gives
 errors.

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

Re: [tor-bugs] #28302 [Webpages/Website]: Update nickm's signing key on signing-keys page

[Tor Bug Tracker & Wiki]

#28302: Update nickm's signing key on signing-keys page
--+--
 Reporter:  nickm |  Owner:  hiro
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22637| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  new => needs_review
 * parent:   => #22637


Comment:

 https://github.com/torproject/webwml/pull/66

 This PR replaces your currently shown key for {{{Tor source tarballs}}}
 0x165733EA with 0xFE43009C4607B1FB.
 Does it follow the logic to keep "older Tor tarballs" untouched?

 current key
 {{{
 $ gpg --keyid-format 0xlong --fingerprint --list-key 0xFE43009C4607B1FB
 pub   rsa4096/0xFE43009C4607B1FB 2016-09-21 [C] [expires: 2019-09-21]
   Key fingerprint = 2133 BC60 0AB1 33E1 D826  D173 FE43 009C 4607 B1FB
 uid   [ unknown] Nick Mathewson 
 uid   [ unknown] Nick Mathewson 
 uid   [ unknown] Nick Mathewson 
 uid   [ unknown] Nick Mathewson 
 }}}

 removed key:
 {{{
 $ gpg --keyid-format 0xlong --fingerprint --list-key 0x165733EA
 pub   rsa1024/0xD50624EC165733EA 2014-06-16 [SCEA] [revoked: 2016-08-16]
   Key fingerprint = 33DC 81DC C099 4E0A 10D8  048B D506 24EC 1657 33EA
 uid   [ revoked] Nick Mathewson 

 pub   rsa3072/0x21194EBB165733EA 2004-07-03 [SC]
   Key fingerprint = B35B F85B F194 89D0 4E28  C33C 2119 4EBB 1657 33EA
 uid   [ unknown] Nick Mathewson 
 uid   [ unknown] Nick Mathewson 
 uid   [ unknown] Nick Mathewson 
 uid   [ unknown] [jpeg image of size 3369]
 sub   rsa3072/0x910397D88D29319A 2004-07-03 [S]
 sub   rsa3072/0xD2CA27F3F25B8E5E 2004-07-03 [E]
 }}}

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

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by atagar):

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


Comment:

 Hi wagon. tor-prompt uses your terminal's readline module. It isn't a
 curses interface like nyx so I don't have that level of control over
 scrolling (readline just provides standard terminal output, and as such
 relies on your normal window scrolling).

 Sorry!

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

Re: [tor-bugs] #28299 [Core Tor/Nyx]: Custom colors for Nyx and tor-prompt are needed

[Tor Bug Tracker & Wiki]

#28299: Custom colors for Nyx and tor-prompt are needed
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  tor-prompt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  assigned => needs_information


Comment:

 Hi wagon. Sorry, I'm unsure of the ask here. Are you talking about the
 [https://nyx.torproject.org/index.html#configuration color_override nyxrc
 option]?

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

Re: [tor-bugs] #28153 [Core Tor/Nyx]: Nyx memory leaks

[Tor Bug Tracker & Wiki]

#28153: Nyx memory leaks
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by atagar):

 Hi wagon. The version field is unused for nyx tickets. The only fields I
 care about are listed on...

 https://trac.torproject.org/projects/tor/wiki/doc/nyx/bugs

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

Re: [tor-bugs] #25302 [Core Tor/Nyx]: Cannot quit after using Control Interpreter

[Tor Bug Tracker & Wiki]

#25302: Cannot quit after using Control Interpreter
--+
 Reporter:  slopdog   |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 > I cannot reproduce this problem on my Debian.

 Great, thanks wagon!

 > Also, I don't understand why do you need qq instead of q. Simply q
 should be enough to quit.

 It's so a single accidental keystroke doesn't shut nyx down. You can
 include "confirm_quit false" in your
 [https://nyx.torproject.org/index.html#configuration nyxrc] to turn that
 off.

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

Re: [tor-bugs] #27321 [Core Tor/Nyx]: incorrect bw calculation during initial startup

[Tor Bug Tracker & Wiki]

#27321: incorrect bw calculation during initial startup
--+---
 Reporter:  a_p   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi wagon, I'm unsure I follow what you're describing. Could you please
 attach a screenshot pointing out the issue and the 'nyx ---debug' log
 (redacted of any information you feel is sensitive)?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 The estimated fraction of reported user statistics from relays has reached
 100% and even went slightly beyond that number to 100.294% on 2018-10-27
 and 100.046% on 2018-10-28.

 The effect is that we're excluding days when this happened from
 statistics, because we never thought this was possible:

 {{{
 WHERE a.frac BETWEEN 0.1 AND 1.0
 }}}

 However, I think this is most likely a rounding error somewhere, not a
 general issue with the approach. Stated differently, it seems wrong to
 include a number with a fraction of reported statistics of 99.9% but not
 one where that fraction is 100.1%.

 I suggest that we drop the upper limit and change the line above to:

 {{{
 WHERE a.frac >= 0.1
 }}}

 We'll be replacing these statistics by PrivCount in the medium term
 anyway.

 However, simply excluding data points doesn't seem like an intuitive
 solution.

 Thoughts?

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

Re: [tor-bugs] #28297 [Core Tor/Nyx]: Control interpreter in nyx does not do line splitting

[Tor Bug Tracker & Wiki]

#28297: Control interpreter in nyx does not do line splitting
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Hi wagon, this is an interesting catch - thanks! Nyx and tor-prompt share
 the same functionality but use very different display their output. tor-
 prompt uses readline whereas Nyx uses curses. With curses I need to do
 line wrapping myself so unsurprising I missed it here - 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] #28296 [Core Tor/Nyx]: Nyx shows wrong IP address for ControlPort connection

[Tor Bug Tracker & Wiki]

#28296: Nyx shows wrong IP address for ControlPort connection
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by atagar):

 * status:  assigned => needs_information


Comment:

 Hi wagon. Localhost connections (127.0.0.1) are replaced with your
 externally facing IP when we can because this *is* your address to the
 wider world. Showing localhost would be pretty unhelpful.

 Displaying either address is correct. Did you have any other questions?

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

Re: [tor-bugs] #28304 [Metrics/Relay Search]: Please deliver png when svg is filtered

[Tor Bug Tracker & Wiki]

#28304: Please deliver png when svg is filtered
--+--
 Reporter:  traumschule   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * Attachment "metrics-graph.png" added.

 "No Data Available" without description what kind of data. "Save Graph"
 links rs.html and could be hidden.

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

Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code

[Tor Bug Tracker & Wiki]

#27299: hsv3: Clarify timing sources around hsv3 code
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs hsv3 refactoring easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by ffmancera):

 I am going to work on this patch. This seems to be huge because there is a
 lot of files using timing sources in `src/features/hs`. I am going to add
 some notes in the ticket if there is no problem.

 I saw that we are using `approx_time()` which is an alias of `time(NULL)`,
 but at the same time and in the same file, we are using both. As
 `approx_time.h` has different utilities for timing, we should use it
 instead of `time(NULL)`. 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

[tor-bugs] #28304 [Metrics/Relay Search]: Please deliver png when svg is filtered

[Tor Bug Tracker & Wiki]

#28304: Please deliver png when svg is filtered
--+--
 Reporter:  traumschule   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hi metrics team!

 With #19654 the relay search shows
 > Graphs cannot be shown as your browser does not support Scalable Vector
 Graphics (SVG). This is the case when Tor Browser is in High Security
 mode.
 This is very useful. However i'd like to download a png of the graph, or
 just csv/xml/json in that case.

 On a sidenote the graph shows "No data available" while data is loading
 which can be confusing, ie. it's not clear with a slow connection if the
 graph will show up later or not - would "data is loading .." make sense?
 Hesitating to open another ticket about this because it looks like #25264.
 Thought it could help to show captions (or similar) to indicate what kind
 of data isn't available.

 Let me know if you prefer a separate issue for the latter. Thanks for your
 work!

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

Re: [tor-bugs] #28295 [Core Tor/Nyx]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28295: Non-interactive way to supply ControlPort password for nyx and 
tor-prompt
is needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Oh oops. Thanks wagon, this is a good point, I did forget the controller
 password from the [https://nyx.torproject.org/index.html#configuration
 config options]. My bad.

 From a technical standpoint I'm unsure it's useful, since a persisted
 config password is effectively cookie authentication. Said another way, in
 authentication schemes a password is 'something you know' whereas cookie
 auth is 'something you have'. If you write your password into a text file
 it's just a poor man's cookie authentication.

 That said, this is likely to confuse others too so I should simply add it.
 Not sure when I'll get around to this (patches welcome), but I'll be sure
 it's included in the next release.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/tor/pull/470

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

Re: [tor-bugs] #28303 [Core Tor/Tor]: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build

[Tor Bug Tracker & Wiki]

#28303: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  openbsd   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by kjak):

 PR: https://github.com/torproject/tor/pull/469

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

Re: [tor-bugs] #28294 [Core Tor/Nyx]: Nyx crashes at graph resizing

[Tor Bug Tracker & Wiki]

#28294: Nyx crashes at graph resizing
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

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


Comment:

 Hi wagon, thanks for the report. This is already fixed:
 https://trac.torproject.org/projects/tor/ticket/24382

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28303 [Core Tor/Tor]: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build

[Tor Bug Tracker & Wiki]

#28303: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build
-+--
 Reporter:  kjak |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:   |   Severity:  Normal
 Keywords:  openbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 The files `src/lib/encoding/time_fmt.c` and `src/lib/evloop/timers.c` both
 need to include `sys/time.h` for `struct timeval`.  Otherwise compilation
 fails on OpenBSD with the following errors:

 {{{
   CC   src/lib/encoding/time_fmt.o
   src/lib/encoding/time_fmt.c: In function 'format_iso_time_nospace_usec':
   src/lib/encoding/time_fmt.c:318: error: dereferencing pointer to
 incomplete type
   src/lib/encoding/time_fmt.c:319: error: dereferencing pointer to
 incomplete type
   gmake[1]: *** [Makefile:9088: src/lib/encoding/time_fmt.o] Error 1
 }}}

 and

 {{{
   CC   src/lib/evloop/timers.o
   src/lib/evloop/timers.c: In function 'tv_to_timeout':
   src/lib/evloop/timers.c:115: error: dereferencing pointer to incomplete
 type
   src/lib/evloop/timers.c:116: error: dereferencing pointer to incomplete
 type
   src/lib/evloop/timers.c: In function 'timeout_to_tv':
   src/lib/evloop/timers.c:128: error: dereferencing pointer to incomplete
 type
   src/lib/evloop/timers.c:129: error: dereferencing pointer to incomplete
 type
   src/lib/evloop/timers.c: In function 'libevent_timer_reschedule':
   src/lib/evloop/timers.c:156: error: storage size of 'd' isn't known
   src/lib/evloop/timers.c:156: warning: unused variable 'd'
   gmake[1]: *** [Makefile:9088: src/lib/evloop/timers.o] Error 1
 }}}

 This change does not appear to be necessary on FreeBSD or NetBSD.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28302 [Webpages/Website]: Update nickm's signing key on signing-keys page

[Tor Bug Tracker & Wiki]

#28302: Update nickm's signing key on signing-keys page
--+--
 Reporter:  nickm |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hi!  The page at https://www.torproject.org/docs/signing-keys.html.en
 lists an older signing key that I have deprecated for about 2 years now.

 Here is a signed statement about my current key:

 https://people.torproject.org/~nickm/key-transition-statement-2.txt.asc

 Could we have the website list my current primary key?

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

Re: [tor-bugs] #28301 [Community/Translations]: URGENT! Translation mistake on front page – big quiproquo may occur

[Tor Bug Tracker & Wiki]

#28301: URGENT! Translation mistake on front page – big quiproquo may occur
+--
 Reporter:  autonum |  Owner:  emmapeel
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Community/Translations  |Version:  Tor: unspecified
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 Ah indeed the translation on the `about:tor` banner is wrong.

 It has already been fixed, but too late for the 8.0.3 release:
 
https://gitweb.torproject.org/torbutton.git/commit/?id=a62f5e98572d2dd6bcc5d7310dfbb431bcd6fec7

 {{{
 -
 +
 }}}

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

Re: [tor-bugs] #28301 [Community/Translations]: URGENT! Translation mistake on front page – big quiproquo may occur

[Tor Bug Tracker & Wiki]

#28301: URGENT! Translation mistake on front page – big quiproquo may occur
+--
 Reporter:  autonum |  Owner:  emmapeel
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Community/Translations  |Version:  Tor: unspecified
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 On which page?

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  assigned => merge_ready


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by hiro):

 This is now in staging. Please check it out and I will be pushing 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] #28301 [Community/Translations]: URGENT! Translation mistake on front page – big quiproquo may occur

[Tor Bug Tracker & Wiki]

#28301: URGENT! Translation mistake on front page – big quiproquo may occur
+--
 Reporter:  autonum |  Owner:  emmapeel
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Community/Translations  |Version:  Tor: unspecified
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by traumschule):

 * cc: traumschule (removed)
 * owner:  hiro => emmapeel
 * component:  Webpages/Website => Community/Translations


Comment:

 Thanks for reporting!

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

Re: [tor-bugs] #28301 [Webpages/Website]: URGENT! Translation mistake on front page – big quiproquo may occur

[Tor Bug Tracker & Wiki]

#28301: URGENT! Translation mistake on front page – big quiproquo may occur
--+--
 Reporter:  autonum   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Webpages/Website  |Version:  Tor: unspecified
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by autonum):

 Main greeting page 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

[tor-bugs] #28301 [Webpages/Website]: URGENT! Translation mistake on front page – big quiproquo may occur

[Tor Bug Tracker & Wiki]

#28301: URGENT! Translation mistake on front page – big quiproquo may occur
--+--
 Reporter:  autonum   |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Immediate |  Component:  Webpages/Website
  Version:  Tor: unspecified  |   Severity:  Critical
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 SORRY.
 I don't have time to get through the translation protocol.

 On the main page, the french translation says «give now and mozilla will
 receive your donation»; instead of «mozilla will double your donation» as
 I think it is suppose to say.

 I consider this critical.

 Sorry if this way of reporting is not appropriate.

 Tahnks for the tremendous job.

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

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by wagon):

 * keywords:   => tor-prompt


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Component:  Core Tor/Stem
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 Control Interpreter of Nyx has very convenient type of scrolling, where
 ESC allows us to scroll buffer using `up`/`down` arrows,
 `PageUp`/`PageDown`, and `Home`/`End` keys. Though scrolling can be done
 with the help of terminal itself or with the help of some environments
 such as `screen`, it would be convenient to have Nyx-like scrolling
 working also in `tor-prompt`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28299 [Core Tor/Nyx]: Custom colors for Nyx and tor-prompt are needed

[Tor Bug Tracker & Wiki]

#28299: Custom colors for Nyx and tor-prompt are needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Component:  Core Tor/Nyx
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:  tor-prompt|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 If `color_interface true` is selected for Nyx, some elements are
 highlighted, but their colors cannot be changed. It would be good to add
 `nyxrc` options for custom colors. `tor-prompt` also needs config options
 to select colors.

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

Re: [tor-bugs] #15706 [Applications/Tor Browser]: Extract statistics on incremental update success rates

[Tor Bug Tracker & Wiki]

#15706: Extract statistics on incremental update success rates
--+---
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  MikePerry201507   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 Do we still think this is a worthwhile goal?

 (I would hope that the fraction of Tor Browser users who hack their local
 scripts, even on Linux, is tiny compared to the overall population. Maybe
 there are bugs in the updater that cause a larger fraction of the user
 base to end up fetching the whole (non-incremental) update, but those
 sound like different issues than this ticket or its parent #15456 are
 for.)

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 For the "cutting all RP circuits" side, compare to how we handle changes
 in ExitPolicy, or how we handle changes to SocksPolicy: the config change
 only impacts how we respond to new requests. That is, we don't cut
 existing exit connections when the exit policy changes, or existing socks
 connections when the socks policy changes. As an even more extreme
 example, I think we leave OR and exit connections as-is when ORPort gets
 disabled too. All of these config options focus on how we will treat new
 requests.

 As for the "rotating intro points" side, I haven't kept up on the auth
 design here, but I just looked through rend-spec-v3.txt. It looks like
 there are two components to the client auth -- one is whether the client
 can decrypt the descriptor (to learn the intro points), and the other is
 whether the client can prove that it's authorized in the INTRODUCE1 cell?
 I'm tempted to try to solve this one by defining "revoke" to focus on that
 second component. I also wish we had actual use cases for this client auth
 design, so we wouldn't be left trying to debate over what future
 hypothetical users would want the system 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] #28296 [Core Tor/Nyx]: Nyx shows wrong IP address for ControlPort connection

[Tor Bug Tracker & Wiki]

#28296: Nyx shows wrong IP address for ControlPort connection
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by wagon):

 * keywords:  nyx =>
 * reviewer:  atagar =>
 * component:  Applications => Core Tor/Nyx


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

Re: [tor-bugs] #28295 [Core Tor/Nyx]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28295: Non-interactive way to supply ControlPort password for nyx and 
tor-prompt
is needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by wagon):

 * keywords:  nyx =>


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

Re: [tor-bugs] #28294 [Core Tor/Nyx]: Nyx crashes at graph resizing

[Tor Bug Tracker & Wiki]

#28294: Nyx crashes at graph resizing
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by wagon):

 * keywords:  nyx =>
 * reviewer:  atagar =>


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

Re: [tor-bugs] #28153 [Core Tor/Nyx]: Nyx memory leaks

[Tor Bug Tracker & Wiki]

#28153: Nyx memory leaks
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 I am sorry for off-topic. When I create tickets, for the component "Core
 Tor/Nyx" I can select only Tor version, but I expect it should be Nyx
 version instead. If I am right, that menu should be fixed in trac
 interface itself.

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

Re: [tor-bugs] #28297 [Core Tor/Nyx]: Control interpreter in nyx does not do line splitting

[Tor Bug Tracker & Wiki]

#28297: Control interpreter in nyx does not do line splitting
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by wagon):

 * keywords:  nyx =>
 * reviewer:  atagar =>
 * component:  Applications => Core Tor/Nyx


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

Re: [tor-bugs] #14979 [Core Tor/Nyx]: Option to close circuit

[Tor Bug Tracker & Wiki]

#14979: Option to close circuit
--+
 Reporter:  intrigeri |  Owner:  atagar
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  connections   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by wagon):

 > you get an unexpected HTTPS or SSH warning, write down the info about
 your exit node, and close that circuit to get a fresh one and confirm your
 suspicions.
 You can already do it with `tor-prompt`, but it is not straightforward:
 1. Run `GETINFO stream-status` and get a number of the circuit associated
 to your SSH connection (IP or hostname will be written). It is the third
 parameter in each stream.
 2. Run `GETINFO circuit-status` and look for the circuit which has that
 circuit's number (from the step 1). It is the first parameter in each
 circuit.
 3. If you look at the line with the right circuit from the step 2, you can
 see fingerprint and nickname of your exit node (it was used for your SSH
 connection).
 4. To get more information on the exit node from the step 3, run the
 command `GETINFO ns/id/FINGERPRINT`. It will give you IP address. If you
 want to know also its country, run `GETINFO ip-to-country/IP_ADDRESS`.

 Now, if you want to change that circuit, you can either mark all already
 used circuits as dirty by typing `SIGNAL NEWNYM` command, or close only
 that particular circuit with the command `CLOSECIRCUIT CircuitNumber`,
 where CircuitNumber is taken from the step 1 (`tor` will create new
 circuit that stream automatically).

 You cannot do it with the help of the control interpreter of `nyx` because
 the bug [[https://trac.torproject.org/projects/tor/ticket/28297|#28297]]
 prevents you from learning your exit node.

 It could be done easily in `nyx` if its list of circuits include
 associated streams (somebody already proposed it in
 [[https://trac.torproject.org/projects/tor/ticket/5186|#5186]]).

 Potentially, you can create a custom circuit for your tests with the help
 of commands `EXTENDCIRCUIT`, `SETCIRCUITPURPOSE,` and `ATTACHSTREAM`, but
 if you haven't already automated this task, it may be simpler to
 temporarily fix your exit node globally (using `ExitNodes` option in
 `torrc`).

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

Re: [tor-bugs] #25302 [Core Tor/Nyx]: Cannot quit after using Control Interpreter

[Tor Bug Tracker & Wiki]

#25302: Cannot quit after using Control Interpreter
--+---
 Reporter:  slopdog   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 Also, I don't understand why do you need `qq` instead of `q`. Simply `q`
 should be enough to quit.

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

Re: [tor-bugs] #25302 [Core Tor/Nyx]: Cannot quit after using Control Interpreter

[Tor Bug Tracker & Wiki]

#25302: Cannot quit after using Control Interpreter
--+---
 Reporter:  slopdog   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Low   |  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 > Run nyx, cycle through to Control Interpreter, press [Enter] to start
 interpreter, type SIGNAL RELOAD[Enter], Press [Enter] to quit, cycle back
 to graph panel, type 'qq' to quit.
 I think you mean "Press [ESC] to quit" instead of "Press [Enter] to quit."
 Anyway, I cannot reproduce this problem on my Debian.

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

Re: [tor-bugs] #22731 [Core Tor/Tor]: Relative DataDirectory + RunAsDaemon = Tor can't read or write most of its datadirectory files

[Tor Bug Tracker & Wiki]

#22731: Relative DataDirectory + RunAsDaemon = Tor can't read or write most of 
its
datadirectory files
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  review-group-23  |  Actual Points:  .1
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+

Comment (by arma):

 Fyi, this fix got broken in 0.3.3.1-alpha because we split
 options->DataDirectory into options->DataDirectory_option: #28298.

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Confirmed that
 {{{
 diff --git a/src/or/config.c b/src/or/config.c
 index 2660fbd..43cc082 100644
 --- a/src/or/config.c
 +++ b/src/or/config.c
 @@ -3184,7 +3184,8 @@ warn_about_relative_paths(or_options_t *options)
n +=
 warn_if_option_path_is_relative("GeoIPv6File",options->GeoIPv6File);
n += warn_if_option_path_is_relative("Log",options->DebugLogFile);
n += warn_if_option_path_is_relative("AccelDir",options->AccelDir);
 -  n +=
 warn_if_option_path_is_relative("DataDirectory",options->DataDirectory);
 +  n += warn_if_option_path_is_relative("DataDirectory",
 +   options->DataDirectory_option);
n += warn_if_option_path_is_relative("PidFile",options->PidFile);

for (config_line_t *hs_line = options->RendConfigLines; hs_line;
 }}}
 fixes it for me.

 (Did we move any other warn_about_relative_paths() strings into a new
 foo_option variable?)

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Seems like we should either look at DataDirectory_option in
 warn_about_relative_paths(), or call validate_data_directories() earlier
 in options_validate(). My first thought is that the former is better
 (especially to fix the regression).

 Also, it would probably be wise to think about what sort of unit test
 would have caught 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] #27321 [Core Tor/Nyx]: incorrect bw calculation during initial startup

[Tor Bug Tracker & Wiki]

#27321: incorrect bw calculation during initial startup
--+
 Reporter:  a_p   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by wagon):

 > The very first value for download and upload bandwidth is always
 extremely and unreasonably high (3GB/s) and reaches the actual value one
 second after that.

 > The problem of this is the impact on the avg. bw value shown, which is
 distorted due to this incorrect first value.
 I see the same with `nyx` and client-only `tor` on Linux. At first,
 depending on terminal's width, the plot of bandwidth may have the width
 size of about 20 points (Ox, horizontal). At second, bandwidth scale in
 the plot may by dynamic (Oy, vertical). So, the correct values are plotted
 only after the first "impulse"  (moving to the right once per second)
 leaves the plot, i.e. after about 20 seconds.

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 (Found by weasel while he was trying to make a simple Tor test script)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  regression
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In 0.3.2.1-alpha we fixed #22731 (in commit 6fea44c6): we started refusing
 to start if RunAsDaemon is set and also any of a variety of config options
 are set to a relative value.

 And then in 0.3.3.1-alpha we did commit 192be006, which split the original
 options->DataDirectory into a new DataDirectory_option variable.

 But warn_about_relative_paths() continues to look at
 {{{
   n +=
 warn_if_option_path_is_relative("DataDirectory",options->DataDirectory);
 }}}

 and that function is called near the top of options_validate() -- before
 we call validate_data_directories() which is what populates
 options->DataDirectory.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28297 [Applications]: Control interpreter in nyx does not do line splitting

[Tor Bug Tracker & Wiki]

#28297: Control interpreter in nyx does not do line splitting
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Component:  Applications
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+--
 When `GETINFO circuit-status` is typed in control interpreter of `nyx`
 (2.0.4), long lines are not split. Therefore, full `tor`'s reply cannot be
 seen. It looks like (names of Tor nodes are fake):

 {{{
 >>> GETINFO circuit-status
 250+circuit-status=
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodeone,$FINGE
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodetwotwo2,$F
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~node11,$FINGER
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodethree1,$FI
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~tnode,$FINGERP
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~Unnamed,$FINGE
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~anothernode,$F
  BUILT $FINGERPRINT~NODENAME,$FINGERPRINT~nodenew2,$FING
 .
 250 OK
 }}}

 Other commands which output long lines may also have this problem.

 Interestingly, contrary to `nyx`, `tor-prompt` do line splitting
 correctly.

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

Re: [tor-bugs] #28153 [Core Tor/Nyx]: Nyx memory leaks

[Tor Bug Tracker & Wiki]

#28153: Nyx memory leaks
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

 * keywords:  nyx =>
 * cc: atagar (removed)
 * component:  Applications => Core Tor/Nyx
 * reviewer:  atagar =>


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

Re: [tor-bugs] #28295 [Core Tor/Nyx]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28295: Non-interactive way to supply ControlPort password for nyx and 
tor-prompt
is needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * cc: atagar (removed)
 * reviewer:  atagar =>
 * component:  Applications => Core Tor/Nyx


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

Re: [tor-bugs] #13433 [Applications/Tor Browser]: "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in my browser tree

[Tor Bug Tracker & Wiki]

#13433: "Update failed" from 4.0-alpha-3 on 32-bit when I have a large file in 
my
browser tree
--+--
 Reporter:  arma  |  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 arma):

 Maybe we should close this ticket in favor of #18186 ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28296 [Applications]: Nyx shows wrong IP address for ControlPort connection

[Tor Bug Tracker & Wiki]

#28296: Nyx shows wrong IP address for ControlPort connection
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Component:  Applications
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+--
 Nyx (2.0.4 installed using `python3-pip`) connects to Tor's `ControlPort`
 through `127.0.0.1:9051`, but in the window with circuit and other
 connections it shows

 {{{127.0.0.1:PORT (??)  -->  REAL_IP_ADDRESS:9051nyx (XXX)   + 1.8m
 (CONTROL)}}}

 where `REAL_IP_ADDRESS` is a real source IP for outgoing Tor packets to
 Internet. In this setup Tor is not listening at `REAL_IP_ADDRESS:9051`,
 i.e. `nyx`'s information is confusing. Instead of real IP `127.0.0.1` must
 be written:

 {{{127.0.0.1:PORT (??)  -->  127.0.0.1:9051nyx (XXX)   + 1.8m
 (CONTROL)}}}

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

Re: [tor-bugs] #28295 [Applications]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28295: Non-interactive way to supply ControlPort password for nyx and 
tor-prompt
is needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+--
Changes (by wagon):

 * type:  defect => enhancement


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

[tor-bugs] #28295 [Applications]: Non-interactive way to supply ControlPort password for nyx and tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28295: Non-interactive way to supply ControlPort password for nyx and 
tor-prompt
is needed
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Component:  Applications
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+--
 When Tor's `ControlPort` requires password authentication, `nyx` and `tor-
 prompt` ask it interactively. However, it must be also a way to specify
 the password in a command line or in config file. Earlier it was possible
 with `arm`'s option `startup.controlPassword`, which no longer works with
 `nyx`.

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

Re: [tor-bugs] #28153 [Applications]: Nyx memory leaks

[Tor Bug Tracker & Wiki]

#28153: Nyx memory leaks
--+---
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+---

Comment (by wagon):

 > run `nyx --debug` and add the log (redacted of any data you feel is
 private) to this ticket
 OK. I'll try 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] #28294 [Core Tor/Nyx]: Nyx crashes at graph resizing

[Tor Bug Tracker & Wiki]

#28294: Nyx crashes at graph resizing
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.8
 Severity:  Normal| Resolution:
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+--
Changes (by arma):

 * component:  Applications => Core Tor/Nyx


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28294 [Applications]: Nyx crashes at graph resizing

[Tor Bug Tracker & Wiki]

#28294: Nyx crashes at graph resizing
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Component:  Applications
  Version:  Tor: 0.3.4.8  |   Severity:  Normal
 Keywords:  nyx   |  Actual Points:
Parent ID:| Points:
 Reviewer:  atagar|Sponsor:
--+--
 Nyx (2.0.4 installed using `python3-pip`) has reproducible crash if the
 following is done:

 1. Press `g` for graph resizing.
 2. Press `down arrow` many times until `Events` sub-window will be
 completely hidden.
 3. Nyx crashes with the following log:

 {{{
 Traceback (most recent call last):
   File "/usr/local/bin/nyx", line 9, in 
 load_entry_point('nyx==2.0.4', 'console_scripts', 'nyx')()
   File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 176,
 in main
 nyx.starter.main()
   File "/usr/local/lib/python3.4/dist-packages/stem/util/conf.py", line
 289, in wrapped
 return func(*args, config = config, **kwargs)
   File "/usr/local/lib/python3.4/dist-packages/nyx/starter.py", line 118,
 in main
 nyx.curses.start(nyx.draw_loop, acs_support =
 config.get('acs_support', True), transparent_background = True, cursor =
 False)
   File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 217,
 in start
 curses.wrapper(_wrapper)
   File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
 return func(stdscr, *args, **kwds)
   File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 215,
 in _wrapper
 function()
   File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 243,
 in draw_loop
 keybinding.handle(key)
   File "/usr/local/lib/python3.4/dist-packages/nyx/panel/__init__.py",
 line 84, in handle
 self._action()
   File "/usr/local/lib/python3.4/dist-packages/nyx/panel/graph.py", line
 504, in _resize_graph
 nyx_interface().redraw()
   File "/usr/local/lib/python3.4/dist-packages/nyx/__init__.py", line 716,
 in redraw
 panel.redraw(force = force, top = occupied)
   File "/usr/local/lib/python3.4/dist-packages/nyx/panel/__init__.py",
 line 175, in redraw
 self._last_draw_size = nyx.curses.draw(self._draw, top = self._top,
 height = self.get_height(), draw_if_resized = draw_dimension)
   File "/usr/local/lib/python3.4/dist-packages/nyx/curses.py", line 740,
 in draw
 curses_subwindow = CURSES_SCREEN.subwin(subwindow_height,
 subwindow_width, top, left)
 _curses.error: curses function returned NULL
 }}}

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

Re: [tor-bugs] #28293 [Obfuscation/Pluggable transport]: Corrupted obfs4proxy executable after restarts when bridges were offline

[Tor Bug Tracker & Wiki]

#28293: Corrupted obfs4proxy executable after restarts when bridges were offline
-+-
 Reporter:  traumschule  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by traumschule):

 * Attachment "obfs4proxy" added.

 ./Browser/TorBrowser/Tor/PluggableTransports/obfs4proxy

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

Re: [tor-bugs] #28293 [Obfuscation/Pluggable transport]: Corrupted obfs4proxy executable after restarts when bridges were offline

[Tor Bug Tracker & Wiki]

#28293: Corrupted obfs4proxy executable after restarts when bridges were offline
-+-
 Reporter:  traumschule  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by traumschule):

 * Attachment "tor-launcher-failed-obfs4proxy.png" added.

 > Tor failed to establish a Tor network connection. Connecting to a relay
 directory failed (missing pluggable transport

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28293 [Obfuscation/Pluggable transport]: Corrupted obfs4proxy executable after restarts when bridges were offline

[Tor Bug Tracker & Wiki]

#28293: Corrupted obfs4proxy executable after restarts when bridges were offline
-+
 Reporter:  traumschule  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25502
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Testing bridges in TB 8.0.3 (with tor 0.3.4.8) two of the requested
 bridges were offline (see #28291) and bootstrapping was stuck at 71% (This
 is a known issue tor prior 0.3.5, see #25502).

 Going back and changing from requested to built in obfs4 bridges didn't
 have any effect, bootstrapping still hung.

 After restarting the browser it hung at 20%. Restarted the browser again
 and requested new bridges the UI told
 > Connecting to a relay directory failed (missing pluggable transport...
 (took debug and info logs, will attach them later)

 After a hint by dcf1 on IRC i turned on logging:
 > To enable obfs4proxy logging, edit Browser/TorBrowser/Data/Tor/torrc-
 defaults and add "--enableLogging --logLevel=INFO --unsafeLogging" to the
 "ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit" line.
 > Then the log will be written to
 Browser/TorBrowser/Data/Tor/pt_state/obfs4proxy.log

 {{{
 11/3/18, 05:44:15.821 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 11/3/18, 05:44:15.821 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 11/3/18, 05:44:15.821 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 11/3/18, 05:44:15.822 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 11/3/18, 05:44:16.722 [WARN] The communication stream of managed proxy
 './TorBrowser/Tor/PluggableTransports/obfs4proxy' is 'closed'. Most
 probably the managed proxy stopped running. This might be a bug of the
 managed proxy, a bug of Tor, or a misconfiguration. Please enable logging
 on your managed proxy and check the logs for errors.
 11/3/18, 05:44:16.722 [NOTICE] Ignoring directory request, since no bridge
 nodes are available yet.
 11/3/18, 05:44:17.788 [NOTICE] Bridge 'Unnamed' has both an IPv4 and an
 IPv6 address.  Will prefer using its IPv4 address (146.196.65.18:443)
 based on the configured Bridge address.
 11/3/18, 05:44:17.788 [NOTICE] Bootstrapped 5%: Connecting to directory
 server
 11/3/18, 05:44:17.790 [WARN] We were supposed to connect to bridge
 '102.253.68.166:43775' using pluggable transport 'obfs4', but we can't
 find a pluggable transport proxy supporting 'obfs4'. This can happen if
 you haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 11/3/18, 05:44:17.791 [WARN] Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Can't connect to bridge; PT_MISSING;
 count 1; recommendation warn; host
 8D5F75269D5E0D2B9A1B0FA3D5A3BCA0EFC7F313 at 102.253.68.166:43775)
 11/3/18, 05:44:17.809 [WARN] We were supposed to connect to bridge
 '146.196.65.18:443' using pluggable transport 'obfs4', but we can't find a
 pluggable transport proxy supporting 'obfs4'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 11/3/18, 05:44:17.809 [WARN] Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Can't connect to bridge; PT_MISSING;
 count 2; recommendation warn; host
 642201EDF4BF5E3898E4F34B930032B00E3BA27C at 146.196.65.18:443)
 11/3/18, 05:44:17.810 [WARN] We were supposed to connect to bridge
 '24.154.179.248:44673' using pluggable transport 'obfs4', but we can't
 find a pluggable transport proxy supporting 'obfs4'. This can happen if
 you haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 11/3/18, 05:44:17.810 [WARN] Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Can't connect to bridge; PT_MISSING;
 count 3; recommendation warn; host
 1AAEE6A3B52C69A3D74E9EDEEDE9F15BE3182C3F at 24.154.179.248:44673)
 11/3/18, 05:44:17.812 [NOTICE] Closing no-longer-configured Socks listener
 on 127.0.0.1:9150
 11/3/18, 05:44:17.812 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 11/3/18, 05:44:17.812 [NOTICE] Closing old Socks listener on
 127.0.0.1:9150
 }}}

 Run manually:
 {{{
 ./Browser/TorBrowser/Tor/PluggableTransports/obfs4proxy