Re: [tor-bugs] #33067 [Metrics/Consensus Health]: DocTor should also fetch microdesc consensus, plus maybe downplay the vanilla consensus warnings

[Tor Bug Tracker & Wiki]

#33067: DocTor should also fetch microdesc consensus, plus maybe downplay the
vanilla consensus warnings
--+-
 Reporter:  arma  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by gk):

 Replying to [comment:2 arma]:
 > cc'ing geko too, because somebody needs to change the email side of
 consensus-health (I think that's DocTor, and Tom's side is DepicTor), and
 I hear GeKo became the new DocTor maintainer when he tried to talk Damian
 out of moving it to Github. :)

 Well, yes. I think, though, I can't do anything in that regard until
 #33022 is resolved. So, it feels to me if you want to see changes before
 that pinging atagar is still not an unreasonable option.

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

Re: [tor-bugs] #33067 [Metrics/Consensus Health]: DocTor should also fetch microdesc consensus, plus maybe downplay the vanilla consensus warnings

[Tor Bug Tracker & Wiki]

#33067: DocTor should also fetch microdesc consensus, plus maybe downplay the
vanilla consensus warnings
--+-
 Reporter:  arma  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arma):

 * cc: gk (added)


Comment:

 cc'ing geko too, because somebody needs to change the email side of
 consensus-health (I think that's DocTor, and Tom's side is DepicTor), and
 I hear GeKo became the new DocTor maintainer when he tried to talk Damian
 out of moving it to Github. :)

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

Re: [tor-bugs] #33109 [Webpages/Blog]: Make (and then use) a blog account policy

[Tor Bug Tracker & Wiki]

#33109: Make (and then use) a blog account policy
---+--
 Reporter:  arma   |  Owner:  ggus
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Gus, I'm letting you lead this one if you want. :) Let me know if that's a
 poor idea and I should drive it.

 I'm hoping the policy will be uncontroversial, since we're just trying to
 capture what we're doing now.

 Three next steps:

 (A) Think about who else are the main blog constituents, to make sure we
 check with them to see if they have any improvements or clarifications to
 make. Maybe checking with Steph is enough, and we're all set there, and
 the next step is to show the rest of the community the draft proposal
 (e.g. with a mail to tor-project@) and give them a timeframe for comments
 / fixes / suggestions and then we're done?

 (B) Figure out where to post this policy. We could put it on trac,
 alongside the comment moderation policy. But ultimately we want space on
 an actual official Tor website for this policy, plus probably for the
 comment moderation one too.

 (C) Figure out how best to "disable" an account. Some blog accounts are
 disabled currently by removing the Blogger capability from them. Others
 are disabled by taking away the 'active' flag. Maybe we even deleted some
 others. We should get some consistency on what we do to disable an account
 -- I bet hiro would have a good opinion there.

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

Re: [tor-bugs] #31565 [Core Tor/Tor]: static Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSL

[Tor Bug Tracker & Wiki]

#31565: static Tor building against openssl-1.1.1 fails: configure unable to 
find
linkable OpenSSL
+--
 Reporter:  shredder|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor,openssl,1.1.1,static,mingw  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * cc: boklm (added)


Comment:

 I'm told by somebody on irc today that openssl 1.0.2 is now unsupported.
 So the folks trying to maintain "static Tor binary on Windows" build
 scripts, such as
 https://gitlab.com/euphrosyne/tor-mingw/blob/master/guide
 are now out of options.

 I wonder how rbm solves this one; I'm cc'ing boklm to find out. Maybe it's
 simply by not making it that static.

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

Re: [tor-bugs] #33124 [Core Tor/Tor]: Controller circuits don't pass the SOCKS request address in relay begin cells

[Tor Bug Tracker & Wiki]

#33124: Controller circuits don't pass the SOCKS request address in relay begin
cells
--+
 Reporter:  opara |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Thanks opara. I agree this is a bug and we should fix it.

 I'll let the network team folks pick the milestone -- 0.4.3 or 0.4.4 make
 sense, in that yes it's a bug but it sure isn't a regression against
 anything recent. :)

 After some spelunking, I believe commit 329af979 (Tor version 0.1.1.15-rc)
 is arguably where the bug came in -- since that's where
 CIRCUIT_PURPOSE_CONTROLLER came to be.

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

Re: [tor-bugs] #33024 [Core Tor/Tor]: can not connect to TOR please help

[Tor Bug Tracker & Wiki]

#33024: can not connect to TOR please help
-+---
 Reporter:  brottousn@…  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Immediate|  Milestone:
Component:  Core Tor/Tor |Version:  Tor: unspecified
 Severity:  Critical | Resolution:
 Keywords:  can not connect  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by 8kjetgsmt):

 hi
 i have the same problem
 windows 10
 firewall off
 antivirus off

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

[tor-bugs] #33124 [Core Tor/Tor]: Controller circuits don't pass the SOCKS request address in relay begin cells

[Tor Bug Tracker & Wiki]

#33124: Controller circuits don't pass the SOCKS request address in relay begin
cells
+--
 Reporter:  opara   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 If a stream is attached to a circuit with purpose
 {{{CIRCUIT_PURPOSE_CONTROLLER}}}, a RELAY_BEGIN cell will be sent with an
 empty address. This is because of a bug in
 {{{connection_ap_handshake_send_begin()}}}.

 {{{
 tor_snprintf(payload,RELAY_PAYLOAD_SIZE, "%s:%d",
  (circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL) ?
ap_conn->socks_request->address : "",
  ap_conn->socks_request->port);
 }}}

 The function seems to assume that if it's not a general purpose circuit,
 then it is a rendezvous circuit. This was added in
 [https://github.com/torproject/tor/commit/5b6099e8#diff-
 0798d3d17392dc5c15f3f58a5fc6b29aR946-R957 commit 5b6099e8].

 There is a similar error in a logging statement in
 {{{link_apconn_to_circ()}}} which logs that a controller circuit is to a
 "hidden service", even if the circuit is actually to an exit.

 {{{
 log_info(LD_APP, "Looks like completed circuit to %s %s allow "
  "optimistic data for connection to %s",
  circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL ?
/* node_describe() does the right thing if exitnode is NULL */
safe_str_client(node_describe(exitnode)) :
"hidden service",
  apconn->may_use_optimistic_data ? "does" : "doesn't",
  safe_str_client(apconn->socks_request->address));
 }}}

 And another example is in {{{connection_ap_expire_beginning()}}} which
 logs the warning:

 {{{
 [warn] connection_ap_expire_beginning(): Bug: circuit->purpose ==
 CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was Circuit
 made by controller; it was in state open, path_state new. (on Tor 0.4.2.5
 )
 }}}

 The relay which receives the RELAY_BEGIN cell will then make a dns request
 for the address "". Libevent will eventually give up after 3 tries
 ({{{global_timeout.tv_sec = 5}}} seconds per try).

 {{{
 Feb 01 01:11:41.369 [info] launch_resolve(): Launching eventdns request
 for ""
 Feb 01 01:11:41.369 [info] evdns_log_cb(): eventdns: Resolve requested.
 ...
 Feb 01 01:11:56.378 [info] eventdns: Giving up on request 0x5565c825ac80;
 tx_count==3
 }}}

 Back at the tor client, the streams detach (reason=timeout,
 remote_reason=none) after some time, then the controller circuits close a
 few seconds later (a total of 25 seconds after the streams were first
 attached) with:

 {{{
 [info] circuit_mark_for_close_(): Circuit 226273 (id: 15) marked for
 close at src/core/or/circuituse.c:1507 (orig reason: 9, new reason: 0)
 }}}

 Finally a SOCKS error code {{{0x5b}}} is returned to the application after
 some long amount of time.

 In summary, the main problems are:

 (1) Tor has checks for only {{{CIRCUIT_PURPOSE_C_GENERAL}}} when it should
 be checking for other circuit purposes like
 {{{CIRCUIT_PURPOSE_CONTROLLER}}}.
 (2) Tor attempts to resolve the address of an empty string.
 (3) (Maybe?) It takes a long time before the application is notified that
 the SOCKS connection was unsuccessful.

 Thanks to arma for help debugging this.

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

Re: [tor-bugs] #33123 [Applications/GetTor]: Update GetTor's rate limiting

[Tor Bug Tracker & Wiki]

#33123: Update GetTor's rate limiting
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Here's a commit that does what I described above:
 
https://dip.torproject.org/cohosh/gettor/commit/e36587122d5cd813e1693ab2640baf1c25298d56

 I noticed we don't have any database-related tests. I'm going to try to
 put some together as a part of this ticket.

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

Re: [tor-bugs] #33123 [Applications/GetTor]: Update GetTor's rate limiting

[Tor Bug Tracker & Wiki]

#33123: Update GetTor's rate limiting
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

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


Comment:

 Okay, it seems like this was originally intended to be an actual rate
 limit, where the function `get_num_requests` was supposed to pull from the
 database requests that were in progress from the same email address. The
 way it's implemented now, requests are not removed from the table when
 they are completed. Instead, the status is updated from `ONHOLD` to
 `SENT`.

 There's no reason to keep these entries around, especially since we have a
 separate table for statistics. I also don't feel good about keeping
 records of individual requests, even if the email addresses are hashed.
 Emails draw from a low entropy tool and subsequent requests from the same
 account are linkable.

 I '''think''' just deleting requests once they are handled will fix this.

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

Re: [tor-bugs] #19026 [Circumvention/Snowflake]: Remove local LAN address ICE candidates

[Tor Bug Tracker & Wiki]

#19026: Remove local LAN address ICE candidates
-+--
 Reporter:  dcf  |  Owner:  arlolra
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arlolra):

 * status:  assigned => needs_review


Comment:

 Here's an attempt at this,
 
https://github.com/keroserene/snowflake/commit/71934f1db34bec354a94266c79f2e631be604a03

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

Re: [tor-bugs] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can extra-review  |
Parent ID:  #4310| Points:  0.5
 Reviewer:  teor, catalyst   |Sponsor:
-+-
Changes (by catalyst):

 * keywords:  documentation tor-client manpage easy 043-can => documentation
 tor-client manpage easy 043-can extra-review


Comment:

 Thanks!

 It mostly looks good.  I think it's better to have a title like "Circuit
 timeout options".  (I think we don't currently have any timeout options
 other than circuit timeout options, but we might in the future.)

 I'll try to comment more after the weekend.

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

Re: [tor-bugs] #32929 [Core Tor/Tor]: Tor Manual: Split Node options into their own subsection

[Tor Bug Tracker & Wiki]

#32929: Tor Manual: Split Node options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can extra-review  |
Parent ID:  #4310| Points:  0.5
 Reviewer:  catalyst, teor   |Sponsor:
-+-
Changes (by catalyst):

 * keywords:  documentation tor-client manpage easy 043-can => documentation
 tor-client manpage easy 043-can extra-review


Comment:

 Thanks!

 It mostly looks good to me.  I think "Node selection options" might be a
 better section title, because they restrict the nodes a tor client (or
 onion service) can use while building a circuit.  There should also
 probably be introductory text explaining that these options can weaken
 your anonymity by making your client behavior different from other Tor
 clients.

 I'll try to comment more after the weekend.

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

Re: [tor-bugs] #31872 [Circumvention]: Write up process for distribution of private bridges

[Tor Bug Tracker & Wiki]

#31872: Write up process for distribution of private bridges
---+
 Reporter:  phw|  Owner:  phw
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  s30-o23a1  |  Actual Points:
Parent ID:  #31280 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+
Changes (by phw):

 * status:  assigned => needs_revision


Comment:

 Replying to [comment:3 cohosh]:
 > Cool, this page looks good. Just a few comments:
 [[br]]
 Thanks, these are good points. I'll address your feedback soon.

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

Re: [tor-bugs] #31872 [Circumvention]: Write up process for distribution of private bridges

[Tor Bug Tracker & Wiki]

#31872: Write up process for distribution of private bridges
---+---
 Reporter:  phw|  Owner:  phw
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  s30-o23a1  |  Actual Points:
Parent ID:  #31280 | Points:  1
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by phw):

 * owner:  (none) => phw
 * status:  needs_review => assigned


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

Re: [tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  10
 Reviewer: |Sponsor:
---+--

Comment (by anarcat):

 is it part of the spec here to allow users unfamiliar with git to edit the
 website? i'm wondering if we've given any thought to which tools could be
 used for that purpose...

 i wonder if tools like this could be useful for us:

 https://gohugo.io/tools/frontends/

 those are hugo frontends, but they could easily apply to lektor as
 well

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

Re: [tor-bugs] #21314 [Circumvention/Snowflake]: snowflake-client needs to stop using my network when I'm not giving it requests

[Tor Bug Tracker & Wiki]

#21314: snowflake-client needs to stop using my network when I'm not giving it
requests
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, ex-sponsor19, anti-  |  Actual Points:
  censorship-roadmap |
Parent ID:  #21967   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 I think the way to do this is to restructure the code so that the broker-
 polling loop (which keeps the client replenished with fresh proxies)
 happens inside the SOCKS handler, not outside.

 That is, currently the code works like this, with the broker-polling loop
 being global and independent of any SOCKS connection:
 {{{
 func main() {
 snowflakes := sf.NewPeers() // etc.
 go ConnectLoop(snowflakes) // start the background broker-polling loop

 for conn in ln.AcceptSocks() {
 // pass a handle to the snowflake collector to the handler
 function
 go Handler(conn, snowflakes)
 }

 snowflakes.End()
 }

 func Handler(socks net.Conn, snowflakes SnowflakeCollector) {
 snowflake := snowflakes.Pop()
 copyLoop(socks, snowflake)
 }
 }}}

 Instead, it should start a new browser-polling loop specific to each SOCKS
 connection (tor usually has 0 or 1 of these open at a time):
 {{{
 func main() {
 for conn in ln.AcceptSocks() {
 go Handler(conn)
 }
 }

 func Handler(socks net.Conn, snowflakes SnowflakeCollector) {
 snowflakes := sf.NewPeers() // etc.
 go ConnectLoop(snowflakes) // start the background broker-polling loop

 snowflake := snowflakes.Pop()
 copyLoop(socks, snowflake)

 snowflakes.End()
 }
 }}}

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

Re: [tor-bugs] #32929 [Core Tor/Tor]: Tor Manual: Split Node options into their own subsection

[Tor Bug Tracker & Wiki]

#32929: Tor Manual: Split Node options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can   |
Parent ID:  #4310| Points:  0.5
 Reviewer:  catalyst, teor   |Sponsor:
-+-

Comment (by swati):

 Added a new section called Advanced Options for grouping all the *Node
 related options. See PR - ​https://github.com/torproject/tor/pull/1702

 Currently, there are 9 options in this section.

 Some questions:
  - Is **Advanced Options** an appropriate title for this category?
  - Does the NodeFamily option belong to this section?

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

Re: [tor-bugs] #32929 [Core Tor/Tor]: Tor Manual: Split Node options into their own subsection

[Tor Bug Tracker & Wiki]

#32929: Tor Manual: Split Node options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can   |
Parent ID:  #4310| Points:  0.5
 Reviewer:  catalyst, teor   |Sponsor:
-+-
Changes (by swati):

 * status:  new => needs_review
 * reviewer:   => catalyst, teor


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

Re: [tor-bugs] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can   |
Parent ID:  #4310| Points:  0.5
 Reviewer:  teor, catalyst   |Sponsor:
-+-
Changes (by swati):

 * reviewer:   => teor, catalyst


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

Re: [tor-bugs] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can   |
Parent ID:  #4310| Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by swati):

 * status:  new => needs_review


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

Re: [tor-bugs] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can   |
Parent ID:  #4310| Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by swati):

 Added a new section called Timeout Options. See PR -
 https://github.com/torproject/tor/pull/1702
 Currently, there are 7 options in this section.

 Some questions:

  - Is the **Timeout Options** an appropriate title for this category?

  - Do the following options also belong to the Timeout Options category?
 MaxCircuitDirtiness
 MaxClientCircuitsPending
 CircuitPadding
 ReducedCircuitPadding
 NewCircuitPeriod
 PathsNeededToBuildCircuits

 If yes, I will have to add these two.

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

Re: [tor-bugs] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:  phw  |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Merged!
 
https://gitweb.torproject.org/gettor.git/commit/?id=3dfc2fdbaa3f8467d8c49977b08256f12149daf4

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

Re: [tor-bugs] #32645 [Applications/Tor Browser]: Update URL bar onion indicators

[Tor Bug Tracker & Wiki]

#32645: Update URL bar onion indicators
+--
 Reporter:  antonela|  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam202001R  |  Actual Points:
Parent ID:  #30025  | Points:
 Reviewer:  |Sponsor:
|  Sponsor27-must
+--
Changes (by boklm):

 * keywords:  ux-team, TorBrowserTeam20200131 => ux-team,
 TorBrowserTeam202001R


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

Re: [tor-bugs] #33122 [Applications/GetTor]: GetTor should provide download links even if email request is invalid

[Tor Bug Tracker & Wiki]

#33122: GetTor should provide download links even if email request is invalid
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by phw):

 Cecylia mentioned that GetTor should already be doing this. The real issue
 here may be #33123: GetTor may have banned my email address because it has
 already seen 30 requests from it.

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

Re: [tor-bugs] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:  phw  |Sponsor:
-+-
Changes (by phw):

 * status:  needs_review => merge_ready


Comment:

 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] #24607 [Circumvention/BridgeDB]: CAPTCHAs on BridgeDB seem to be getting more difficult

[Tor Bug Tracker & Wiki]

#24607: CAPTCHAs on BridgeDB seem to be getting more difficult
-+-
 Reporter:  alison   |  Owner:  phw
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-november,|  Actual Points:
  s30-o22a2  |
Parent ID:  #31279   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-
Changes (by phw):

 * owner:  (none) => phw


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

Re: [tor-bugs] #24607 [Circumvention/BridgeDB]: CAPTCHAs on BridgeDB seem to be getting more difficult

[Tor Bug Tracker & Wiki]

#24607: CAPTCHAs on BridgeDB seem to be getting more difficult
-+-
 Reporter:  alison   |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-november,|  Actual Points:
  s30-o22a2  |
Parent ID:  #31279   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by phw):

 I took a look at our recent BridgeDB metrics to get an idea of how our new
 CAPTCHAs affected users and bots. Here's what we believe are bot requests
 for vanilla bridges over HTTPS (i.e., `https.vanilla.zz`):

 ||= Date =||= # success =||= # failed =||= # total =||= Success rate =||
 || 2020-01-28 || 4,060|| 640|| 4,700|| 86%||
 || 2020-01-29 || 3,700|| 1,120|| 4,820|| 77%||
 || 2020-01-30 || 510|| 4,550|| 5,060|| 10%||

 And here's what we believe are user requests from the U.S. for vanilla
 bridges over HTTPS (i.e., `https.vanilla.us`):

 ||= Date =||= # success =||= # failed =||= # total =||= Success rate =||
 || 2020-01-28 || 170|| 160|| 330|| 52%||
 || 2020-01-29 || 280|| 290|| 570|| 49%||
 || 2020-01-30 || 300|| 70|| 370|| 81%||

 Recall that we deployed new CAPTCHAs on January 29. This is when the
 success rate of bots began to decline, and the success rate of users began
 to increase. I expect the bots to improve over time but we managed to
 increase the success rate of users, which is what matters most. (Granted,
 I'm only looking at requests from the U.S. because we see most requests
 from this region. Other regions that don't have native English speakers
 may not be doing as well.)

 Here's the number of moat requests over time (i.e., `moat.obfs4.??`). Note
 that we don't know the proportion of user and bot requests comprising all
 moat requests:

 ||= Date =||= # success =||= # failed =||= # total =||= Success rate =||
 || 2020-01-28 || 3,780|| 2,780|| 6,560|| 58%||
 || 2020-01-29 || 3,800|| 2,830|| 6,630|| 57%||
 || 2020-01-30 || 3,910|| 590|| 4,500|| 87%||

 I find it surprising that the number of failed requests decreased on Jan
 30 but the number of successful requests didn't increase. This may be a
 bug in the metrics collection. Another possibility is that bots requested
 CAPTCHAs, were not sufficiently confident in their classification, and
 subsequently didn't send a POST request with their solution to 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

[tor-bugs] #33123 [Applications/GetTor]: Update GetTor's rate limiting

[Tor Bug Tracker & Wiki]

#33123: Update GetTor's rate limiting
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:  2|   Reviewer:
  Sponsor:   |
-+
 Right now GetTor has a limit for the number of total requests a user can
 make from a single email address. This was likely put in place to prevent
 abuse or resource consumption, but functions as a total limit rather than
 a rate limit.

 This does not seem desirable, the limit right now is pretty low (30
 requests), and is essentially a lifetime limit since we don't clear the
 database when we update links.

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

Re: [tor-bugs] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:  phw  |Sponsor:
-+--

Comment (by cohosh):

 Ah just saw the help body text. We should update it:
 
https://dip.torproject.org/cohosh/gettor/commit/3dfc2fdbaa3f8467d8c49977b08256f12149daf4

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

Re: [tor-bugs] #32915 [- Select a component]: Some Tor exit node servers are using Cloudflare DNS, result in "DNS resolution error"

[Tor Bug Tracker & Wiki]

#32915: Some Tor exit node servers are using Cloudflare DNS, result in "DNS
resolution error"
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:5 cypherpunks]:
 > Please enable cookies.
 > Error 1001 Ray ID: 5535dad91ec26e3c • 2020-01-11 xx:xx:xx UTC
 > DNS resolution error
 > What happened?
 >
 > You've requested a page on a website (spreadprivacy.com) that is on the
 Cloudflare network. Cloudflare is currently unable to resolve your
 requested domain (spreadprivacy.com). There are two potential causes of
 this:
 >
 > Most likely: if the owner just signed up for Cloudflare it can take
 a few minutes for the website's information to be distributed to our
 global network.
 > Less likely: something is wrong with this site's configuration.
 Usually this happens when accounts have been signed up with a partner
 organization (e.g., a hosting provider) and the provider's DNS fails.
 >
 > Cloudflare Ray ID: 5535dad91ec26e3c • Your IP:
 2405:8100:8000:5ca1::493:8b61 • Performance & security by Cloudflare


 None of the reported IP´s seem to be exitting! Are you sure you are using
 tor?
 i have looked into
 http://rougmnvswfsmd4dq.onion/rs.html#search/flag:exit%20
 sorted by IPv6. But there exist no exit with IPv6 prefix 2405:

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33122 [Applications/GetTor]: GetTor should provide download links even if email request is invalid

[Tor Bug Tracker & Wiki]

#33122: GetTor should provide download links even if email request is invalid
-+
 Reporter:  phw  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 GetTor only responds to you if you send a correctly-formatted email. My
 guess is that many users fail at this, at least on their first attempt.
 (Do we have GetTor metrics do back this up?)

 Why not make GetTor more usable by making it respond even to invalid
 requests? This response could include download links (e.g., for en-US
 bundles for Windows, Linux, and MacOS), and a note saying something along
 the lines of "if this isn't the language you wanted, write FOO in the
 message body".

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

Re: [tor-bugs] #4806 [Core Tor/Tor]: Detect and warn when running IPv6-using client without IPv6 address privacy

[Tor Bug Tracker & Wiki]

#4806: Detect and warn when running IPv6-using client without IPv6 address 
privacy
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-client, nickm-patch,   |  Actual Points:
  intro, privacy |
Parent ID:  #5940| Points:  medium
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:39 teor]:
 > We might end up using parts of this patch to *avoid* IPv6 address
 privacy on relays.
 but might it would benefit for exit relays exitting traffic? could result
 in less punishment, less captchas for tor users.
  expect the IPv6 orport

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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by opara):

 Above I added some patches for how I did this a few months ago. I'm not
 proposing to use them on tor as I didn't test them thoroughly, but they
 might be helpful to look at when you or someone else in the future decides
 to fix this. The first patch isn't necessary for this bug, but makes some
 changes to the thread pool that might affect the other two patches.

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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by opara):

 * Attachment "0003-Added-the-ability-to-shutdown-the-threadpool.patch"
 added.


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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by opara):

 * Attachment "0001-Uncoupled-the-thread-pool-from-the-reply-queue.patch"
 added.


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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by opara):

 * Attachment "0002-Changed-threads-to-be-joinable-rather-than-
 detatched.patch" added.


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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 It looks like the reason that the cleanup functions don't currently run is
 that the thread pool itself is not shut down anywhere on shutdown, so the
 threads are not told to exit.  This is not yet a problem for embedded
 users, since they are mostly clients and clients don't yet use threads,
 but it's something we should fix.

 I'll see how hard the fix is.

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

Re: [tor-bugs] #33121 [Core Tor/sbws]: Deploy sbws in the rest of bwauths (was: Help the remaining bwauths to deploy sbws)

[Tor Bug Tracker & Wiki]

#33121: Deploy sbws in the rest of bwauths
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords:  sbws-roadmap   |  Actual Points:
Parent ID: | Points:  2
 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #30727, #30733, #30735, #30067, ...

[Tor Bug Tracker & Wiki]

Batch modification to #30727, #30733, #30735, #30067, #30196, #30719, #30726, 
#33033, #29728, #33009, #33076, #33077 by gaba:
parent to #33121

Comment:
The goal is to deploy sbws in all bw authorities. We need to fix critical bugs 
to do this.

--
Tickets URL: 

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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Hm.  I'd rather retain the option to have both ways to exit a thread,
 since we're likely to do more thread stuff in the future.

 I'll add a comment about setting thread_cleanup_fn before starting any
 threads.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33121 [Core Tor/sbws]: Help the remaining bwauths to deploy sbws

[Tor Bug Tracker & Wiki]

#33121: Help the remaining bwauths to deploy sbws
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal |   Keywords:  sbws-roadmap
Actual Points: |  Parent ID:
   Points:  2  |   Reviewer:
  Sponsor: |
---+---
 When we're ready to deploy sbws in all the remaining bwauths (3/6), send
 an email to the dirauths to start the transition process.

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

Re: [tor-bugs] #32103 [Core Tor/Tor]: Subsystem "thread_cleanup" is never called

[Tor Bug Tracker & Wiki]

#32103: Subsystem "thread_cleanup" is never called
--+
 Reporter:  opara |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should, extra-review  |  Actual Points:  .2
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * reviewer:  nickm =>


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

Re: [tor-bugs] #33077 [Metrics/Analysis]: Graph results from the sbws to torflow transition

[Tor Bug Tracker & Wiki]

#33077: Graph results from the sbws to torflow transition
-+-
 Reporter:  mikeperry|  Owner:
 |  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Analysis |Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-roadmap metrics-team-roadmap-   |  Actual Points:
  2020Q1 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * keywords:  sbws-roadmap => sbws-roadmap metrics-team-roadmap-2020Q1


Comment:

 This one is needed for sbws deployment.

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

Re: [tor-bugs] #33076 [Metrics/Analysis]: Graph onionperf and consensus information from Rob's experiments

[Tor Bug Tracker & Wiki]

#33076: Graph onionperf and consensus information from Rob's experiments
-+-
 Reporter:  mikeperry|  Owner:
 |  metrics-team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Analysis |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1, sbws-   |  Actual Points:
  roadmap|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * keywords:  metrics-team-roadmap-2020Q1 => metrics-team-roadmap-2020Q1,
 sbws-roadmap


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

Re: [tor-bugs] #33098 [Internal Services/Tor Sysadmin Team]: fsn-node-03 disk problems

[Tor Bug Tracker & Wiki]

#33098: fsn-node-03 disk problems
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Blocker  | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  assigned => merge_ready


Comment:

 resync seems to be going fine, i'll do one last reboot in about an hour
 and then we're clear here.

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

Re: [tor-bugs] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:  phw  |Sponsor:
-+--
Changes (by cohosh):

 * status:  merge_ready => 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] #33002 [Applications/GetTor]: Localized binaries not working for some locales

[Tor Bug Tracker & Wiki]

#33002: Localized binaries not working for some locales
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:  phw  |Sponsor:
-+-

Comment (by cohosh):

 Thanks! I forgot a commit to update sendmail. It's deployed as a hotfix
 now but isn't merged to master:
 
https://dip.torproject.org/cohosh/gettor/commit/56399f5a71f7ebc642ab5ba9526f4da716a83771

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33120 [Core Tor/Tor]: Resolve TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33120: Resolve TROVE-2020-002
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  043-must
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

[tor-bugs] #33119 [Core Tor/Tor]: Resolve TROVE-2020-001

[Tor Bug Tracker & Wiki]

#33119: Resolve TROVE-2020-001
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  043-must
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #29728 [Core Tor/sbws]: Deprecate torflow

[Tor Bug Tracker & Wiki]

#29728: Deprecate torflow
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords:  sbws-roadmap   |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by gaba):

 * keywords:   => sbws-roadmap


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

Re: [tor-bugs] #30727 [Core Tor/sbws]: Make sbws vote for all measured relays, even if they are not Running / not in the consensus

[Tor Bug Tracker & Wiki]

#30727: Make sbws vote for all measured relays, even if they are not Running / 
not
in the consensus
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker, sbws-roadmap |
Parent ID:  #29710   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Looks good!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33118 [Core Tor/Tor]: Investigate clusterfuzz timeouts

[Tor Bug Tracker & Wiki]

#33118: Investigate clusterfuzz timeouts
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  clusterfuzz 043-should
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Clusterfuzz has found some test cases which in its opinion take too much
 time or memory.  I don't see how this is possible, since they each
 complete within a second on my desktop, but we should aim for better
 performance than that, and we should try to eliminate even our false
 positives.

 And who knows, maybe there's a real bug here?

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

Re: [tor-bugs] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+

Comment (by nickm):

 > Comments on the `.clang-format` file:

 Thank you!  I am not attached to IndentCaseLabels or SpaceAfterLogicalNot,
 though I think others may feel more strongly, and we should probably do a
 quick straw poll.

 I can probably hack something together with `codetool.py` to replace the
 output of AlignEscapedNewlines with something closer to what emacs does;
 do you think that would be worthwhile?

 I would like to keep `KeepEmptyLinesAtTheStartOfBlocks: false` if we can.

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

Re: [tor-bugs] #33114 [Applications/Orbot]: Crash after update to 16.1.4-BETA-1-tor-0.4.2.5-rc (from f-droid)

[Tor Bug Tracker & Wiki]

#33114: Crash after update to 16.1.4-BETA-1-tor-0.4.2.5-rc (from f-droid)
---+--
 Reporter:  user45738  |  Owner:  n8fr8
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Orbot |Version:  Tor: 0.4.2.5
 Severity:  Major  | Resolution:
 Keywords:  orbot, crash, android, update  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by n8fr8):

 Please downgrade so you can use the previous version.

 Lineage 16.0 has known issues with Tor and VPN mode that we are actively
 debugging.

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

Re: [tor-bugs] #33116 [Internal Services/Tor Sysadmin Team]: irc bouncer account

[Tor Bug Tracker & Wiki]

#33116: irc bouncer account
-+-
 Reporter:  pospeselr|  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 pastly is responsible for the IRC bouncer currently deployed on chives,
 from what i undesrstand... it's not clear to me how to ask for an account,
 but please direct your request to pastly instead of TPA. see also #32532.

 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] #25204 [Applications/Tor Browser]: Switch security.insecure_connection_* prefs to warn users about insecure HTTP in FF60-esr

[Tor Bug Tracker & Wiki]

#25204: Switch security.insecure_connection_* prefs to warn users about insecure
HTTP in FF60-esr
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, ux-team |  Actual Points:
Parent ID:  #30025| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * parent:  #30037 => #30025


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

Re: [tor-bugs] #27476 [Applications/Tor Browser]: Remove gap between Tor Launcher window and main browser window

[Tor Bug Tracker & Wiki]

#27476: Remove gap between Tor Launcher window and main browser window
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-launcher tbb-performance ux- |  Actual Points:
  team   |
Parent ID:  #31283   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * parent:   => #31283


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

Re: [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:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  AffectsTails, ux-team  |  Actual Points:
Parent ID:  #31283 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by antonela):

 * parent:   => #31283


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

Re: [tor-bugs] #33117 [- Select a component]: Tor Launcher Issues

[Tor Bug Tracker & Wiki]

#33117: Tor Launcher Issues
--+---
 Reporter:  antonela  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:  #31283| Points:
 Reviewer:|Sponsor:  Sponsor30
--+---
Changes (by antonela):

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


Comment:

 Issues are going directly under #31283 - closing this ticket.

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

Re: [tor-bugs] #24452 [Applications/Tor Launcher]: Firewall option is visible behind Tor Network Settings... but not during start-up

[Tor Bug Tracker & Wiki]

#24452: Firewall option is visible behind Tor Network Settings... but not during
start-up
---+---
 Reporter:  gk |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #31283 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by antonela):

 * parent:  #33117 => #31283


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

Re: [tor-bugs] #30540 [Applications/Tor Browser]: Give TBA alpha users a link to stable

[Tor Bug Tracker & Wiki]

#30540: Give TBA alpha users a link to stable
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Is this done? will we have the same issue at the next release?

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

Re: [tor-bugs] #32459 [Applications/Tor Launcher]: Enhance TBB GUI Torrc

[Tor Bug Tracker & Wiki]

#32459: Enhance TBB GUI Torrc
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  enhancement| Status:  new
 Priority:  Low|  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by antonela):

 * parent:  #32572 =>


Comment:

 unparenting. Is not related and parent was implemented.

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

Re: [tor-bugs] #32572 [Applications/Tor Browser]: Expose Tor advanced settings in about:preferences#tor

[Tor Bug Tracker & Wiki]

#32572: Expose Tor advanced settings in about:preferences#tor
--+-
 Reporter:  antonela  |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by antonela):

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


Comment:

 Deployed in #31286. Great work pospeslr!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33117 [- Select a component]: Tor Launcher Issues

[Tor Bug Tracker & Wiki]

#33117: Tor Launcher Issues
--+
 Reporter:  antonela  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #31283
   Points:|   Reviewer:
  Sponsor:  Sponsor30 |
--+
 Parent ticket for known tor-launcher issues which apply into s30 scope

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

Re: [tor-bugs] #24452 [Applications/Tor Launcher]: Firewall option is visible behind Tor Network Settings... but not during start-up

[Tor Bug Tracker & Wiki]

#24452: Firewall option is visible behind Tor Network Settings... but not during
start-up
---+---
 Reporter:  gk |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #33117 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by antonela):

 * parent:   => #33117


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

Re: [tor-bugs] #32645 [Applications/Tor Browser]: Update URL bar onion indicators

[Tor Bug Tracker & Wiki]

#32645: Update URL bar onion indicators
-+-
 Reporter:  antonela |  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam20200131  |  Actual Points:
Parent ID:  #30025   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by pospeselr):

 * keywords:  ux-team => ux-team, TorBrowserTeam20200131
 * status:  new => needs_review


Comment:

 Implemented this as a fixup! commit to the original onion icon ticket (
 #23247 ).

 tor-browser: https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_32645_v1

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

Re: [tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  10
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * cc: tpa-roadmap-march (added)
 * points:   => 10


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

Re: [tor-bugs] #33116 [Internal Services/Tor Sysadmin Team]: irc bouncer account

[Tor Bug Tracker & Wiki]

#33116: irc bouncer account
-+-
 Reporter:  pospeselr|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by pospeselr:

Old description:

> Hey I'd like access to the irc bouncer please. LDAP account username is
> {{{pospeselr}}}

New description:

 Hey I'd like access to the irc bouncer please. LDAP account username is
 {{{richard}}}

--

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

Re: [tor-bugs] #33020 [Internal Services/Service - git]: Create new git repo for pospeselr

[Tor Bug Tracker & Wiki]

#33020: Create new git repo for pospeselr
-+
 Reporter:  pospeselr|  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by hiro):

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


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

Re: [tor-bugs] #30727 [Core Tor/sbws]: Make sbws vote for all measured relays, even if they are not Running / not in the consensus

[Tor Bug Tracker & Wiki]

#30727: Make sbws vote for all measured relays, even if they are not Running / 
not
in the consensus
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker, sbws-roadmap |
Parent ID:  #29710   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 Thanks, i think i addressed what you commented.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33116 [Internal Services/Tor Sysadmin Team]: irc bouncer account

[Tor Bug Tracker & Wiki]

#33116: irc bouncer account
-+-
 Reporter:  pospeselr|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hey I'd like access to the irc bouncer please. LDAP account username is
 {{{pospeselr}}}

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

Re: [tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * parent:  #33105 =>


Old description:

> We have been having issues with the blog for a long time. The template we
> are using was developed for another purpose and never really finished.
> We also spend a lot of money on Drupal that could rather be spent
> somewhere else.
>
> I propose to migrate the blog to a static website with lektor and have
> comments running from discourse.org. I have actually been in contact with
> discourse and they have offered to run a forum for us for free
> (). Addittionally they would run an .onion and a torproject.org
> subdomain.
>
> Moderation on discourse is much easier than on drupal comments (another
> pain point for the blog), and we would get a forum that we could use for
> other purposes too.
>
> This is how the blog can be migrated.
>
>  - We will do mockups and approve them with all the parties involved.
>  - We will start migrating content and have it on staging for testing.
>  - Once we are happy we will archive the current blog into static pages
> and move the static bloc to blog.torproject.org.
>
> What we will lose:
>  - Version history on posts.
>  - Old comments. I see no value in migrating old blog comments to
> discourse to be honest. It would be a lot of effort and the old comments
> will be archived anyways in the blog archive.
>
> What we will gain:
>  - Once the blog has been migrated creating posts will be no different
> than editing anyone of our websites. It would actually be a bit easier
> since there are a few different template and pages in our website and the
> blog will just have posts.
>  - Anyone that is currently updating the websites will be able to help
> people with blog posts, therefore we will gain a lot more of blog admins.
>  - The blog will run from our static www rotation, so we will not have to
> run expensive services or 2 cache VMs in front of it to avoid paing a lot
> to a third party for page views.
>  - We will not have to update a service every now and again. The blog
> will run out of static HTML.
>  - We will be able to update the templates according to our styleguide.
>  - Functionalities that we will build won't break because of a drupal
> update.

New description:

 We have been having issues with the blog for a long time. The template we
 are using was developed for another purpose and never really finished.
 We also spend a lot of money on Drupal that could rather be spent
 somewhere else.

 I propose to migrate the blog to a static website with lektor and have
 comments running from discourse.org. I have actually been in contact with
 discourse and they have offered to run a forum for us for free (#33105).
 Addittionally they would run an .onion and a torproject.org subdomain.

 Moderation on discourse is much easier than on drupal comments (another
 pain point for the blog), and we would get a forum that we could use for
 other purposes too.

 This is how the blog can be migrated.

  - We will do mockups and approve them with all the parties involved.
  - We will start migrating content and have it on staging for testing.
  - Once we are happy we will archive the current blog into static pages
 and move the static bloc to blog.torproject.org.

 What we will lose:
  - Version history on posts.
  - Old comments. I see no value in migrating old blog comments to
 discourse to be honest. It would be a lot of effort and the old comments
 will be archived anyways in the blog archive.

 What we will gain:
  - Once the blog has been migrated creating posts will be no different
 than editing anyone of our websites. It would actually be a bit easier
 since there are a few different template and pages in our website and the
 blog will just have posts.
  - Anyone that is currently updating the websites will be able to help
 people with blog posts, therefore we will gain a lot more of blog admins.
  - The blog will run from our static www rotation, so we will not have to
 run expensive services or 2 cache VMs in front of it to avoid paing a lot
 to a third party for page views.
  - We will not have to update a service every now and again. The blog will
 run out of static HTML.
  - We will be able to update the templates according to our styleguide.
  - Functionalities that we will build won't break because of a drupal
 update.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 

[tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33105
   Points: |   Reviewer:
  Sponsor: |
---+
 We have been having issues with the blog for a long time. The template we
 are using was developed for another purpose and never really finished.
 We also spend a lot of money on Drupal that could rather be spent
 somewhere else.

 I propose to migrate the blog to a static website with lektor and have
 comments running from discourse.org. I have actually been in contact with
 discourse and they have offered to run a forum for us for free
 (). Addittionally they would run an .onion and a torproject.org
 subdomain.

 Moderation on discourse is much easier than on drupal comments (another
 pain point for the blog), and we would get a forum that we could use for
 other purposes too.

 This is how the blog can be migrated.

  - We will do mockups and approve them with all the parties involved.
  - We will start migrating content and have it on staging for testing.
  - Once we are happy we will archive the current blog into static pages
 and move the static bloc to blog.torproject.org.

 What we will lose:
  - Version history on posts.
  - Old comments. I see no value in migrating old blog comments to
 discourse to be honest. It would be a lot of effort and the old comments
 will be archived anyways in the blog archive.

 What we will gain:
  - Once the blog has been migrated creating posts will be no different
 than editing anyone of our websites. It would actually be a bit easier
 since there are a few different template and pages in our website and the
 blog will just have posts.
  - Anyone that is currently updating the websites will be able to help
 people with blog posts, therefore we will gain a lot more of blog admins.
  - The blog will run from our static www rotation, so we will not have to
 run expensive services or 2 cache VMs in front of it to avoid paing a lot
 to a third party for page views.
  - We will not have to update a service every now and again. The blog will
 run out of static HTML.
  - We will be able to update the templates according to our styleguide.
  - Functionalities that we will build won't break because of a drupal
 update.

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