[tor-bugs] #30478 [Webpages/Website]: Make it easier to find tb-manual

[Tor Bug Tracker & Wiki]

#30478: Make it easier to find tb-manual
-+--
 Reporter:  cypherpunks  |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Webpages/Website
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 It is hard to find tb-manual.torproject.org from www.torproject.org. I
 found only one link, anywhere. On the webpage for downloading, scroll
 halfway down to find it in a sentence in the middle of similar looking
 paragraphs. I found the manuals on 2019.www.torproject.org from the
 www.torproject.org Documentation heading much faster than I found tb-
 manual.torproject.org.

 It is easy to find support.torproject.org because it is on every page in
 the heading.

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

Re: [tor-bugs] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

[Tor Bug Tracker & Wiki]

#28780: circpadding: Add machine flag for not closing circuit if machine is 
active
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  6
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Freshly squashed nicely organized PR that addresses previous comments:
 https://github.com/torproject/tor/pull/1015

 Summary of branch:

  * Still hooks circuit_mark_for_close(), but the
 circpad_is_using_circuit_for_padding() function name and mechanism are
 much clearer.
  * Only one return branch in the circpad_is_using_circuit_for_padding()
 function keeps the circuit open. All others result in relinquishing
 ownership to
 circuit_mark_for_close()/circuit_expire_old_circuits_clientside().
  * It is easy to see that this one branch cannot hold the circuit open for
 more than CIRCPAD_DELAY_MAX_SECS (1.25hr) of inactivity on a circuit, even
 if it is deadlocked. This is also verified in the unit tests, by testing
 circuit_expire_old_circuits_clientside() directly.
  * If padding machines deadlock by ping-ponging (sending padding back and
 forth forever), then they will hit their machine-specific padding overhead
 limits, and cease padding. At which point, network activity on the circuit
 will cease, and circpad_is_using_circuit_for_padding() will return 0 and
 allow circuit_expire_old_circuits_clientside() to close the circuit
 (machine-specific padding limits are tested in a previously existing
 test).

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

Re: [tor-bugs] #25930 [Applications/Tor Browser]: Update gcc to 7.X

[Tor Bug Tracker & Wiki]

#25930: Update gcc to 7.X
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #30321| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 GCC 9.1 is better (#30475).
 About Firefox: https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-
 inter-procedural.html
 Hah: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702

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

Re: [tor-bugs] #29085 [Core Tor/Tor]: WTF-PAD: Reduce monotime usage because of performance issues

[Tor Bug Tracker & Wiki]

#29085: WTF-PAD: Reduce monotime usage because of performance issues
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 Ok I split that commit into the non-padding path refactoring (aka taking
 stuff out of circpad_remove_token) and the padding path (aka taking stuff
 out of the padding callback). It should hopefully be easier to see what
 went where, now: https://github.com/torproject/tor/pull/1014

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

Re: [tor-bugs] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

[Tor Bug Tracker & Wiki]

#28780: circpadding: Add machine flag for not closing circuit if machine is 
active
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  6
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 Replying to [comment:37 asn]:
 > FWIW, I did some testing with the latest of this branch and #28634, and
 I can confirm that this branch will eventually close the padding circuit
 as intended.

 Out of curiosity, did you discover this through a malfunctioning machine
 that deadlocked and hit the 1.25 hour timer, or with a well-behaved
 machine?

 I have been brainstorming for other failure modes, and I realized that
 malfunctioning machines can get caught in infinite padding loops -- as
 long as cells are being sent to each other, they will stick around
 (because that last_cell_time_sec field will keep getting updated due to
 the sent and/or received cells). I think this type of error is best
 safeguarded against by specifying padding limits on the machines, though,
 as I just suggested in ticket:28634#comment:23.

 I will add unit tests to cover this new expiry timer, and I will think
 more if anything can be tweaked in
 circuit_expire_old_circuits_clientside(), but right now I'm not seeing
 anything that will further address the immediate concerns of additional
 circuit-leak risk and code clarity, but I'm open to suggestions.

 I am tempted to say that refactoring how circuit_mark_for_close vs circuit
 expiry vs circuit build timeout vs measurement circuits vs pathbias vs
 padding takeover vs cannibalization vs other purpose changes all interact
 with circuit shutdown should be done in a modularization-sponsored ticket.
 There are lot of things that could benefit from some refactoring wrt
 circuit ownership, timeout, expiry, and shutdown paths, and I don't think
 it's the best move to rabbit hole down them under Sponsor2 if we can keep
 this particular change low-risk.

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

Re: [tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28632   | Points:  8
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  needs_review => needs_revision


Comment:

 This looks good! We're getting real close IMO.

 Last thing I can think of: As an extra safety mechanism, I think we should
 use the machine-specific padding limits allowed_padding_count = 20 and
 max_padding_percent = 1 on these two machines. That way we know that even
 if they go haywaire somehow, we have the padding limits to stop meltdown
 (and to log that we're hitting the limit and something is going wrong).

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

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by phw):

 We had a short discussion on IRC and concluded the following:
 * We don't want another central service that collects all the data.
 * A bridge can self-test by having its tor client establish a TCP
 connection with its obfs4 port (see #30477). Tor can then warn the
 operator in its log file if the test fails. Unfortunately, this won't help
 if we ever deploy a PT that speaks UDP.
 * Some operators will ignore their log files, though, so we will still be
 collecting unreachable obfs4 bridges. BridgeDB should therefore learn how
 to test all of its bridges by speaking their respective transport
 protocol. It should not hand out bridges that are unreachable or otherwise
 broken.

 We were left wondering what obfs4 operators should do in the short term,
 before #30477 is done, to figure out if their bridge is reachable. One way
 forward would be a simple web page, hosted by us, that asks for an IP
 address, and a port as input. The service then tries to establish a TCP
 connection to the given tuple, and lets the user know if it succeeded or
 failed. The service doesn't need to log or remember anything, and we can
 run it on polyanthum, the host that also runs BridgeDB.

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

Re: [tor-bugs] #29024 [Core Tor/Chutney]: Add pluggable-transport support to Chutney

[Tor Bug Tracker & Wiki]

#29024: Add pluggable-transport support to Chutney
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 041-accepted-20190115,   |  Actual Points:
  network-team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by phw):

 * cc: phw (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

[tor-bugs] #30477 [Core Tor/Tor]: Tor should self-test reachability of TCP listeners exposed by PT's

[Tor Bug Tracker & Wiki]

#30477: Tor should self-test reachability of TCP listeners exposed by PT's
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  tor-pt
Actual Points:|  Parent ID:  #30472
   Points:|   Reviewer:
  Sponsor:  Sponsor19 |
--+--
 It would be useful if Tor would do self-test of TCP port reachability for
 bridge listeners and not just the ORPort itself.

 Currently when a bridge operator starts their Bridge Relay, Tor will test
 whether their ORPort is available from the internet, but we do not test
 the reachability of, for example, the obfs4 TCP port.

 We believe that *just* testing for whether the port is available to the
 internet is better than to actually test if the port, for example, is able
 to speak the obfs4 protocol.

 We should probably have a way to disable the warning that is emitted if a
 port is not reachable if, for example, the bridge is actually lying to Tor
 about its port, does not have a port, or the port is exposed via UDP
 instead of TCP.

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

Re: [tor-bugs] #30475 [Core Tor/Tor]: hs_service.c: compile-time warning with GCC 9.1.1

[Tor Bug Tracker & Wiki]

#30475: hs_service.c: compile-time warning with GCC 9.1.1
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  040-must 035-backport  |  Actual Points:
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


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

Re: [tor-bugs] #30475 [Core Tor/Tor]: hs_service.c: compile-time warning with GCC 9.1.1

[Tor Bug Tracker & Wiki]

#30475: hs_service.c: compile-time warning with GCC 9.1.1
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  040-must 035-backport  |  Actual Points:  .1
Parent ID: | Points:  .1
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 See branch `bug30475_035` with PR at
 https://github.com/torproject/tor/pull/1013 . Should also merge cleanly
 into later branches.

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

Re: [tor-bugs] #30476 [Applications/Tor Browser]: uploaded Browser 8.0.9 - now i can't connect

[Tor Bug Tracker & Wiki]

#30476: uploaded Browser 8.0.9 - now i can't connect
--+---
 Reporter:  bfi   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * severity:  Blocker => Normal
 * component:  Applications => Applications/Tor Browser
 * priority:  High => Medium
 * version:  Tor: unspecified =>
 * owner:  (none) => tbb-team


Comment:

 Hi! Could you follow the steps in comment:4:ticket:30035 and let us know
 what you learn?

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

Re: [tor-bugs] #29259 [Circumvention/Snowflake]: Ensure high test coverage for Snowflake

[Tor Bug Tracker & Wiki]

#29259: Ensure high test coverage for Snowflake
-+--
 Reporter:  ahf  |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+--
Changes (by cohosh):

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


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

Re: [tor-bugs] #29259 [Circumvention/Snowflake]: Ensure high test coverage for Snowflake

[Tor Bug Tracker & Wiki]

#29259: Ensure high test coverage for Snowflake
-+--
 Reporter:  ahf  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+--
Description changed by cohosh:

Old description:

> We should aim for high test coverage and proper CI setup for Snowflake as
> early as possible in the process to ensure that we don't cause
> regressions or break things "randomly".
>
> We also don't currently have any proxy-go tests.

New description:

 We should aim for high test coverage and proper CI setup for Snowflake as
 early as possible in the process to ensure that we don't cause regressions
 or break things "randomly".

 Known issues:
 - We don't currently have any proxy-go tests.
 - Tests in `client/lib/rendezvous.go` rely on specific HTTP response
 bodies which is prone to change and unnecessary

--

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

Re: [tor-bugs] #29982 [Applications/Tor Browser]: Clicking on cog/gear icon crashes Tor Browser for Android

[Tor Bug Tracker & Wiki]

#29982: Clicking on cog/gear icon crashes Tor Browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3, tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:4 sysrqb]:
 > Quoting from the blog comment:
 > {{{
 > [...] the tor settings page is white and torbrowser freezes. not a
 significant
 > difference, I only have to terminate torbrowser manually now when its
 stuck in
 > that white page.
 > }}}
 >
 > I wonder if #30214 is the underlying bug of this.

 Does not seem to be the case. I try to get more debug information.

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

Re: [tor-bugs] #26348 [Circumvention/Snowflake]: Guard against large reads

[Tor Bug Tracker & Wiki]

#26348: Guard against large reads
---+---
 Reporter:  dcf|  Owner:  cohosh
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Circumvention/Snowflake|Version:
 Severity:  Normal | Resolution:
 Keywords:  easy anti-censorship-roadmap-2019  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 Here's another go: https://github.com/cohosh/snowflake/compare/large_reads

 The two copies of `limitedRead` are a bit smelly, but I'm not sure there's
 enough there that justifies a new shared library in `common/`

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

Re: [tor-bugs] #30284 [Applications/Tor Browser]: start fails with "Control port file not created"

[Tor Bug Tracker & Wiki]

#30284: start fails with "Control port file not created"
+--
 Reporter:  belm0   |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-8.5-must, TorBrowserTeam201905  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Huh, I wonder where this `torrc` file is coming from. Looks like it could
 need some clean-up.  echaskaris: what are the paths that got clipped on
 the screenshot?

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

Re: [tor-bugs] #30258 [Circumvention/Snowflake]: Snowflake proxy stops working during browsing session

[Tor Bug Tracker & Wiki]

#30258: Snowflake proxy stops working during browsing session
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:  snowflake|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---
Changes (by cohosh):

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


Comment:

 Thanks cypherpunks! Marking as closed (duplicate) since #30206 seems to
 have resolved 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] #30069 [Applications/Tor Browser]: Security slider and about:tor strings are untranslated in Tor Browser for Android

[Tor Bug Tracker & Wiki]

#30069: Security slider and about:tor strings are untranslated in Tor Browser 
for
Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  GeorgKoppen201904, tbb-parity, |
  TorBrowserTeam201905R  |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. I pushed the Torbutton changes (`master`, commit
 8877c1ecb16aec821dea8aa2282c845452cef24f) and the `tor-browser` ones on
 `tor-browser-60.6.1esr-8.5-1` (commit
 22d7c0ae06cbc722dae7d0f685b671ae6af25731).

 FWIW: I updated the README a while back to deal with the git submodule
 issues when testing patches. Did you see that:
 https://gitweb.torproject.org/builders/tor-browser-
 build.git/tree/README.HACKING#n254 (please amend it if it's not
 sufficient).

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

Re: [tor-bugs] #30319 [Applications/Tor Browser]: Drop FTE related bits in Tor Browser

[Tor Bug Tracker & Wiki]

#30319: Drop FTE related bits in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-rbm,   |  Actual Points:
  TorBrowserTeam201905R, GeorgKoppen201905   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-rbm, TorBrowserTeam201905, GeorgKoppen201905 =>
 ff68-esr, tbb-rbm, TorBrowserTeam201905R, GeorgKoppen201905
 * status:  new => needs_review


Comment:

 `bug_30319_v2` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_30319_v2=9434516fe866d5b4da76012caa4ad8cd3fbe5487)
 has the fix for 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] #30476 [Applications]: uploaded Browser 8.0.9 - now i can't connect

[Tor Bug Tracker & Wiki]

#30476: uploaded Browser 8.0.9 - now i can't connect
--+--
 Reporter:  bfi   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications  |Version:  Tor: unspecified
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bfi):

 * Attachment "Screen Shot 2019-05-10 at 16.50.50.png" added.

 Restart 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

[tor-bugs] #30476 [Applications]: uploaded Browser 8.0.9 - now i can't connect

[Tor Bug Tracker & Wiki]

#30476: uploaded Browser 8.0.9 - now i can't connect
--+--
 Reporter:  bfi   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Component:  Applications
  Version:  Tor: unspecified  |   Severity:  Blocker
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Hi,

 I keep getting a message that Tor quit unexpectedly, restart etc. but it
 won't restart, and i can't copy the log to paste. please help.

 MAC OS 10.10.5

 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] #30419 [Internal Services/Tor Sysadmin Team]: Apache's server-status page accessible via TPO onion services

[Tor Bug Tracker & Wiki]

#30419: Apache's server-status page accessible via TPO onion services
-+-
 Reporter:  Parckwart|  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 == Context

 As documented in the
 [https://metrics.torproject.org/collector.html#webstats metrics pages],
 Tor webservers do not keep logs of visitors. The webserver (Apache) itself
 keeps those IP addresses in memory during the lifetime of the connection.
 This information can be disclosed on a /server-status page that is usually
 visible only to inside monitoring systems. A configuration error was
 introduced on March 19th 2019 which allowed onion services to access that
 page which could be used to access that information. This issue was
 reported in the Trac bugtracker (issue #30419) on May 6th 2019 and was
 fixed within the hour.

 == Mitigation

 The server-status page was checked and the issue was confirmed. A check in
 the git history found the bug and resolved it, and an audit was performed
 to see if the issue was correctly resolved. Analysis of the logs suggests
 there wasn't a significant increase in requests to /server-status.

 Patch that introduced the bug:

 {{{
 commit 8ba7d37b9b2e2431e201752a1eb69a9bcce483e1
 Date:   Tue Mar 19 16:50:44 2019 -0400

 port server-status configuration to Apache 2.4

 I verified that all hosts run at least Apache 2.4.10-10+deb8u13,
 shipped with Debian jessie.

 This is necessary for the apache collector to work.

 diff --git a/modules/apache2/files/common/etc/apache2/conf.d/server-status
 b/modules/apache2/files/common/etc/apache2/conf.d/server-status
 index 1a44e9b9..9362bcc2 100644
 --- a/modules/apache2/files/common/etc/apache2/conf.d/server-status
 +++ b/modules/apache2/files/common/etc/apache2/conf.d/server-status
 @@ -11,8 +11,6 @@
  ExtendedStatus on
  
  SetHandler server-status
 -Order deny,allow
 -Deny from all
 -Allow from 127.0.0.1
 +Require local
  
  
 }}}

 Patch that fixed it:

 {{{
 commit 19d5a30ca88fba4aa57d2574774c72d344114b1a
 Date:   Mon May 6 19:47:36 2019 -0400

 hide server-status from tor hidden services

 This is a hotfix for bug #30419 which correctly identified that the
 server-status pages are accessible when the webserver is accessed
 through the hidden service. It's unclear to me why "local" isn't
 equivalent to "127.0.0.1" but this fixes the problem on
 troodi/trac/ea5faa5po25cf7fb.onion so I'm satisfied.

 This was a regression introduced since march 19th, in commit
 8ba7d37b9b2e2431e201752a1eb69a9bcce483e1.

 diff --git a/modules/apache2/files/common/etc/apache2/conf.d/server-status
 b/modules/apache2/files/common/etc/apache2/conf.d/server-status
 index 9362bcc2..0da33673 100644
 --- a/modules/apache2/files/common/etc/apache2/conf.d/server-status
 +++ b/modules/apache2/files/common/etc/apache2/conf.d/server-status
 @@ -11,6 +11,6 @@
  ExtendedStatus on
  
  SetHandler server-status
 -Require local
 +Require ip 127.0.0.1
  
  
 }}}

 == Timeline

 All times in UTC starting on 2019-05-07:

  * 22:56:49 bug #30419 opened
  * 23:36:04 noticed by anarcat
  * 23:38:00 source of the problem identified
  * 23:47:36 patch implemented
  * 23:50:46 patch pushed to puppet
  * 23:50:57 issue claimed by anarcat
  * 00:00:00 (approximate) fix deployed everywhere, checks started
  * 00:38:30 all .onion sites from onion.tpo and ticket audited
  * 00:49:00 this report started
  * 01:14:00 audit of the webserver logs completed

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

Re: [tor-bugs] #19496 [Internal Services/Service - deb.tpo]: Remove deb.tpo obfs4proxy Debian packages

[Tor Bug Tracker & Wiki]

#19496: Remove deb.tpo obfs4proxy Debian packages
-+-
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  debian,packaging,obfs4proxy  |  Actual Points:
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 If we proceed with deleting them, we can also close #18796, and
 update/simplify the output of #20643.

 There are some more recent versions of obfs4proxy:
 https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/tree/ChangeLog
 but none of them seem critical to get from the obfs4 server side.

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

Re: [tor-bugs] #19496 [Internal Services/Service - deb.tpo]: Remove deb.tpo obfs4proxy Debian packages (was: Provide backports for obfs4proxy Debian packages)

[Tor Bug Tracker & Wiki]

#19496: Remove deb.tpo obfs4proxy Debian packages
-+-
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - deb.tpo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  debian,packaging,obfs4proxy  |  Actual Points:
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * owner:  (none) => irl
 * status:  new => assigned
 * component:  Circumvention/Obfs4 => Internal Services/Service - deb.tpo


Comment:

 I'm hijacking this ticket to be about removing our separate, unmaintained,
 obfs4proxy packages.

 We're shipping obfs4proxy 0.0.7-1 on deb.tpo.

 weasel points out that since go statically compiles stuff, that old
 package is shipping with a go that now has security bugs. That's no good.

 In the mean time, Debian stable now has 0.0.7-1+b2, which presumably is
 where the underlying go libs got rebuilt.

 Everything else we care about has at least that version of obfs4proxy too,
 except Ubuntu 16.04, which still ships with 0.0.6-2.

 So the most straightforward thing to do is to get rid of our obfs4proxy
 component in deb.tpo -- nobody should be using it. And to fix the
 documentation that tells people to add that repo to their apt sources,
 e.g.
 
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy

 And then if folks want to make debs for newer versions of obfs4proxy, we
 should get those into debian testing, and reevaluate once that's done.

 Sound plausible?

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

Re: [tor-bugs] #28044 [Applications/Tor Launcher]: Integrate Tor Launcher into tor-browser

[Tor Bug Tracker & Wiki]

#28044: Integrate Tor Launcher into tor-browser
-+-
 Reporter:  gk   |  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, ux-team,   |  Actual Points:
  TorBrowserTeam201905R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review
 * keywords:  AffectsTails, ux-team, TorBrowserTeam201905 => AffectsTails,
 ux-team, TorBrowserTeam201905R


Comment:

 Replying to [comment:20 gk]:
 > b7e7058359b402e9f37e27a86b99b68702189cdb - looks good
 > 80cedf677bb43d10c6b37902ca22af7650752bf0 just one white space between
 "locale" and "torlauncher" (in `+% locale   torlauncher en-US %locale/en-
 US/`) as used for the other locales and no "/" at the end of `locale/en-
 US/` as done with the other locales, otherwise this looks good
 > 2dd09cb68db2b267cd12db7ce542406791fd6ef7 - there are some conflicts with
 the languages strings (sorry for that), otherwise this looks good

 We rebased the above changes and fixed the en-US locale issues that you
 found. We chose to add a trailing / for the non-en-US locales (by
 modifying import-translations.sh) since the results are more consistent
 with what Mozilla does. For example, see
 browser/extensions/pocket/locale/jar.mn. The three new tor-launcher
 patches are available on the bug28044-02 branch within the brade repo::
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/log/?h=bug28044-02


 > > There is one tor-browser commit:
 > > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug28044-01=79f8ea9c98c69eb594e7d2aace9199b3bceb22cb
 >
 > Looks good to me.

 Rebased:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug28044-02=70e8a9a20fea7bc4036fb1e8af01c65a82089f79

 > > And one tor-browser-build commit:
 > > https://gitweb.torproject.org/user/brade/tor-browser-
 build.git/commit/?h=bug28044-01=90a8ef3543cddebc2bfa946351c9eacc58641dd9
 >
 > Looks good to me.

 Rebased:
 https://gitweb.torproject.org/user/brade/tor-browser-
 build.git/commit/?h=bug28044-02=6d94f73dc055c1739a67ffd422f7f5bf29218723

 > > We also need to update the proposal to account for feedback we
 received from Tails as well as a couple of other things we learned; we
 will do that soon.
 >
 > Okay, works for me in a follow-up ticket.

 I filed #30473 for that 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

[tor-bugs] #30475 [Core Tor/Tor]: hs_service.c: compile-time warning with GCC 9.1.1

[Tor Bug Tracker & Wiki]

#30475: hs_service.c: compile-time warning with GCC 9.1.1
--+---
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  040-must 035-backport
Actual Points:|  Parent ID:
   Points:  .1|   Reviewer:
  Sponsor:|
--+---
 I tried building with GCC 9.1.1 for the first time, and got various
 warnings.

 {{{
 make[1]: Entering directory '/home/nickm/src/tor-035'
   CC   src/feature/hs/hs_service.o
 In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
  from ./src/core/or/or.h:32,
  from src/feature/hs/hs_service.c:11:
 In function ‘load_client_keys’,
 inlined from ‘load_service_keys’ at
 src/feature/hs/hs_service.c:1090:7,
 inlined from ‘hs_service_load_all_keys’ at
 src/feature/hs/hs_service.c:4010:9:
 ./src/lib/log/log.h:244:3: error: ‘%s’ directive argument is null [-Werror
 =format-overflow=]
   244 |   log_fn_(LOG_WARN, domain, __FUNCTION__, args, ##__VA_ARGS__)
   |   ^~~~
 src/feature/hs/hs_service.c:1267:7: note: in expansion of macro ‘log_warn’
  1267 |   log_warn(LD_REND, "Client authorization file %s can't be
 read. "
   |   ^~~~
 src/feature/hs/hs_service.c: In function ‘hs_service_load_all_keys’:
 src/feature/hs/hs_service.c:1267:52: note: format string is defined here
  1267 |   log_warn(LD_REND, "Client authorization file %s can't be
 read. "
   |^~
 cc1: all warnings being treated as errors
 make[1]: *** [Makefile:9877: src/feature/hs/hs_service.o] Error 1
   CC   src/feature/hs/core_libtor_app_testing_a-hs_service.o
 In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
  from ./src/core/or/or.h:32,
  from src/feature/hs/hs_service.c:11:
 In function ‘load_client_keys’,
 inlined from ‘load_service_keys’ at
 src/feature/hs/hs_service.c:1090:7,
 inlined from ‘hs_service_load_all_keys’ at
 src/feature/hs/hs_service.c:4010:9:
 ./src/lib/log/log.h:244:3: error: ‘%s’ directive argument is null [-Werror
 =format-overflow=]
   244 |   log_fn_(LOG_WARN, domain, __FUNCTION__, args, ##__VA_ARGS__)
   |   ^~~~
 src/feature/hs/hs_service.c:1267:7: note: in expansion of macro ‘log_warn’
  1267 |   log_warn(LD_REND, "Client authorization file %s can't be
 read. "
   |   ^~~~
 src/feature/hs/hs_service.c: In function ‘hs_service_load_all_keys’:
 src/feature/hs/hs_service.c:1267:52: note: format string is defined here
  1267 |   log_warn(LD_REND, "Client authorization file %s can't be
 read. "
   |^~
 cc1: all warnings being treated as errors
 make[1]: *** [Makefile:1: src/feature/hs/core_libtor_app_testing_a-
 hs_service.o] Error 1
 make[1]: Target 'all-am' not remade because of errors.
 make[1]: Leaving directory '/home/nickm/src/tor-035'
 make: *** [Makefile:5788: all] Error 2
 [1016]$
 }}}

 It looks like this is a real bug: when there's something wrong with the
 client authorization file, we first free and null the file, and only log
 its contents afterwards.

 This appears to affect 0.3.5 and later.

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

Re: [tor-bugs] #19496 [Circumvention/Obfs4]: Provide backports for obfs4proxy Debian packages

[Tor Bug Tracker & Wiki]

#19496: Provide backports for obfs4proxy Debian packages
-+
 Reporter:  irl  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  debian,packaging,obfs4proxy  |  Actual Points:
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by phw):

 It's been a few years and obfs4proxy is now in
 [https://packages.debian.org/search?keywords=obfs4proxy Debian stable] and
 [https://packages.ubuntu.com/search?keywords=obfs4proxy all currently-
 supported Ubuntu flavours].

 The question is: are these packages recent enough? Debian's oldest package
 is 0.0.7, in stable, and Ubuntu's oldest package is 0.0.6, in xenial
 (16.04 LTS).

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

Re: [tor-bugs] #19496 [Circumvention/Obfs4]: Provide backports for obfs4proxy Debian packages

[Tor Bug Tracker & Wiki]

#19496: Provide backports for obfs4proxy Debian packages
-+
 Reporter:  irl  |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  debian,packaging,obfs4proxy  |  Actual Points:
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by phw):

 * parent:   => #30471


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

Re: [tor-bugs] #30069 [Applications/Tor Browser]: Security slider and about:tor strings are untranslated in Tor Browser for Android

[Tor Bug Tracker & Wiki]

#30069: Security slider and about:tor strings are untranslated in Tor Browser 
for
Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5-must,|  Actual Points:
  GeorgKoppen201904, tbb-parity, |
  TorBrowserTeam201905R  |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  needs_review => merge_ready


Comment:

 Okay, after much fighting with the git submodule I finally successfully
 tested this. It looks good to me!

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

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing (was: Implement a mechanism for PT rechability testing)

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | 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] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by n8fr8):

 Sure. I guess I will be implement this here:
 https://github.com/guardianproject/orfox

 so once it is up, and there are string files to localize we can do that.

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

Re: [tor-bugs] #28849 [Core Tor/Tor]: Handle dormant mode in process library and for PT's

[Tor Bug Tracker & Wiki]

#28849: Handle dormant mode in process library and for PT's
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+--

Comment (by dcf):

 Replying to [comment:7 ahf]:
 > I've tried to make a proposal patch here:
 https://github.com/ahf/torspec/commit/49d1cf355c350816ded4ea2e7d5772042aaa9d08

 This looks pretty good.

 * "The PT proxy SHOULD respond to the `FEATURES` message using the
 `FEATURES-ACK` message..."
   * Does the PT proxy necessarily have to wait for `FEATURES` before
 responding with `FEATURES-ACK`? It would be simpler if both sides just
 send a `FEATURES` line declaring their own features.
 * "...a comma-separated list of ''mutually supported'' features..."
   * Maybe the "mutually supported" isn't necessary. It's simpler if both
 sides just declare ''all'' the features they support. Otherwise you also
 have to specify what should happen if a PT proxy violates the spec and
 declares a feature set that is not a subset of the parent process's
 feature set--which is probably that the parent process should ignore the
 features it doesn't support, which amounts to the same.
 * "The PT proxy SHOULD respond to the `FEATURES` message..."
   * I think this needs some language saying what it means if the PT proxy
 does not respond to the `FEATURES` message (backward compatibility); i.e.,
 that the PT proxy's feature set is the empty set. Symmetrically for the PT
 proxy's interpretation: lack of a `FEATURES` option means the parent
 process's feature set is the empty set.
 * "Example message from parent process to PT proxy: `FEATURES
 dormant,x,y`"\\
   "Example response from PT proxy to parent proxy: `FEATURES-ACK
 dormant,y`"
   * I would like the spec to say what should happen when the feature set
 is empty. Specifically, whether a space character is required before the
 null list, `FEATURES` or `FEATURES `.
 * "...the `FEATURES` message that is written to the PT proxy's standard
 input."
   * Why is `FEATURES` on standard input, and not an environment variable
 like every other global configuration? There's no grammar yet in the spec
 for parent→PT standard input messages (presumably it looks like section
 3.3). If `FEATURES` is on standard input, what happens if it is sent more
 than once? What happens if it is sent more than once with different
 feature sets?
 * "Once the Pluggable Transport Specification version have been
 successfully negotiated..."
   * The spec should say when the PT proxy is allowed to send `FEATURES-
 ACK` is allowed and when it is not allowed. It has to be after `VERSION`.
 Can it come after `CMETHODS DONE` or `SMETHODS DONE`? What happens if the
 PT proxy sends it more than once?
 * "The PT proxy MUST acknowledge the request using: `SIGNAL DORMANT-ENTER-
 DONE`"
   * What happens if the parent process sends `SIGNAL DORMANT-ENTER` more
 than once without an intervening `SIGNAL DORMANT-EXIT`? Must the PT proxy
 acknowledge each one, even when it has not changed its own state? I.e.,
 are the acknowledgements edge-triggered or level-triggered?
   * Personally I would remove the MUST language here as it's kind of
 ineffectual--can a PT proxy reply with `SIGNAL DORMANT-ENTER-DONE` 60
 seconds later? Is the parent process going to wait and enforce the MUST?
 If not, it's not really a MUST. I feel the MUST language will encourage PT
 proxies to lie about their current state (I need to send `SIGNAL DORMANT-
 ENTER-DONE` because the spec says so, even if I currently am not capable
 of going dormant). What tor is really interested is not whether the PT
 proxy has received and understood the `SIGNAL DORMANT-ENTER` message, it's
 the points in time when the PT proxy actually changes its dormant state,
 so the spec should reflect that.
   * I would make the messages the same in both directions; e.g. use
 `SIGNAL DORMANT-ENTER` in both directions, without a special `SIGNAL
 DORMANT-ENTER-DONE` in the PT→parent direction.
 * Or even simplify more: `DORMANT ENTER` and `DORMANT EXIT`.

 Side note, one of the features I would like tor to advertise is `reads-
 stdout`, so a PT proxy can know whether it's safe to use `LOG` or not.

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

Re: [tor-bugs] #29263 [Core Tor/Chutney]: prop289: add bidirectional data transfers to chutney

[Tor Bug Tracker & Wiki]

#29263: prop289: add bidirectional data transfers to chutney
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, network-team-   |  Actual Points:  1
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Travis is complaining; I suspect there are some per-version issues to
 solve.

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

Re: [tor-bugs] #30331 [Circumvention/Pluggable transport]: obfs4_bridgeline.txt file should contain complete bridge line

[Tor Bug Tracker & Wiki]

#30331: obfs4_bridgeline.txt file should contain complete bridge line
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Pluggable transport|Version:
 Severity:  Normal   | Resolution:
 Keywords:  obfs4, bridge, anticensorship-   |  duplicate
  roadmap-can|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by arma):

 * parent:  #30471 =>


Comment:

 removing parent so we don't confuse #30471 by looking like this task is
 done

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

Re: [tor-bugs] #28152 [Applications/GetTor]: Gettor code refactor with Python Twisted

[Tor Bug Tracker & Wiki]

#28152: Gettor code refactor with Python Twisted
-+--
 Reporter:  ilv  |  Owner:  hiro
 Type:  enhancement  | Status:  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Major| Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28232   | Points:
 Reviewer:  phw  |Sponsor:  Sponsor19
-+--

Comment (by phw):

 I think it's a great idea to document the code, but it's orthogonal to my
 point that we should strive for clean git histories. Also, I'm happy to
 help, and polish the git history to the best of my abilities! Do you want
 me to make a pass over it?

 Finally, we should take care of the following remark, which seems to be an
 actual bug:
 > The last line in ​61973769 should probably be print_footer() and not
 print_footer.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30474 [Core Tor/Tor]: RFC: Tor should war about expiring keys much earlier (and leass annoying)

[Tor Bug Tracker & Wiki]

#30474: RFC: Tor should war about expiring keys much earlier (and leass 
annoying)
--+--
 Reporter:  toralf|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Component:  Core Tor/Tor
  Version:  Tor: 0.4.0.5  |   Severity:  Minor
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Currently it starts to complain 1 day before and complaints minutely - too
 late for operators being afk for week(s) or so.

 What's about warning once daily around 1 month ago, and hourly when 1 day
 left before expiration?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30473 [Applications/Tor Launcher]: update Tor Browser proposal 102 to account for Tails team feedback

[Tor Bug Tracker & Wiki]

#30473: update Tor Browser proposal 102 to account for Tails team feedback
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 We need to update proposal 102 "Integration of Tor Launcher into Tor
 Browser Core" to account for feedback we received from the Tails team
 (intrigeri). See the discussion here:
 https://lists.torproject.org/pipermail/tbb-dev/2019-February/000962.html
 https://lists.torproject.org/pipermail/tbb-dev/2019-February/000963.html
 https://lists.torproject.org/pipermail/tbb-dev/2019-February/000964.html

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

Re: [tor-bugs] #29734 [Circumvention/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:  2
Parent ID:  #29207   | Points:  1
 Reviewer:  ahf  |Sponsor:  Sponsor19
-+-

Comment (by cohosh):

 More on deployment:

 I tried the following steps on snowflake-broker:
 - add `deb https://deb.torproject.org/torproject.org stretch main` to
 /etc/apt/sources.list.d/tor.list
 - installed `tor-geoipdb` (which also installed `tor` and `torsocks`)
 - changed /etc/runit/snowflake-broker to:
 {{{
 exec chpst -u snowflake-broker /usr/local/bin/broker --acme-hostnames
 snowflake-broker.bamsoftware.com --acme-email d...@torproject.org
 --metrics-log /home/snowflake-broker/metrics.log 2>&1
 }}}

 But I'm still getting the error message
 {{{ 2019/05/10 18:07:13 open metrics.log: permission denied }}}

 I see that snowflake-broker is the owner of `/home/snowflake-broker` but
 it's assigned to group nogroup. Is that the cause of this problem?

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

Re: [tor-bugs] #30284 [Applications/Tor Browser]: start fails with "Control port file not created"

[Tor Bug Tracker & Wiki]

#30284: start fails with "Control port file not created"
+--
 Reporter:  belm0   |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-8.5-must, TorBrowserTeam201905  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by torlove):

 After the whole "addon signing fiasco" I decided to update to the latest.
 Knowing that it MUST also have the fix for the bug I reported over a month
 ago.

 I have this same problem. Kitkat 4.4.2

 "- Orbot is starting…
 - Tor control port file not created
 - Unable to start Tor: java.io.IOException: Control port file not created:
 /data/data/org.torproject.torbrowser_alpha/app_torservice/lib/tor/control.txt,
 len = 0

 Still have Orbot working with Orfox.

 In no position to install debug versions at this stage.

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

Re: [tor-bugs] #28849 [Core Tor/Tor]: Handle dormant mode in process library and for PT's

[Tor Bug Tracker & Wiki]

#28849: Handle dormant mode in process library and for PT's
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+--
Changes (by dcf):

 * cc: dcf (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

[tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT rechability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT rechability testing
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  project  | Status:  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Pluggable  |Version:
  transport  |   Keywords:
 Severity:  Major|  reachability
Actual Points:   |  Parent ID:  #30471
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Non-vanilla bridges currently have no way to automatically test their
 reachability. Vanilla bridges
 [https://gitweb.torproject.org/torspec.git/tree/path-spec.txt#n193 self-
 test the reachability of their ORPort] by creating a circuit that includes
 themselves, but we cannot do this for, say, obfs4. In practice, this is
 problematic because obfs4 operators won't know if their bridge is
 unreachable; for example due to NAT. In fact, BridgeDB is distributing
 obfs4 bridges that aren't actually reachable.

 We need to build a mechanism that allows non-vanilla bridges to test their
 reachability. Ideally, something would create a circuit over the bridge
 while speaking its respective transport protocol but even a simple TCP or
 UDP-based reachability test would already go a long way.

 Looking at the discussion
 [https://trac.torproject.org/projects/tor/ticket/30331#comment:2 over in
 #30331], tor seems to be the right component to trigger the reachability
 test. In its log files, it can then yell at the operator if the test
 failed. The question is: how should we design the mechanism that
 implements the reachability test?

 One solution would be a simple HTTP API that takes as input an address,
 port, a transport type, and optional parameters, and then tells you if the
 given bridge is reachable, e.g.: the URL https://pt-
 reachable.torproject.org/obfs4/1.2.3.4/9002 may respond with something
 along the lines of `obfs4_reachable: true`. Ideally, if the reachability
 test fails, we should provide details, to help the operator figure out
 what went wrong.

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

Re: [tor-bugs] #20943 [Circumvention/Obfs4]: Clarify documentation for obfs4 setup

[Tor Bug Tracker & Wiki]

#20943: Clarify documentation for obfs4 setup
-+
 Reporter:  kaie |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by phw):

 * parent:   => #30471


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

Re: [tor-bugs] #29128 [Core Tor/Tor]: Place complete obfs4 bridge line in accessible location

[Tor Bug Tracker & Wiki]

#29128: Place complete obfs4 bridge line in accessible location
-+-
 Reporter:  phoul|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, tor-doc, |  Actual Points:
  040-deferred-20190220  |
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by phw):

 * parent:   => #30471


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

Re: [tor-bugs] #30331 [Circumvention/Pluggable transport]: obfs4_bridgeline.txt file should contain complete bridge line

[Tor Bug Tracker & Wiki]

#30331: obfs4_bridgeline.txt file should contain complete bridge line
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Pluggable transport|Version:
 Severity:  Normal   | Resolution:
 Keywords:  obfs4, bridge, anticensorship-   |  duplicate
  roadmap-can|  Actual Points:
Parent ID:  #30471   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by phw):

 * parent:   => #30471


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

Re: [tor-bugs] #29263 [Core Tor/Chutney]: prop289: add bidirectional data transfers to chutney

[Tor Bug Tracker & Wiki]

#29263: prop289: add bidirectional data transfers to chutney
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, network-team-   |  Actual Points:  1
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by nickm):

 * status:  accepted => 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] #29263 [Core Tor/Chutney]: prop289: add bidirectional data transfers to chutney

[Tor Bug Tracker & Wiki]

#29263: prop289: add bidirectional data transfers to chutney
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, network-team-   |  Actual Points:  1
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-

Comment (by nickm):

 See branch `bidi` with PR at https://github.com/torproject/chutney/pull/28

 This was much easier than I'd expected, once I refactored Traffic.py to be
 a little more ergonomic.

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

Re: [tor-bugs] #27548 [Core Tor/Chutney]: chutney: HS v3 client authorization network template/configuration (was: chutney: HS v3 client authorization netowkr template/configuration)

[Tor Bug Tracker & Wiki]

#27548: chutney: HS v3 client authorization network template/configuration
--+--
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs ci |  Actual Points:
Parent ID:  #27544| 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] #28521 [Archived/FTE]: fte is not working using default tor browser bridges

[Tor Bug Tracker & Wiki]

#28521: fte is not working using default tor browser bridges
--+
 Reporter:  boklm |  Owner:  kpdyer
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Archived/FTE  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by phw):

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


Comment:

 Replying to [comment:12 kpdyer]:
 > Maybe it's best to remove them from the Tor Browser? That is unless
 someone else is willing to assume ownership.

 We retired these bridges over in #30457. Thanks for having run these,
 Kevin!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30471 [Circumvention/Obfs4]: Improve UX for obfs4 bridge operation

[Tor Bug Tracker & Wiki]

#30471: Improve UX for obfs4 bridge operation
-+
 Reporter:  arma |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Obfs4  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Right now there are some sharp edges if you want to operate an obfs4
 bridge: you have to set up port forwarding, it's hard to know whether it's
 working, it's hard to figure out your bridge line, etc.

 This is a master ticket for collecting these UX issues, so we can capture
 all of them and make progress on fixing 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] #29734 [Circumvention/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:  2
Parent ID:  #29207   | Points:  1
 Reviewer:  ahf  |Sponsor:  Sponsor19
-+-

Comment (by cohosh):

 Replying to [comment:30 dcf]:
 > While you are waiting for feedback on #21315, I think it would be okay
 to do a provisional deployment of (say) 7 days in order to get an idea of
 what a typical metrics.log file looks like. In our
 [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-05-09-17.01.log.html meeting today], cohosh suggested
 removing the proxy geoip information from /debug during the provisional
 deployment, and only storing it in metrics.log.

 I did this and a few other things to make it work better with our specific
 deployment: https://github.com/cohosh/snowflake/compare/geoip_squashed

 - the broker wasn't failing correctly if the hardcoded "metrics.log" file
 couldn't be opened so I added a command-line option to specify this file,
 or default to Stdout. I also made sure to LogFatal if the specified file
 can't be opened. This required a bit of refactoring.

 - Fixed the log output to not print an extra newline character

 - Removed the {{{if country != "" {} }}} condition and added the
 documentation as requested 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] #29263 [Core Tor/Chutney]: prop289: add bidirectional data transfers to chutney

[Tor Bug Tracker & Wiki]

#29263: prop289: add bidirectional data transfers to chutney
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, network-team-   |  Actual Points:  1
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by nickm):

 * status:  new => accepted
 * owner:  (none) => nickm
 * actualpoints:   => 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] #29664 [Webpages/Website]: Create release notes page at torproject.org

[Tor Bug Tracker & Wiki]

#29664: Create release notes page at torproject.org
--+---
 Reporter:  antonela  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #25640| Points:
 Reviewer:|Sponsor:
--+---
Changes (by antonela):

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


Comment:

 https://dip.torproject.org/web/tpo/issues/11

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

Re: [tor-bugs] #30370 [Webpages/Website]: Unify headers and footers for all portals

[Tor Bug Tracker & Wiki]

#30370: Unify headers and footers for all portals
--+---
 Reporter:  antonela  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by antonela):

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


Comment:

 https://dip.torproject.org/web/tpo/issues/12

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 Replying to [comment:16 steph]:
 > Try Tor Browser
 > Orfox is now Tor Browser.
 > Get it from your preferred source:

 Perfect!

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/29955/Orfox%20Download.2.png, 300px)]]

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 Replying to [comment:18 n8fr8]:
 > Could you make a squished Orfox underneath the new icon?
 > "Orfox is dead! Long Live Tor Browser!"

 XD

 I synced it here so you can grab the assets. Please, let me know if
 anything else is needed.
 https://marvelapp.com/33d23hc/screen/56744451/handoff

 We need some localized strings for this. Should we bring emmapeel to the
 party?

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "Orfox Download.2.png" added.


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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:13 antonela]:
 > Hi! Is not clear to me what is better/doable. If Orfox users can update
 Orfox and get Tor Browser, that'd be ideal. If not we can offer them to
 download from the options we have.
 > I made mockups for both scenarios, to have in Orfox.
 > We need Steph's review on this. *Somewhere* we should say that you don't
 need two apps for browsing anymore.
 >

 These look so good! Thanks! Unfortunately users can't upgrade directly
 from Orfox to Tor Browser, so they must go through these steps (install
 new app and uninstall orfox).

 I think we can say "Orfox is now Tor Browser", and we can gives users the
 F-Droid button if they currently have F-Droid installed, and similar for
 Google Play. Downloading directly from the website is a little risky, but
 I'm not totally against it. If we include this option, then we'll need
 additional verification added into the orfox update (verifying the
 signature is valid), but it's possible.

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by steph):

 They both look great! I think if the 2nd version is used (I like the idea
 of showing the options), I would just suggest the language be "Get the
 update from your preferred source:"

 Also, I think we decided that we no longer needed to say "for Android." So
 that could just be "Try Tor Browser"

 So it'd be:

 Try Tor Browser
 Orfox is now Tor Browser.
 Get it from your preferred source:

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by n8fr8):

 Could you make a squished Orfox underneath the new icon?

 "Orfox is dead! Long Live 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] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by n8fr8):

 Cool. Thanks for all this. I think having all 3 options is fine and
 necessary.

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

Re: [tor-bugs] #30470 [Applications/Tor Browser]: tbb search window behavior not as expected

[Tor Bug Tracker & Wiki]

#30470: tbb search window behavior not as expected
--+--
 Reporter:  babs  |  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:
--+--
Changes (by mcs):

 * owner:  (none) => tbb-team
 * version:  Tor: unspecified =>
 * component:  Core Tor => Applications/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] #30467 [Core Tor/Tor]: sendme: Fix coverity CID 1444999

[Tor Bug Tracker & Wiki]

#30467: sendme: Fix coverity CID 1444999
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sendme, tor-relay, 041-must, |  Actual Points:
  coverity   |
Parent ID:  #26288   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by catalyst):

 * keywords:  sendme, tor-relay, 041-must => sendme, tor-relay, 041-must,
 coverity


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

Re: [tor-bugs] #28849 [Core Tor/Tor]: Handle dormant mode in process library and for PT's

[Tor Bug Tracker & Wiki]

#28849: Handle dormant mode in process library and for PT's
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+--
Changes (by ahf):

 * status:  new => needs_review


Comment:

 I've tried to make a proposal patch here:
 https://github.com/ahf/torspec/commit/49d1cf355c350816ded4ea2e7d5772042aaa9d08

 I think it works like you describe in (3) that it's purely asynchronous
 and it always behaves as a hint to the PT that now is the time for the PT
 to enter its dormant state. If the PT is busy with something, it will wait
 a bit, and respond once its able to fulfill the request.

 This spec update also contains your (1) where the Tor process and the PT
 negotiates supported features. If the PT does NOT announce dormant
 support, Tor wont send the "SIGNAL DORMANT-*" events. All events in the
 update must be confirmed by either Tor or the PT as per (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

[tor-bugs] #30470 [Core Tor]: tbb search window behavior not as expected

[Tor Bug Tracker & Wiki]

#30470: tbb search window behavior not as expected
--+--
 Reporter:  babs  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 tbb 8.0.9, on linux mint 18.3...

 in trying to clear search history, right click in right search window for
 pop-up menu. as mouse hovers over any menu entry, same 'search using ...'
 message appears (... in example is duckduckgo).  any left click brings up
 search engine menu. does not clear, rather just pops same window.

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * cc: steph (added)


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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 Hi! Is not clear to me what is better/doable. If Orfox users can update
 Orfox and get Tor Browser, that'd be ideal. If not we can offer them to
 download from the options we have.
 I made mockups for both scenarios, to have in Orfox.
 We need Steph's review on this. *Somewhere* we should say that you don't
 need two apps for browsing anymore.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/29955/Orfox%20Update.png, 300px)]]
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/29955/Orfox%20Download.png, 300px)]]

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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "Orfox Download.png" added.


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

Re: [tor-bugs] #29955 [Applications/Tor Browser]: Final Orfox update

[Tor Bug Tracker & Wiki]

#29955: Final Orfox update
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, tbb-8.5,|  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #27399   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * Attachment "Orfox Update.png" added.


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

Re: [tor-bugs] #30363 [Core Tor/Tor]: prop289: Implement FlowCtrl protover value

[Tor Bug Tracker & Wiki]

#30363: prop289: Implement FlowCtrl protover value
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, sendme, 041-must, asn-  |  Actual Points:
  merge  |
Parent ID:  #26288   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

 * keywords:  prop289, sendme, 041-must => prop289, sendme, 041-must, asn-
 merge
 * reviewer:   => nickm
 * status:  needs_review => merge_ready


Comment:

 lgtm

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

Re: [tor-bugs] #28930 [Core Tor/Tor]: consider reordering PT/proxy phases

[Tor Bug Tracker & Wiki]

#28930: consider reordering PT/proxy phases
-+-
 Reporter:  catalyst |  Owner:  ahf
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sponsor19-also, s8-bootstrap, pt,|  Actual Points:
  proxy, 040-deferred-20190220   |
Parent ID:  #28018   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by gaba):

 * points:   => 3


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

Re: [tor-bugs] #26844 [Applications/Tor Browser]: TBA: Investigate/Setup Fastlane

[Tor Bug Tracker & Wiki]

#26844: TBA: Investigate/Setup Fastlane
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-8.5, |  Actual Points:
  TorBrowserTeam201905   |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 About changelogs, as far as I know, Google Play and F-Droid will only show
 the exact entry for a given APK.  So that means each release needs a
 changelog txt file, even if the contents don't change.  What lots of
 people do with these changelogs/release notes/whatsNew fields is always
 fill it up, so including important changes from previous releases until
 the 500 char max is reached.  Not everyone does that.

 We're setting up Fastlane on Orbot now:
 https://github.com/n8fr8/orbot/pull/210

 I recommend adding `exiftool -all= *.png` somewhere to strip all metadata
 from images.  I don't know a metadata stripper for SVG.

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

Re: [tor-bugs] #30468 [Applications/Tor Browser]: Ship macedonian Tor Browser in alpha series (was: Ship makedonian Tor Browser in alpha series)

[Tor Bug Tracker & Wiki]

#30468: Ship macedonian Tor Browser in alpha series
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:  #29935| Points:
 Reviewer:|Sponsor:
--+--
Description changed by gk:

Old description:

> The makedonian translation is in good shape it seems. Let's ship a
> makedonian Tor Browser in our alpha series.

New description:

 The macedonian translation is in good shape it seems. Let's ship a
 makedonian Tor Browser in our alpha series.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30468 [Applications/Tor Browser]: Ship makedonian Tor Browser in alpha series

[Tor Bug Tracker & Wiki]

#30468: Ship makedonian Tor Browser in alpha series
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201905
Actual Points:|  Parent ID:  #29935
   Points:|   Reviewer:
  Sponsor:|
--+
 The makedonian translation is in good shape it seems. Let's ship a
 makedonian Tor Browser in our alpha series.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30469 [Applications/Tor Browser]: Ship romanian Tor Browser in alpha series

[Tor Bug Tracker & Wiki]

#30469: Ship romanian Tor Browser in alpha series
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201905
Actual Points:|  Parent ID:  #29935
   Points:|   Reviewer:
  Sponsor:|
--+
 The romanian translation is in good shape it seems. Let's ship a romanian
 Tor Browser in our alpha series.

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

Re: [tor-bugs] #29935 [Applications/Tor Browser]: TBB new locales ready to be shipped in alpha

[Tor Bug Tracker & Wiki]

#29935: TBB new locales ready to be shipped in alpha
--+--
 Reporter:  emmapeel  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201905  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-8.5, TorBrowserTeam201905 => TorBrowserTeam201905


Comment:

 Nothing for 8.5. We want to have alphas first.

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

Re: [tor-bugs] #30456 [Applications/Tor Browser]: TBA - Provide bridges with a magic link

[Tor Bug Tracker & Wiki]

#30456: TBA - Provide bridges with a magic link
--+--
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by n8fr8):

 Yes, please build on #15035. That was an important effort by eighthave /
 _hc.

 These links could also be distributed via chatbots built into Signal,
 WhatsApp, Telegram or other messaging services. This is something we are
 working on with other efforts and can advise.

 Separately, if the user scans a QR code with the system QR code scanner on
 Android, it can launch the browser. There is no need to a QR code scanner
 to be built in.

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

[tor-bugs] #30467 [Core Tor/Tor]: sendme: Fix coverity CID 1444999

[Tor Bug Tracker & Wiki]

#30467: sendme: Fix coverity CID 1444999
--+-
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sendme, tor-relay, 041-must
Actual Points:|  Parent ID:  #26288
   Points:  0.1   |   Reviewer:
  Sponsor:  SponsorV  |
--+-
 Doesn't seems very good but at least not released ;).

 {{{
 *** CID 1445000:  Null pointer dereferences  (FORWARD_NULL)
 /src/core/or/relay.c: 1952 in connection_edge_process_relay_cell()
 1946   log_info(domain,
 1947"'connected' received on circid %u for streamid
 %d, "
 1948"no conn attached anymore. Ignoring.",
 1949(unsigned)circ->n_circ_id, rh.stream_id);
 1950   return 0;
 1951 case RELAY_COMMAND_SENDME:
 >>> CID 1445000:  Null pointer dereferences  (FORWARD_NULL)
 >>> Passing null pointer "layer_hint" to "process_sendme_cell", which
 dereferences it.
 1952   return process_sendme_cell(, cell, circ, conn,
 layer_hint, domain);
 1953 case RELAY_COMMAND_RESOLVE:
 1954   if (layer_hint) {
 1955 log_fn(LOG_PROTOCOL_WARN, LD_APP,
 1956"resolve request unsupported at AP; dropping.");
 1957 return 0;
 }}}

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

[tor-bugs] #30466 [Core Tor/Tor]: hs: Do not allow more than one control cell on a circuit

[Tor Bug Tracker & Wiki]

#30466: hs: Do not allow more than one control cell on a circuit
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-dos, tor-hs, tor-relay
Actual Points: |  Parent ID:  #2
   Points:  0.1|   Reviewer:
  Sponsor:  Sponsor27-can  |
---+
 This is the list of HS control cell that is they are all for establishing
 a circuit or/and "connection" between HS entities (IP, RP, Service,
 client):

 {{{
 RELAY_COMMAND_ESTABLISH_INTRO:
 RELAY_COMMAND_ESTABLISH_RENDEZVOUS:
 RELAY_COMMAND_INTRODUCE1:
 RELAY_COMMAND_INTRODUCE2:
 RELAY_COMMAND_INTRODUCE_ACK:
 RELAY_COMMAND_INTRO_ESTABLISHED:
 RELAY_COMMAND_RENDEZVOUS1:
 RELAY_COMMAND_RENDEZVOUS2:
 RELAY_COMMAND_RENDEZVOUS_ESTABLISHED:
 }}}

 It appears that anyone can send an arbitrary amount of those cells on the
 same circuit. Even to the point that tor allows a rendezvous circuit to
 become an intro circuit.

 The only special one is `INTRODUCE2` which is by-design are sent a lot on
 the same circuit.

 The only cell currently limited to 1 cell is `INTRODUCE1` since we do not
 allow multiple introductions on the same client circuit for DoS reasons.

 But the rest should only be seen *once* on a circuit. Lets restrict them
 and if we see more, then we close the circuit due to a protocol error.
 This would limit side-channels.

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

Re: [tor-bugs] #30440 [Core Tor/Tor]: sendme: Service introduction circuit ignore flow control

[Tor Bug Tracker & Wiki]

#30440: sendme: Service introduction circuit ignore flow control
+
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, sendme  |  Actual Points:
Parent ID:  #15516  | Points:  2
 Reviewer:  |Sponsor:  Sponsor27-can
+

Comment (by dgoulet):

 After much discussions with armadev and asn, the ideal path forward is to
 use prop289 here.

 The service can know (with protover `FlowCtrl=1`) if the introduction
 point supports SENDME v1 and if it does, the service should then start
 emitting them on the intro circuit.

 For this to work, we need also the intro point to handle SENDME v1 which
 means decrease its `package_window` as INTRO2 cell comes in (not the
 current behavior). However, because the IP doesn't know if the service
 uses SENDME, it would only start accepting them once we switch on SENDME
 v1 in the network (`sendme_accept_min_version`) which could be some years
 down the road... But at least, in the meantime, service can start right
 now emitting SENDMEs v1 for any relay advertising `FlowCtrl=1`.

 1. There could be an argument for a new consensus param that control the
 usage of SENDMEs on the intro circuit which would be turned on much later
 since once we force that on the intro circuit, every service *NOT* sending
 SENDMEs on the circuit will stop working after 1000 cells because the
 intro point will reject anything due to flow control.

 2. Another approach is to make intro points right now start decreasing the
 package window and if it ends up to 0 and it doesn't get the SENDME at
 that point, the IP can deduce the service is not supporting it and thus we
 should continue operating like before. And this behavior will at some
 point fade out itself once every HS out there start using SENDME v1. I
 currently don't see much of a gain for a service to game this in the
 future, except maybe voluntarily allow the intro point to route a LOT of
 INTRO2 cells without flow control...? Again, we could switch off that
 feature with the consensus or simply by starting releasing a new stable
 not supporting this.

 Overall, this will introduce an information leak: the intro point will
 know that the service behind an intro circuit is >= "tor_version" ... asn
 and I aren't too worried about that since any new HS features has that
 "leak" once deployed on the network (ex: client auth).

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

Re: [tor-bugs] #30440 [Core Tor/Tor]: sendme: Service introduction circuit ignore flow control

[Tor Bug Tracker & Wiki]

#30440: sendme: Service introduction circuit ignore flow control
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  accepted
 Priority:  Very High|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, sendme, prop289  |  Actual Points:
Parent ID:  #15516   | Points:  2
 Reviewer:   |Sponsor:  Sponsor27-can
-+
Changes (by dgoulet):

 * owner:  (none) => dgoulet
 * priority:  High => Very High
 * status:  new => accepted
 * keywords:  tor-hs, sendme => tor-hs, sendme, prop289
 * milestone:  Tor: 0.4.2.x-final => Tor: 0.4.1.x-final


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

Re: [tor-bugs] #15516 [Core Tor/Tor]: Consider rate-limiting INTRODUCE2 cells when under load

[Tor Bug Tracker & Wiki]

#15516: Consider rate-limiting INTRODUCE2 cells when under load
-+-
 Reporter:  special  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  SponsorU-deferred, tor-dos, tor-hs,  |  Actual Points:
  network-team-roadmap-2019-Q1Q2 |
Parent ID:  #2   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-

Comment (by dgoulet):

 Because #30440 won't be a mature thing in the network for many years to
 come, we can only use the "package_window" proposal once it is.

 So until then, we'll use a token bucket system, add knobs in the consensus
 (like the dos.c subsystem) and go on from there. Not sure how we are going
 to come up with the values but they need to be large enough so it doesn't
 affect legit busy HS.

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

Re: [tor-bugs] #30454 [Core Tor/Tor]: hs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAY

[Tor Bug Tracker & Wiki]

#30454: hs-v3: INTRODUCE1 trunnel code doensn't handle
HS_INTRO_ACK_STATUS_CANT_RELAY
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 034-backport, 035-backport,  |  Actual Points:
  040-backport, 041-must |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #30382 [Core Tor/Tor]: Provide control port event for when we are missing v3 client auth for an onion

[Tor Bug Tracker & Wiki]

#30382: Provide control port event for when we are missing v3 client auth for an
onion
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tbb-usability, hs-auth  |  Actual Points:
Parent ID:  #14389  | Points:  6
 Reviewer:  |Sponsor:
|  Sponsor27-must
+--

Comment (by dgoulet):

 Lets go with SOCKS5 error extension code! We'll re-use the prop229 and
 open a new one for only extending error codes!

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

Re: [tor-bugs] #12454 [Applications/Tor Browser]: many PT components ship with "test" or "tests" directories

[Tor Bug Tracker & Wiki]

#12454: many PT components ship with "test" or "tests" directories
--+-
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #30319| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

 * parent:   => #30319


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

Re: [tor-bugs] #12381 [Archived/Obfsproxy]: Pluggable Transports + proxy is not working on Windows with Tor Browser

[Tor Bug Tracker & Wiki]

#12381: Pluggable Transports + proxy is not working on Windows with Tor Browser
---+-
 Reporter:  gk |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Archived/Obfsproxy |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tbb-helpdesk-frequent  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by gk):

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


Comment:

 Python PTs on Windows are gone for a while now. Closing as WONTFIX.

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

Re: [tor-bugs] #13726 [Applications/Tor Browser]: A bunch of Pluggable Transport related .pyd files depend on msvcr90.dll which we do not ship

[Tor Bug Tracker & Wiki]

#13726: A bunch of Pluggable Transport related .pyd files depend on msvcr90.dll
which we do not ship
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 This is a non-issue anymore with no PT for Windows based on Python.

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

Re: [tor-bugs] #30443 [Applications/Tor Browser]: NoScript still not working right, not sure if https everywhere is working right either, addons?

[Tor Bug Tracker & Wiki]

#30443: NoScript still not working right, not sure if https everywhere is 
working
right either, addons?
--+---
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  needs_information => closed
 * resolution:   => not a bug


Comment:

 Okay, I looked closer at that. NoScript is working as expected: JavaScript
 is blocked on the highest level and all the other prefs are properly
 flipped as well. In short it's not a NoScript problem.

 What happens is that for some (probably Yahoo-internal) reason a different
 landing page is loaded sometimes. I am not sure why you did not see that
 before but probably that's because Yahoo changed their logic recently.

 I tested older Tor Browser versions from before the 8.0.9 update and I see
 the same problem on a Windows machine as well. I am not sure why I don't
 see this on Linux, though.

 I double-checked as well that SVG (while loaded on that different page you
 encountered) is not executed when we set the slider pref. So, we are good
 here and this is not a bug.

 Regarding HTTPS Everywhere: this has never been a problem and that
 extension should never have been disabled as we have it exempt from the
 signature check because we use the EFF and not the Mozilla version.

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

Re: [tor-bugs] #30406 [Core Tor/sbws]: Refactor bandwidth file header constants

[Tor Bug Tracker & Wiki]

#30406: Refactor bandwidth file header constants
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.2.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #30255 | Points:  1
 Reviewer:  asn|Sponsor:
---+---
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Did a review. Might need revisions or just clarifications. Putting it in
 needs_revision anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30465 [Core Tor/Nyx]: Python error and program crash when pressing "m" menu key

[Tor Bug Tracker & Wiki]

#30465: Python error and program crash when pressing "m" menu key
--+--
 Reporter:  cypherpunks   |  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Nyx
  Version:  Tor: 0.3.5.8  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Running system:
 {{{
 FreeBSD hostname 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64
 }}}

 Packages:
 {{{
 tor-0.3.5.8
 nyx-2.1.0
 py36-stem-1.7.1
 }}}

 When I run Nyx and press the "m" key for the menu, I get the following
 error:

 {{{
 Traceback (most recent call last):
   File "/usr/local/bin/nyx", line 11, in 
 load_entry_point('nyx==2.1.0', 'console_scripts', 'nyx')()
   File "/usr/local/lib/python3.6/site-packages/nyx/__init__.py", line 176,
 in main
 nyx.starter.main()
   File "/usr/local/lib/python3.6/site-packages/stem/util/conf.py", line
 289, in wrapped
 return func(*args, config = config, **kwargs)
   File "/usr/local/lib/python3.6/site-packages/nyx/starter.py", line 128,
 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.6/site-packages/nyx/curses.py", line 219,
 in start
 curses.wrapper(_wrapper)
   File "/usr/local/lib/python3.6/curses/__init__.py", line 94, in wrapper
 return func(stdscr, *args, **kwds)
   File "/usr/local/lib/python3.6/site-packages/nyx/curses.py", line 217,
 in _wrapper
 function()
   File "/usr/local/lib/python3.6/site-packages/nyx/__init__.py", line 221,
 in draw_loop
 nyx.menu.show_menu()
   File "/usr/local/lib/python3.6/site-packages/nyx/menu.py", line 210, in
 show_menu
 selection_x = _draw_top_menubar(menu, cursor.selection)
   File "/usr/local/lib/python3.6/site-packages/nyx/menu.py", line 296, in
 _draw_top_menubar
 nyx.curses.draw(_render, height = 1, background = RED)
   File "/usr/local/lib/python3.6/site-packages/nyx/curses.py", line 758,
 in draw
 curses_subwindow.bkgd(' ', curses_attr(background, HIGHLIGHT))
   File "/usr/local/lib/python3.6/site-packages/nyx/curses.py", line 440,
 in curses_attr
 encoded |= _color_attr()[override if override else attr]
 KeyError: 'none'
 }}}

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

Re: [tor-bugs] #29203 [Core Tor/Tor]: Add a way to specify machines as reduced circuit padding

[Tor Bug Tracker & Wiki]

#29203: Add a way to specify machines as reduced circuit padding
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:  0.33
Parent ID:  #28634| Points:  4
 Reviewer:  asn   |Sponsor:  Sponsor2
--+
Changes (by asn):

 * status:  needs_review => 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] #28693 [Core Tor/Tor]: Add an option to disable circuit padding

[Tor Bug Tracker & Wiki]

#28693: Add an option to disable circuit padding
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-must  |
Parent ID:  #28634   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * status:  needs_review => 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] #30173 [Core Tor/Tor]: Ensure circuit padding can be safely disabled from consensus

[Tor Bug Tracker & Wiki]

#30173: Ensure circuit padding can be safely disabled from consensus
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Ugh. You are right, the option was already in. I somehow missed it. Sorry
 about that.

 LGTM!

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

Re: [tor-bugs] #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:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:  2
  ipv6, 034-triage-20180328, |
  034-removed-20180328, 040-unreached-20190109,  |
  041-proposed, v3-onion-service-feature-|
  parity-can asn-merge nickm-merge   |
Parent ID:  #23493   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by asn):

 Merged! Cant close until  #27251 is closed.

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

Re: [tor-bugs] #30464 [Applications/Tor Browser]: Update text for safer security level to include WebGL

[Tor Bug Tracker & Wiki]

#30464: Update text for safer security level to include WebGL
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.5-must,|  Actual Points:
  TorBrowserTeam201905R, GeorgKoppen201905   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-8.5-must, TorBrowserTeam201905, GeorgKoppen201905 =>
 tbb-8.5-must, TorBrowserTeam201905R, GeorgKoppen201905


Comment:

 `bug_30464`
 
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_30464=f4836d963fb71af377d6834a6a2bd58663afbac8)
 in my Torbutton repo has the change. It is a bit unfortunate that we need
 to duplicate the strings as we use .properties on desktop and .dtd on
 mobile but maybe that's something we can think about during #10760.

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

Re: [tor-bugs] #30382 [Core Tor/Tor]: Provide control port event for when we are missing v3 client auth for an onion

[Tor Bug Tracker & Wiki]

#30382: Provide control port event for when we are missing v3 client auth for an
onion
+--
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tbb-usability, hs-auth  |  Actual Points:
Parent ID:  #14389  | Points:  6
 Reviewer:  |Sponsor:
|  Sponsor27-must
+--

Comment (by asn):

 ACK. Makes sense.

 While it seems like we are moving towards the SOCKS direction, I should
 mention that comment:52:ticket:14389 also asks for some enhancements to
 our SOCKS handshake. We should probably oen a new ticket for this. Also,
 wrt this ticket, we should consider how to use prop#229 for any additional
 SOCKS error codes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30464 [Applications/Tor Browser]: Update text for safer security level to include WebGL

[Tor Bug Tracker & Wiki]

#30464: Update text for safer security level to include WebGL
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-8.5-must,
 Severity:  Normal   |  TorBrowserTeam201905,
 |  GeorgKoppen201905
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should make it explicit that WebGL is click-to-play on medium level (as
 it had been) already.

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

Re: [tor-bugs] #19722 [Applications/Tor Browser]: Compile tor with selfrando

[Tor Bug Tracker & Wiki]

#19722: Compile tor with selfrando
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-security, tbb-rbm |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  assigned => closed
 * keywords:  tbb-security => tbb-security, tbb-rbm
 * resolution:   => wontfix


Comment:

 We removed selfrando support in bug 30377, thus this is a WONTFIX.

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

Re: [tor-bugs] #23073 [Applications/Tor Browser]: Include selfrando in the Linux stable series

[Tor Bug Tracker & Wiki]

#23073: Include selfrando in the Linux stable series
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+--
Changes (by gk):

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


Comment:

 We removed selfrando support in bug 30377, thus this is a WONTFIX.

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

Re: [tor-bugs] #30027 [Webpages]: lektor portals: Titles should not be capitalized in the CSS (was: tb-manual: Titles should not be capitalized in the CSS)

[Tor Bug Tracker & Wiki]

#30027: lektor portals: Titles should not be capitalized in the CSS
--+--
 Reporter:  emmapeel  |  Owner:  emmapeel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by emmapeel):

 * owner:  phoul => emmapeel
 * status:  new => assigned
 * component:  Community/Tor Browser Manual => Webpages


Comment:

 i make the scope of this ticket bigger, because it also happens in the
 other lektor portals.

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