[tor-bugs] #31711 [- Select a component]: Spread the word about the Digital Climate Strike on Tor's social media

[Tor Bug Tracker & Wiki]

#31711: Spread the word about the Digital Climate Strike on Tor's social media
--+--
 Reporter:  teor  |  Owner:  steph
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #31708
   Points:|   Reviewer:
  Sponsor:|
--+--
 Here's an example post:
 https://mobile.twitter.com/SeventhGen/status/1169227616236253186

 And here are some sample graphics and text:
 https://digital.globalclimatestrike.net/#social-downloads

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31710 [Webpages/Blog]: Write blog post about the digital climate strike, and how Tor makes activists safer

[Tor Bug Tracker & Wiki]

#31710: Write blog post about the digital climate strike, and how Tor makes
activists safer
---+--
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #31708
   Points: |   Reviewer:
  Sponsor: |
---+--
 We want to write a blog post about:
 * Tor's participation in the Digital Climate Strike, and
 * How using Tor makes climate activists safer

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31709 [Webpages/Website]: Add the Digital Climate Strike code to the Tor Website

[Tor Bug Tracker & Wiki]

#31709: Add the Digital Climate Strike code to the Tor Website
--+
 Reporter:  teor  |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #31708
   Points:|   Reviewer:
  Sponsor:|
--+
 Please add the Digital Climate Strike code to the Tor Website, by
 following the Self-Hosted instructions:
 https://github.com/fightforthefuture/digital-climate-strike#option-2-self-
 hosted

 We'll also want to set these options before loading the script:
 {{{
 
   var DIGITAL_CLIMATE_STRIKE_OPTIONS = {
 /* The Tor website base URL */
 iframeHost: 'https://www.torproject.org',
 /* Disable Google Analytics, for user privacy */
 disableGoogleAnalytics: true,
 /* Let users dismiss the banner, and use the Tor website */
 showCloseButtonOnFullPageWidget: true,
   };
 
 
 }}}

 For more details, see:
 https://github.com/fightforthefuture/digital-climate-strike#customization-
 options

 More info about the Digital Climate Strike, see:
 https://digital.globalclimatestrike.net/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31708 [- Select a component]: Make the Tor website join the Digital Climate Strike on September 20

[Tor Bug Tracker & Wiki]

#31708: Make the Tor website join the Digital Climate Strike on September 20
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Isabela has approved Tor joining the Digital Climate Strike on September
 20.

 Here's more info about the Digital Climate Strike:
 https://digital.globalclimatestrike.net/


 I'll create sub-tickets for all the things we need to do to make that
 happen.

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

Re: [tor-bugs] #31111 [Core Tor/Tor]: Properly support two padding machines per circuit

[Tor Bug Tracker & Wiki]

#3: Properly support two padding machines per circuit
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.3.x-final


Comment:

 Hi Mike,

 Do you want this fix merged into 0.4.2 or 0.4.3 ?
 For the moment, I'm going to assume 0.4.3, and put it in that milestone.

 Please change if you want something different.

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

Re: [tor-bugs] #30870 [Applications/Orbot]: Default obfs4 bridges are all offline

[Tor Bug Tracker & Wiki]

#30870: Default obfs4 bridges are all offline
+---
 Reporter:  phw |  Owner:  n8fr8
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-bridges |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by n8fr8):

 Why is it so hard to keep good obfs4 bridges online? It is frustrating
 that we have to keep changing these.

 I am not even talking about "unblocked in China", I just mean reliably
 running. What is the expected life time of an obfs4 bridge?

 We don't run our own bridges, but it may be time for us to 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] #27511 [Applications/Tor Browser]: Add New identity button to toolbar

[Tor Bug Tracker & Wiki]

#27511: Add New identity button to toolbar
-+-
 Reporter:  isnaiter |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-newnym, tbb-9.0-must-   |  Actual Points:
  alpha, TorBrowserTeam201909|
Parent ID:  #10760   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-

Comment (by antonela):

 A while ago, I dropped some ideas at a similar TBA ticket.

 https://trac.torproject.org/projects/tor/ticket/28800#comment:8

 What do you think? When do you think users need a New Identity? When do
 you think users actually *use* a New Identity?

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

Re: [tor-bugs] #26742 [Internal Services/Service - trac]: Where did the search bar on trac go? What did the 力 say?

[Tor Bug Tracker & Wiki]

#26742: Where did the search bar on trac go? What did the 力 say?
--+--
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 OP means it's absent w/o login.

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

Re: [tor-bugs] #31111 [Core Tor/Tor]: Properly support two padding machines per circuit

[Tor Bug Tracker & Wiki]

#3: Properly support two padding machines per circuit
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by mikeperry):

 * milestone:  Tor: 0.4.2.x-final => Tor: unspecified


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

Re: [tor-bugs] #31111 [Core Tor/Tor]: Properly support two padding machines per circuit (was: negotiate one machine per index)

[Tor Bug Tracker & Wiki]

#3: Properly support two padding machines per circuit
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |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] #31653 [Core Tor/Tor]: Padding cells sent with 0ms delay cause circuit failures (was: padding machine sending padding from relay to client closes circuit)

[Tor Bug Tracker & Wiki]

#31653: Padding cells sent with 0ms delay cause circuit failures
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  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] #31636 [Core Tor/Tor]: Circuit padding: Add meta probability distribution type

[Tor Bug Tracker & Wiki]

#31636: Circuit padding: Add meta probability distribution type
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, circpad-researchers-maybe-  |  Actual Points:
  want   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * keywords:  wtf-pad => wtf-pad, circpad-researchers-maybe-want


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

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding machines have shutdown sync issues (with intro circ NACKs and other cases)

[Tor Bug Tracker & Wiki]

#30992: circpadding machines have shutdown sync issues (with intro circ NACKs 
and
other cases)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad-researchers-maybe-   |  Actual Points:
  want   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * keywords:  wtf-pad circpad 042-proposed => wtf-pad circpad-researchers-
 maybe-want


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

Re: [tor-bugs] #23493 [Core Tor/Tor]: IPv6 v3 Onion Services support

[Tor Bug Tracker & Wiki]

#23493: IPv6 v3 Onion Services support
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  v3-onion-service-feature-parity- |  Actual Points:  0.7
  can, prop224, tor-hs, single-onion, ipv6,  |
  network-team-roadmap-august|
Parent ID:  #29995   | Points:  7
 Reviewer:   |Sponsor:
 |  Sponsor27-can
-+-
Changes (by teor):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  Tor: unspecified => Tor: 0.4.2.x-final


Comment:

 All the child tickets have been fixed and merged to master, closing.

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

Re: [tor-bugs] #30172 [Core Tor/Tor]: Always send PADDING_NEGOTIATE if middle supports it

[Tor Bug Tracker & Wiki]

#30172: Always send PADDING_NEGOTIATE if middle supports it
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, circpad-researchers-maybe-want|
Parent ID:   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor2-can
-+-
Changes (by mikeperry):

 * keywords:  wtf-pad, tor-relay, tor-cell, padding => wtf-pad, tor-relay,
 tor-cell, padding, circpad-researchers-maybe-want


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

Re: [tor-bugs] #30092 [Core Tor/Tor]: Add a probability-to-apply field for circuitpadidng machines

[Tor Bug Tracker & Wiki]

#30092: Add a probability-to-apply field for circuitpadidng machines
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.5
  padding, circpad-researchers-maybe-want|
Parent ID:   | Points:  2
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-
Changes (by mikeperry):

 * keywords:  wtf-pad, tor-relay, tor-cell, padding => wtf-pad, tor-relay,
 tor-cell, padding, circpad-researchers-maybe-want


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

Re: [tor-bugs] #23818 [Core Tor/Tor]: Make v2 and v3 single onion services retry all failed intro and rend connections with a 3-hop path

[Tor Bug Tracker & Wiki]

#23818: Make v2 and v3 single onion services retry all failed intro and rend
connections with a 3-hop path
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-no-backport, 035-backport,   |  Actual Points:  0.2
  040-backport, 041-backport, v3-onion-service-  |
  feature-parity, prop224, tor-hs, single-   |
  onion, ipv6, network-team-roadmap-august,  |
  consider-backport-after-0421   |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by teor):

 * parent:  #23493 =>


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

Re: [tor-bugs] #31657 [Core Tor/Tor]: Rephrase "missing descriptors" notice log to be less confusing

[Tor Bug Tracker & Wiki]

#31657: Rephrase "missing descriptors" notice log to be less confusing
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, log, tor-guard, tor-   |  Actual Points:  0.1
  bridge, tor-client, BugSmashFund, 042-should   |
Parent ID:  #21969   | Points:  0.1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Let's deal with the UX / behaviour in #31707.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31707 [Core Tor/Tor]: Better handling and UX for missing and expired guard descriptors

[Tor Bug Tracker & Wiki]

#31707: Better handling and UX for missing and expired guard descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:  Tor: 0.3.3.1-alpha
  Tor/Tor|   Keywords:  fast-fix, log, tor-guard, tor-
 Severity:  Normal   |  bridge, tor-client, BugSmashFund, 042-should
Actual Points:   |  Parent ID:  #21969
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Split off #31657:

 Replying to teor:
 > How do we reliably detect pathological cases?
 > Suppress the message, until it occurs a few times within a short
 timeframe?

 dgoulet:

 That's a good question I don't have an answer for.

 Unfortunately, I don't think that's the kind of message that occurs
 multiple times, looking at #30746 (and friends) this seems to be able to
 cause havoc with just a single repeatition.

 I'm not sure why this is the case, since `router_have_minimum_dir_info()`
 seems to be called all the time and that should eventually call
 `entry_guards_get_err_str_if_dir_info_missing()` which is the source of
 the log message... Things are kinda messy between these two functions tho,
 so it's kinda hard to understand what's the issue.

 Perhaps we can merge this patch for now since it does not seem to make the
 situation worse, and we can think in the future how to improve the UX? If
 you agree, feel free to toggle this into merge_ready since the patch 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] #31705 [Core Tor/Tor]: Add sufficient coccinelle tooling to run coccinelle without stress

[Tor Bug Tracker & Wiki]

#31705: Add sufficient coccinelle tooling to run coccinelle without stress
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 CI has passed

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

Re: [tor-bugs] #29083 [Core Tor/Tor]: WTF-PAD: Specify exit policy for machine conditions

[Tor Bug Tracker & Wiki]

#29083: WTF-PAD: Specify exit policy for machine conditions
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, circpad-researchers-maybe-want|
Parent ID:   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor2-can
-+-
Changes (by mikeperry):

 * keywords:  wtf-pad, tor-relay, tor-cell, padding => wtf-pad, tor-relay,
 tor-cell, padding, circpad-researchers-maybe-want


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

Re: [tor-bugs] #31657 [Core Tor/Tor]: Rephrase "missing descriptors" notice log to be less confusing

[Tor Bug Tracker & Wiki]

#31657: Rephrase "missing descriptors" notice log to be less confusing
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, log, tor-guard, tor-   |  Actual Points:  0.1
  bridge, tor-client, BugSmashFund, 042-should   |
Parent ID:  #21969   | Points:  0.1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => 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] #31654 [Core Tor/Tor]: Should --list-torrc-options and GETINFO config/names have more in common?

[Tor Bug Tracker & Wiki]

#31654: Should --list-torrc-options and GETINFO config/names have more in 
common?
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 That's now #31706

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31706 [Core Tor/Tor]: Expose config flags to the controller

[Tor Bug Tracker & Wiki]

#31706: Expose config flags to the controller
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #31654
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #31625, we refactored the config behaviours into an orthogonal set of
 flags.

 We should expose at least settable to the controller. We may decide to
 expose them all.

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

Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * keywords:  wtf-pad circpad => wtf-pad circpad-researchers-want


Comment:

 The #29494 implementation will change this codepath. It is reasonable for
 now to merge a workaround that just sets in_usec = 0 to ensure correct
 behavior for 0 delay in the meantime.

 There is roughly a 2/1000 chance of this happening during client rend
 circuit creation in production in 0.4.1.x (because the left edge of the
 histogram for that circuit type is 0ms and the right edge is 1000, and we
 roll the dice once on the client side and once on the relay 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] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:  tickets-migration|  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  Yes. I understand the problem you are describing and the solution you
 have. And I'm not sure how we are going to have something usable in gitlab
 with all the issues in one project (legacy in your example).
 >
 >  We could have all trac issues in a 'legacy project' and then any new
 issue in its own project (the structure that we proposed in the gitlab
 migration document). But still will make it hard to manage issues that
 way.

 You're absolutely right: it would be awful to have all tickets in the same
 project in GitLab.

 That's not what I'm proposing here.

 What I am proposing is that we '''import''' all tickets in the same
 ''legacy'' project '''BUT''' we then '''move''' each ticket to the right
 project outside of ''legacy''.

 The goal of importing everything in the same project is to make
 redirections workable. Without this, we have to guess, on the redirection
 side, which project the ticket ended up in. This could be quite difficult
 to implement and will lead a complex redirection system. We're lucky
 enough to have a "flat" numbering space for the ticket numbers in Trac
 (there's only one list of tickets), so it would be great to have the same
 thing on GitLab's side.

 By importing all tickets in the same project and then moving them, we
 accomplish this: the redirector can point to the legacy project, which in
 turn will point to the right project the issue has been moved to. I think
 it's a win-win...

 >  I understand the problem but I do not think the legacy project is a
 solution that works for us.

 ... but I'm ready to accept that as well. It's the best solution I can
 think of but I'd be happy to hear about possible alternatives. The only
 one I can think of is to have an explicit list of ticket N ->
 GITLAB_PROJECT_NAME/Y with ~40,000 entries, and I think that would be a
 pain in the ass to create and carry around forever. :)

 In summary, I agree with you that having all tickets in the same project
 is not workable, and that's not what I'm suggesting.

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

Re: [tor-bugs] #31111 [Core Tor/Tor]: negotiate one machine per index

[Tor Bug Tracker & Wiki]

#3: negotiate one machine per index
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by mikeperry):

 * keywords:  wtf-pad => wtf-pad circpad-researchers-want
 * status:  needs_information => merge_ready


Comment:

 This looks good to go to me then.

 Note: This does not affect the padding machines we deployed on the live
 network. This bug does not need backport, nor is it urgent. But it is a
 bug that researchers will encounter during development, so we should merge
 the fix to master.

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

Re: [tor-bugs] #30743 [Core Tor/Tor]: Write a coccinelle script to catch increment/decrement calls inside log_debug().

[Tor Bug Tracker & Wiki]

#30743: Write a coccinelle script to catch increment/decrement calls inside
log_debug().
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See branch `ticket30743` with PR at
 https://github.com/torproject/tor/pull/1322 .  Running it over the source
 code with the apply.sh script in #31705 found no additional instances of
 bugs like #30628.

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

Re: [tor-bugs] #29494 [Core Tor/Tor]: Optimize interaction between circuitmux and circuitpadding

[Tor Bug Tracker & Wiki]

#29494: Optimize interaction between circuitmux and circuitpadding
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  enhancement   | Status:
  |  needs_revision
 Priority:  High  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:  Sponsor2
--+
Changes (by mikeperry):

 * keywords:  wtf-pad, network-team-roadmap-2019-Q1Q2 042-proposed => wtf-
 pad circpad-researchers-want


Comment:

 I think the odds are high that this will be important for research
 results. Tagging it to denote 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] #30743 [Core Tor/Tor]: Write a coccinelle script to catch increment/decrement calls inside log_debug().

[Tor Bug Tracker & Wiki]

#30743: Write a coccinelle script to catch increment/decrement calls inside
log_debug().
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Pfew, this has gotten complicated.  I've opened another ticket to improve
 our coccinelle tooling: #31705.

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

Re: [tor-bugs] #31705 [Core Tor/Tor]: Add sufficient coccinelle tooling to run coccinelle without stress

[Tor Bug Tracker & Wiki]

#31705: Add sufficient coccinelle tooling to run coccinelle without stress
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 See branch `ticket31705` with PR at
 https://github.com/torproject/tor/pull/1321

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

Re: [tor-bugs] #29945 [Webpages/Website]: fiscal documents page has missing docs, typos, and wrong labels

[Tor Bug Tracker & Wiki]

#29945: fiscal documents page has missing docs, typos, and wrong labels
--+--
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ggus):

 Contacted Beekela, and her suggestions are:

 a) 2016-12-05 Tor Project Bylaws - move to top under "Founding Documents"
 section

 b) 2012 Financial Statements - AUDIT

 c) 2011 State of MA Form PC - AUDIT

 d) 2010 IRS Form 990, State of MA Form PC, and Independent Audit Results -
 AUDIT, IRS 990

 e) 2009 Dept of Commerce Data Collection Form - FISCAL YEAR

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

Re: [tor-bugs] #31407 [Circumvention/Snowflake]: Create a broker spec for metrics collection

[Tor Bug Tracker & Wiki]

#31407: Create a broker spec for metrics collection
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+-
Changes (by phw):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me.

 Small suggestion: revisions are easier to review if we address them in
 separate follow-up patches. Once everything looks good, we can squash the
 revision patches and end up with a single, well-formatted commit. Without
 separate revision patches, it's a bit tricky to see what changed between
 revisions.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31705 [Core Tor/Tor]: Add sufficient coccinelle tooling to run coccinelle without stress

[Tor Bug Tracker & Wiki]

#31705: Add sufficient coccinelle tooling to run coccinelle without stress
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+
 I think we need two pieces of coccinelle tooling to be able to use it
 effectively:

 1) A script that tells us which files have parsing problems.

 2) A script to invoke spatch with the right arguments.

 Based on 1 and 2, we can improve our tor-coccinelle.h file to handle more
 of our codebase, and we can apply coccinelle scripts without trying to
 remember the name of the "-macro-file-builtins" flag.

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

Re: [tor-bugs] #31637 [Core Tor/Tor]: Make sure we have test coverage for Option, +Option and /Option across defaults, torrc, command line

[Tor Bug Tracker & Wiki]

#31637: Make sure we have test coverage for Option, +Option and /Option across
defaults, torrc, command line
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => 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] #31637 [Core Tor/Tor]: Make sure we have test coverage for Option, +Option and /Option across defaults, torrc, command line

[Tor Bug Tracker & Wiki]

#31637: Make sure we have test coverage for Option, +Option and /Option across
defaults, torrc, command line
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 Okay, I've got something that works.  See notes above: It's not ready to
 merge, but I'd like to know how the approach looks to you.

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

Re: [tor-bugs] #31704 [Applications]: help

[Tor Bug Tracker & Wiki]

#31704: help
--+
 Reporter:  kain3e|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Looks like another instance of #31506.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31704 [Applications]: help

[Tor Bug Tracker & Wiki]

#31704: help
---+--
 Reporter:  kain3e |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Component:  Applications
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Every time I open tor it wont open it says to restart tor when i do it
 never works when i press copy to clipboard 0 comes up even if its just to
 delete the orginal tor file i cant find 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] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:  tickets-migration|  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gaba):

 Yes. I understand the problem you are describing and the solution you
 have. And I'm not sure how we are going to have something usable in gitlab
 with all the issues in one project (legacy in your example).

 We could have all trac issues in a 'legacy project' and then any new issue
 in its own project (the structure that we proposed in the gitlab migration
 document). But still will make it hard to manage issues that way.

 Right now we have (as a way to test) a project Scalability
 (https://dip.torproject.org/torproject/scalability) that is at the base of
 the Tor project group and is shared with other groups (like metrics and
 core). Still we can not add issues from scalability to the metrics and
 core kanban boards...

 I understand the problem but I do not think the legacy project is a
 solution that works for us.

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

Re: [tor-bugs] #30870 [Applications/Orbot]: Default obfs4 bridges are all offline

[Tor Bug Tracker & Wiki]

#30870: Default obfs4 bridges are all offline
+---
 Reporter:  phw |  Owner:  n8fr8
 Type:  defect  | Status:  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-bridges |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by phw):

 * status:  needs_review => needs_information


Comment:

 Setting this to "needs_information" to see what orbot's strategy here is.
 I will remove the fix I pushed earlier because it's already outdated
 again. For what it's worth, our list of default bridges is available here:
 https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges

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

Re: [tor-bugs] #28533 [Circumvention/BridgeDB]: bridgesdb: replace the message to mail support with a link to the documentation

[Tor Bug Tracker & Wiki]

#28533: bridgesdb: replace the message to mail support with a link to the
documentation
+---
 Reporter:  emmapeel|  Owner:  phw
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  ex-sponsor-19   |  Actual Points:  0.2
Parent ID:  | Points:  1
 Reviewer:  cohosh  |Sponsor:  Sponsor30-can
+---
Changes (by phw):

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


Comment:

 Thanks, everyone. I merged and deployed the patch.

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

Re: [tor-bugs] #31703 [Internal Services/Service - dist]: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully slow

[Tor Bug Tracker & Wiki]

#31703: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully 
slow
--+--
 Reporter:  pospeselr |  Owner:  anarcat
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - dist  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by anarcat):

 rejected options:

  * redirect traffic to sunet (got cold feet after last DDOS) or savii (not
 all the files)
  * just pull cymru out of rotation altogether (could overload existing
 mirrors and kill other mirrors)

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

Re: [tor-bugs] #31703 [Internal Services/Service - dist]: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully slow

[Tor Bug Tracker & Wiki]

#31703: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully 
slow
--+--
 Reporter:  pospeselr |  Owner:  anarcat
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - dist  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ggus):

 * cc: ggus (removed)
 * component:  Webpages/Website => Internal Services/Service - dist


Comment:

 Moving to Internal Services/Service - dist.

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

Re: [tor-bugs] #31703 [Webpages/Website]: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully slow

[Tor Bug Tracker & Wiki]

#31703: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully 
slow
--+--
 Reporter:  pospeselr |  Owner:  anarcat
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by anarcat):

 battle plan:

  1. i poked cymru about upgrading to gbps. weasel memory tells us we used
 to be but we have been downgraded over 6 months ago at least (according to
 backups)
  2. if cymru fails or times out (7 days?), we setup another mirror (or
 varnish cache) elsewhere (fsn cluster?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31703 [Webpages/Website]: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully slow

[Tor Bug Tracker & Wiki]

#31703: Downloading Tor Browser from 2620:0:6b0:b:225:dada:19:1 is painfully 
slow
--+--
 Reporter:  pospeselr |  Owner:  anarcat
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Chat

 {{{
 (2019-09-11 12:44:26 PM) pospeselr: this one i think:
 2620:0:6b0:b:225:dada:19:1
 (2019-09-11 12:47:30 PM) pospeselr: though if i wget it it does come down
 a bit faster
 (2019-09-11 12:47:53 PM) arma1: that address is a team cymru address
 (2019-09-11 12:48:03 PM) arma1: i wonder if its magic black box ddos
 defense thinks you're a bad person
 (2019-09-11 12:48:21 PM) pospeselr: well i mean i am obviously, but i
 would still like to dl tor browser quickly >:[
 (2019-09-11 12:48:52 PM) pospeselr: and i take it back, the wget dl is
 slowly slowing down, 80 kb/s now
 (2019-09-11 12:49:23 PM) arma1: anarcat: ^ you any good at these topics?
 :)
 (2019-09-11 12:49:43 PM) anarcat: arma1: i'm in a meeting, but i'll be
 here in 10min
 (2019-09-11 12:49:47 PM) anarcat: arma1: what's the TL;DR
 (2019-09-11 12:49:59 PM) pospeselr: server slow plz make fast
 (2019-09-11 12:50:03 PM) arma1: one of the dist.tpo is being slow for
 pospeselr
 (2019-09-11 12:50:14 PM) arma1: not critical
 (2019-09-11 12:50:18 PM) anarcat: one of, which?
 (2019-09-11 12:50:37 PM) anarcat: how to reproduce?
 (2019-09-11 12:50:38 PM) arma1: dist.torproject.org aka
 2620:0:6b0:b:225:dada:19:1
 (2019-09-11 12:50:51 PM) anarcat: Host
 1.0.0.0.9.1.0.0.a.d.a.d.5.2.2.0.b.0.0.0.0.b.6.0.0.0.0.0.0.2.6.2.ip6.arpa
 not found: 3(NXDOMAIN)
 (2019-09-11 12:50:53 PM) anarcat: great
 (2019-09-11 12:51:21 PM) anarcat: that's at cymru
 (2019-09-11 12:52:25 PM) anarcat: it's web-cymru-01.torproject.org
 specifically
 (2019-09-11 12:52:34 PM) anarcat: which file should i try to get?
 (2019-09-11 12:53:03 PM) anarcat: ( i found the server through a search in
 ldap)
 (2019-09-11 12:53:54 PM) pospeselr:
 https://dist.torproject.org/torbrowser/8.5.5/tor-browser-linux64-8.5.5_en-
 US.tar.xz
 (2019-09-11 12:54:36 PM) anarcat: Connecting to dist.torproject.org
 (dist.torproject.org)|2620:0:6b0:b:225:dada:19:1|:443... failed: Network
 is unreachable.
 (2019-09-11 12:54:37 PM) anarcat: duh
 (2019-09-11 12:55:18 PM) anarcat: i'm getting 130KB/s there now
 (2019-09-11 12:55:30 PM) pospeselr: yeah exactly
 (2019-09-11 12:55:41 PM) pospeselr: and it'll slow down to tourghly 50
 kb/s shortly
 (2019-09-11 12:56:33 PM) anarcat: yeah, there might be saturation there
 (2019-09-11 12:56:39 PM) anarcat: i'll take a look at the host (moly)
 (2019-09-11 12:58:26 PM) anarcat: network's saturated on moly
 (2019-09-11 12:58:28 PM) anarcat: 12MB/s
 (2019-09-11 12:58:32 PM) anarcat: mbps
 (2019-09-11 1:01:38 PM) arma1: anarcat: in the past, sometimes, cymru ran
 black box ddos resistance doohickeys on their network, and we discovered
 them (and bugs in them) by seeing anomalies like this
 (2019-09-11 1:09:41 PM) anarcat: well it sure seems like the cymru web
 mirror is capped to 100mbps
 }}}

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

Re: [tor-bugs] #31637 [Core Tor/Tor]: Make sure we have test coverage for Option, +Option and /Option across defaults, torrc, command line

[Tor Bug Tracker & Wiki]

#31637: Make sure we have test coverage for Option, +Option and /Option across
defaults, torrc, command line
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 (I'm currently wrestling with appveyor to try work around CRLF issues.
 Any advice here would be welcome)

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

Re: [tor-bugs] #30870 [Applications/Orbot]: Default obfs4 bridges are all offline

[Tor Bug Tracker & Wiki]

#30870: Default obfs4 bridges are all offline
+--
 Reporter:  phw |  Owner:  n8fr8
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-bridges |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:30870 phw]:
 > but in the short run we should make sure that these bridges are kept in
 sync with our default bridges

 Btw, the original idea here was that Orbot intentionally shipped with a
 different list of default bridges than Tor Browser, because then whichever
 one attracted more censor attention wouldn't automatically undermine the
 other.

 Though if Orbot isn't maintaining its chosen bridges, that original idea
 isn't so smart anymore. :)

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

Re: [tor-bugs] #31637 [Core Tor/Tor]: Make sure we have test coverage for Option, +Option and /Option across defaults, torrc, command line

[Tor Bug Tracker & Wiki]

#31637: Make sure we have test coverage for Option, +Option and /Option across
defaults, torrc, command line
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => 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] #31538 [Applications/Tor Browser]: Windows bundles based on ESR 68 are not built reproducibly

[Tor Bug Tracker & Wiki]

#31538: Windows bundles based on ESR 68 are not built reproducibly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909,   |
  GeorgKoppen201909  |
Parent ID:  #30322   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:19 gk]:
 > However, other object files are still included non-deterministically
 after that part. I am not sure yet where they are coming from...

 Okay, I think I am at the bottom of that rabbit hole. Thre reason for that
 issue is that `libc++.a` is getting merged with the contents of
 `libc++abi.a` (which, by the way, itself is reproducible at least after
 switching to CMake's 3.5.13). Now, that merging gets done in libc++'s
 `merge_archives.py` (https://github.com/llvm/llvm-
 project/blob/release/8.x/libcxx/utils/merge_archives.py). The problem here
 is:
 {{{
 files = glob.glob(os.path.join(temp_directory_root, '*.o*'))
 }}}
 From the doc (https://docs.python.org/2/library/glob.html):
 {{{
 "The glob module finds all the pathnames matching a specified pattern
 according to the rules used by the Unix shell, although results are
 returned in arbitrary order."
 }}}
 So, doing a simple
 {{{
 files = sorted(glob.glob(os.path.join(temp_directory_root, '*.o*')))
 }}}
 gets us finally a reproducible `libc++.a` and a reproducible 64-bit .exe.
 I am currently testing the 32-bit version as well and will prepare a
 proper patch for review tomorrow.

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

Re: [tor-bugs] #31637 [Core Tor/Tor]: Make sure we have test coverage for Option, +Option and /Option across defaults, torrc, command line

[Tor Bug Tracker & Wiki]

#31637: Make sure we have test coverage for Option, +Option and /Option across
defaults, torrc, command line
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I've started a shell script that will be useful for this, and maybe also
 for parts of #31631.

 It isn't done yet!  I've only written the script and a few example tests
 for it -- I need to write a bunch more tests before I can call this done,
 and also I need to write a changes file.  But before I more ahead, I'd
 like to know what you think of this approach.  No need to do a full review
 now: I just want to know whether you think I should proceed with this line
 of work.

 The branch is `ticket31637_wip`. PR at
 https://github.com/torproject/tor/pull/1320 .

 (WRT #31631: It tests configuration round-trips, but not state or
 sr_disk_state.)

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

Re: [tor-bugs] #31465 [Applications/Tor Browser]: Adapt tor-browser-build projects for macOS notarization

[Tor Bug Tracker & Wiki]

#31465: Adapt tor-browser-build projects for macOS notarization
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, tbb-rbm,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30126   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-security, tbb-rbm, TorBrowserTeam201908R, GeorgKoppen201908, tbb-
 backport
 => tbb-security, tbb-rbm, TorBrowserTeam201908R, GeorgKoppen201908


Comment:

 Apple seems to have relaxed the notarization requirements so that we don't
 need that backport anymore for our hopefully last esr60-based browser
 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] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201909  |  Actual Points:  2.5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  reopened => 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] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  reopened
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201909  |  Actual Points:  2.5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  closed => reopened
 * 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] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:  6
  roadmap-august, security, 042-should   |
Parent ID:  #2   | Points:  7
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by s7r):

 The attacks are quite possible, but also the current replay cache behavior
 can be trivailly gamed so the onion service will rotate intro points more
 often than we would normally want and thus trigger a different sybil type
 attack where eventually the onion service pick a hostile introduction
 point. Both time limit and number of introductions limit are important and
 mitigate different thread models.

 Which is why I think configuring the replay cache to limit on a "hybrid"
 threshold (time + introductions) as described in comment:11 will not
 interfere with the issues and concerns described above. It's just about
 choosing the right variable min and max values so that introduction points
 are not rotated too fast but also cannot send unlimited replays
 (introductions) during their time-based lifetime. A "hybrid" limitation as
 described will simply enhance the current behavior instead of radically
 changing 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] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201909  |  Actual Points:  2.5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 \o/ It seems we are done here. I opened #31702 for backporting the crash
 bug fix and then we should roll out updates asap I think, ideally starting
 with our alpha series.

 mcs/brade please add to the points actually spent. I am just adding mine.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31702 [Applications/Tor Browser]: Backport patch for bug 1578075 for macOS Catalina

[Tor Bug Tracker & Wiki]

#31702: Backport patch for bug 1578075 for macOS Catalina
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201909
Actual Points:|  Parent ID:
   Points:  0.25  |   Reviewer:
  Sponsor:|
--+
 We are almost ready to ship macOS bundles compatible with Catalina.
 However, we need to backport at least the patch for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1578075 as Mozilla does not
 seem to be making another esr60 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] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

[Tor Bug Tracker & Wiki]

#31660: Revise onboarding to take new Firefox experience into account
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:1 antonela]:
 > Thanks for the heads up, gk. Do you have any documentation link I could
 explore regarding any Firefox onboarding in ESR68? I failed when I tried
 to find it.

 I have not looked closely to be honest. It's part of the activity stream
 now, https://bugzilla.mozilla.org/show_bug.cgi?id=1457565 being the meta
 bug. Clicking a bit around I found

 https://trello.com/c/gRkk9mI2/188-i-want-a-simple-onboarding-tour-to-run-
 at-the-first-run-of-the-first-new-tab-page

 but we should probably dig up more 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] #31626 [Core Tor/Tor]: Move confparse.[ch] into lib/confmgt

[Tor Bug Tracker & Wiki]

#31626: Move confparse.[ch] into lib/confmgt
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  042-should|  Actual Points:  .1
Parent ID:  #29211| Points:  0
 Reviewer:  teor  |Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * reviewer:   => teor
 * actualpoints:   => .1


Comment:

 CI has passed.

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

Re: [tor-bugs] #31464 [Applications/Tor Browser]: meek and moat are broken on macOS 10.9 with the switch to Go 1.12

[Tor Bug Tracker & Wiki]

#31464: meek and moat are broken on macOS 10.9 with the switch to Go 1.12
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-rbm, meek |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:3 mcs]:
 > Replying to [comment:2 dcf]:
 > > I suppose this is a problem not only with the meek from meek.git, but
 also when using meek_lite with obfs4proxy (#29430)? Or does obfs4proxy
 somehow avoid using the problematic `_unlinkat` symbol? If the latter is
 the case, then #29430 would seem to solve it.
 >
 > In fact, obfs4proxy seems to avoid this problem. See 30126#comment:56
 >
 > > According to https://github.com/golang/go/wiki/Darwin, OS X 10.9 is
 not supported past Go 1.10.8.
 >
 > I guess we should try to support macOS 10.9.x as long as we can, but it
 may be a losing battle. And even though Mozilla still supports it for
 Firefox, we should not recommend it since 10.9 only rarely receives
 security updates from Apple.
 >
 > Georg, should we close this ticket since this issue seems to be resolved
 with Tor Browser 9.0a6 (after the switch to meek_lite)?

 Yes.

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

Re: [tor-bugs] #31407 [Circumvention/Snowflake]: Create a broker spec for metrics collection

[Tor Bug Tracker & Wiki]

#31407: Create a broker spec for metrics collection
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+--
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 Made suggested fixes:
 
https://github.com/cohosh/snowflake/commit/2bf398af39bda0d2fa684f9d0571e9ea727e1ef9

 I also renamed the folder to `doc` to match obfs4.

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

Re: [tor-bugs] #31603 [Internal Services/Service - github tpo]: GitHub close Support, tpo, community issues

[Tor Bug Tracker & Wiki]

#31603: GitHub close Support, tpo, community issues
+--
 Reporter:  ggus|  Owner:  hiro
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - github tpo  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by antonela):

 I don't have credentials to do it, but here is the way to disable issues
 in Github's repositories

 https://help.github.com/en/articles/disabling-issues

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

Re: [tor-bugs] #30203 [Webpages/Website]: The "Download Tor Source Code" page is mixing source code and win32 binaries

[Tor Bug Tracker & Wiki]

#30203: The "Download Tor Source Code" page is mixing source code and win32
binaries
--+--
 Reporter:  boklm |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Replying to [comment:7 gk]:
 > Replying to [comment:6 hiro]:
 > > I think this could be a good solution: https://share.riseup.net
 /#sqydaqO5OYR-72FeHfhbGw
 >
 > But it is still mixing source code with binaries while saying "Download
 Tor Source Code". Maybe we could label the while thing "Alternative
 Downloads" or something, indicating that we offer here a bunch of
 different (albeit related) things?

 True. We are still mixing source code with binaries and is something that
 we want to fix once the developers portal is in place.

 Now, I see Tor source code as a more critical downloadable than windows
 expert bundles. That is why we have "Download Tor source code" in our
 current /download page.

 If you still see it as a problem, I'm happy to rename this link with
 something like "Alternative Downloads" as arma/you suggested if that
 reflects better what it is inside.

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

Re: [tor-bugs] #31676 [Internal Services/Tor Sysadmin Team]: decommission togashii

[Tor Bug Tracker & Wiki]

#31676: decommission togashii
-+-
 Reporter:  weasel   |  Owner:  weasel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31686   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tpa => weasel
 * status:  new => assigned


Comment:

 weasel started 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] #29399 [Internal Services/Tor Sysadmin Team]: Retire host and services for tordnsel and check

[Tor Bug Tracker & Wiki]

#29399: Retire host and services for tordnsel and check
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31686   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * parent:   => #31686


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

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:  tickets-migration|  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  We need to find a way to get this requirement (ticket number unique
 across tor project group but in its own project) with tickets in its own
 project. Check the plan document to see the structure we are proposing (it
 is at the end of the document)

 The process I'm suggesting (import everything in a single project and move
 in a separate projects in a subsequent operation) fulfills this
 requirement.

 >  Ahf is working on that already. I think the idea is to have gaps in
 ticket numbers in projects to be able to fullfill this requirement.

 I don't think it does. It will work for a single project (say the tor
 little t project), but it can't work for all.

 Just to be clear, I'm fine with having tickets split up in different
 projects. I just don't think it's possible to have redirections working if
 we split them up '''at import time'''.

 Say you have:

  * ticket #1 in Component: Core Tor/Tor
 (https://trac.torproject.org/projects/tor/ticket/1)
  * ticket #2 in Component: Internal Service/Services Admin Team
 (https://trac.torproject.org/projects/tor/ticket/2)

 Under the process you propose, those would map into:

  * https://dip.torproject.org/tor/tor/issues/1
  * https://dip.torproject.org/tor/sysadmin/issues/2

 (project names may vary, this is just an example)

 How do I map https://trac.torproject.org/projects/tor/ticket/2 to
 https://dip.torproject.org/tor/sysadmin/issues/2? More generally, how
 would I know which ''GitLab project'' an arbitrary
 https://trac.torproject.org/projects/tor/ticket/N would map into?

 The answer is: there's no way to know, short of making an explicit, 40
 '''thousand''' long list of redirections. I think that's deeply
 impractical, and counter to the spirit of the requirement.

 Instead, what I am proposing is this: tickets #1 and #2 would map into:

  * ​https://dip.torproject.org/tor/legacy/issues/1
  * ​https://dip.torproject.org/tor/legacy/issues/2

 Issue #1 in GitLab would have a label "component: Core tor/tor" and #2
 would have a label "component: Internal servives/Services Admin team".
 Then a '''post-processing''' script, which can easily be made by only
 talking with the GitLab API, '''moves''' those tickets to the right
 project, their final destination stated above:

  * https://dip.torproject.org/tor/tor/issues/1
  * https://dip.torproject.org/tor/sysadmin/issues/2

 ... but because ticket moves in GitLab leave a trace, we can *still*
 redirect from:

  * https://trac.torproject.org/projects/tor/ticket/1 to
 https://dip.torproject.org/tor/legacy/issues/1 which redirects to
 https://dip.torproject.org/tor/tor/issues/1
  * https://trac.torproject.org/projects/tor/ticket/2 to
 https://dip.torproject.org/tor/legacy/issues/2 which redirects to
 https://dip.torproject.org/tor/sysadmin/issues/2

 And we can therefore have a '''generic''' redirector that looks like:

 https://trac.torproject.org/projects/tor/ticket/N ->
 https://dip.torproject.org/tor/legacy/issues/N

 It's fundamentally the same idea, it just differs as to where we
 '''first''' import the tickets.

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

Re: [tor-bugs] #28533 [Circumvention/BridgeDB]: bridgesdb: replace the message to mail support with a link to the documentation

[Tor Bug Tracker & Wiki]

#28533: bridgesdb: replace the message to mail support with a link to the
documentation
+---
 Reporter:  emmapeel|  Owner:  phw
 Type:  defect  | Status:  merge_ready
 Priority:  High|  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ex-sponsor-19   |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  cohosh  |Sponsor:  Sponsor30-can
+---
Changes (by cohosh):

 * 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

Re: [tor-bugs] #31683 [Core Tor/Tor]: md: Bad family line in cached-microdescs.new

[Tor Bug Tracker & Wiki]

#31683: md: Bad family line in cached-microdescs.new
---+
 Reporter:  dgoulet|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  microdesc, 042-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 I think your diagnosis is correct.  Is it possible that your Tor client
 shut down abruptly while writing the microdescs?

 I believe we've seen this bug before, maybe #28223?

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

Re: [tor-bugs] #31686 [Internal Services/Tor Sysadmin Team]: retire textile

[Tor Bug Tracker & Wiki]

#31686: retire textile
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 ~~one~~ ~~two~~ three (!) more machines are supposed to eventually be
 retired (gayi/SVN in #17202 and check.tpo/tordnsel/chiwui in #29399,
 togashii/testnet in #31676) so we shouldn't migrate those either.

 this leaves us with those machines to migrate before textile can be
 decommissioned, yaay!

 {{{
 iranicum.torproject.org:
  - shell/irc box
 saxatile.torproject.org:
  - www.torproject.org
  - static content rotation
 weissii.torproject.org:
  - Windows buildbox
 winklerianum.torproject.org:
  - Windows buildbox
 }}}

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

Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

[Tor Bug Tracker & Wiki]

#31660: Revise onboarding to take new Firefox experience into account
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * cc: acat (added)


Comment:

 adding acat here too.

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

Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

[Tor Bug Tracker & Wiki]

#31660: Revise onboarding to take new Firefox experience into account
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Thanks for the heads up, gk. Do you have any documentation link I could
 explore regarding any Firefox onboarding in ESR68? I failed when I tried
 to find 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] #17202 [Internal Services/Tor Sysadmin Team]: Shut down SVN and decomission the host (gayi)

[Tor Bug Tracker & Wiki]

#17202: Shut down SVN and decomission the host (gayi)
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31686   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * parent:   => #31686


Comment:

 gayi is on textile, which we want to decomission, so mark that relation

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

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:  tickets-migration|  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gaba):

 Replying to [comment:44 anarcat]:
 > > Tickets will be imported by team/project. It will not work for us to
 have ALL trac tickets in one project in gitlab.
 >
 > I don't see why that has to be the case. We could (more!) easily import
 ''everything'' in a ''single'' project and then, '''post-import''', split
 tickets up between projects.
 >
 > '''Not''' doing so will make it '''impossible''' to fill that first
 requirement, as there will not be a stable URL on GitLab's side for ticket
 #1234 from Trac.



 We need to find a way to get this requirement (ticket number unique across
 tor project group but in its own project) with tickets in its own project.
 Check the plan document to see the structure we are proposing (it is at
 the end of the document)


 >
 > > And that brings me the question on where are we going to have sysadmin
 tickets in gitlab? I was thinking as its own group in gitlab but you may
 have other idea for it.
 >
 > Sure, they can be moved to its own group after the import, like
 everything else.
 >
 > > Sorry that I was not clear. Any new ticket in gitlab will have a
 number that has not being assigned in trac yet. We preserve the number for
 tickets that already exist.
 >
 > Agreed, although you need to understand that ticket numbering is *per
 project* in GitLab. (Strictly speaking, that's also the case in Trac, but
 we have only a single project in Trac, while we already have multiple
 project in GitLab.)
 >
 > So in practice, we will have multiple #1234 tickets in GitLab. This is
 why we need to import everything in a single project at first so that we
 have consistent numbering. *Then* when we move issues around in GitLab,
 the numbers will change, but there will be a note in the "legacy" tickets
 pointing to the new one.
 >
 > I don't know how else you could implement those constraints otherwise.


 Ahf is working on that already. I think the idea is to have gaps in ticket
 numbers in projects to be able to fullfill this requirement.

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

Re: [tor-bugs] #31700 [Internal Services/Service - jabber]: decomission jabber server

[Tor Bug Tracker & Wiki]

#31700: decomission jabber server
+--
 Reporter:  anarcat |  Owner:  anarcat
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - jabber  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #30608  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by anarcat):

 i wrote an announcement, will send after approval from vegas

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31701 [Circumvention/Obfs4]: Reachability tests for new obfs4 bridges

[Tor Bug Tracker & Wiki]

#31701: Reachability tests for new obfs4 bridges
---+---
 Reporter:  cohosh |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component: |Version:
  Circumvention/Obfs4  |
 Severity:  Normal |   Keywords:  reachability, measurement
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 As a follow up to #29279, we can now set up some new reachability tests on
 a subset of the bridges we've gotten through our bridge campaign \o/

 We probably don't want to test all of the new bridges in case these tests
 cause a bunch of bridges to get blocked when they otherwise wouldn't.

 As mentioned in
 [https://trac.torproject.org/projects/tor/ticket/29279#comment:9
 #29279:comment:9], we should sample bridges from our various distribution
 mechanisms (email, private, and HTTPS), and also from any finer grained
 partitions we have (email provider, subnet, etc.).

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

Re: [tor-bugs] #31557 [Internal Services/Service - github tpo]: Update torproject/web group membership permissions

[Tor Bug Tracker & Wiki]

#31557: Update torproject/web group membership permissions
-+-
 Reporter:  pili |  Owner:  hiro
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - github   |Version:
  tpo|
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ggus):

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


Comment:

 Thanks hiro!

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

Re: [tor-bugs] #31700 [Internal Services/Service - jabber]: decomission jabber server

[Tor Bug Tracker & Wiki]

#31700: decomission jabber server
+--
 Reporter:  anarcat |  Owner:  anarcat
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - jabber  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #30608  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by anarcat):

 there are 32 users on the LDAP server, and we might be able to directly
 email some of them, see the output of:

 {{{
 cut -d: -f1 /var/local/rtc-passwords.prosody
 }}}

 for a list of emails.

 out of those 32 users, only a third (11) have logged in in the last year,
 and only 12% (4) in the last month.

 so i think it's fair to see it's underused and i think people can find
 other places for their IM service.

 next step is to write an announcement for the host retirement and send it
 to those people and tor-project@...

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

Re: [tor-bugs] #31686 [Internal Services/Tor Sysadmin Team]: retire textile

[Tor Bug Tracker & Wiki]

#31686: retire textile
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 one of those machines is chamaemoly, which will be decommissioned
 altogether and shouldn't be migrated, see #31700.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31700 [Internal Services/Service - jabber]: decomission jabber server

[Tor Bug Tracker & Wiki]

#31700: decomission jabber server
+--
 Reporter:  anarcat |  Owner:  anarcat
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - jabber  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #30608
   Points:  |   Reviewer:
  Sponsor:  |
+--
 the jabber server is not really used anymore, and we need the LDAP field
 for the new email service (in #30608).

 decommission the server (chamaemoly) with a warning period for users to
 have time to migrate their rosters off the server.

 roadmap:

  1. T-30d: warn users about impeding shutdown,
  2. T: shutdown the jabber service itself
  3. T+7d: start the server decommissioning 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] #31185 [Internal Services/Service - trac]: delete spam comment

[Tor Bug Tracker & Wiki]

#31185: delete spam comment
--+-
 Reporter:  cypherpunks   |  Owner:  anarcat
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  0.001
 Reviewer:|Sponsor:
--+-
Changes (by anarcat):

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


Comment:

 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] #31185 [Internal Services/Service - trac]: delete spam comment

[Tor Bug Tracker & Wiki]

#31185: delete spam comment
--+--
 Reporter:  cypherpunks   |  Owner:  anarcat
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.001
 Reviewer:|Sponsor:
--+--
Changes (by anarcat):

 * status:  reopened => assigned
 * owner:  qbi => anarcat


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

Re: [tor-bugs] #31379 [Internal Services/Service - trac]: Get error message "Error loading tickets." On the 'Create New Ticket' page after writing to the 'summery' input box

[Tor Bug Tracker & Wiki]

#31379: Get error message "Error loading tickets." On the 'Create New Ticket' 
page
after writing to the 'summery' input box
--+-
 Reporter:  xhdix |  Owner:  anarcat
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by anarcat):

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


Comment:

 i don't know if that was the same situation, but i created this exact
 problem last night by enabling the httpauth plugin on the /xmlrpc
 endpoints. there were the same symptoms this morning.

 to solve this, i moved the httpauth plugin to /rpc instead, which fixed
 the search box.

 this could have been a similar test done 5 weeks ago you stumbled upon.

 i believe this is, therefore, 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] #31379 [Internal Services/Service - trac]: Get error message "Error loading tickets." On the 'Create New Ticket' page after writing to the 'summery' input box

[Tor Bug Tracker & Wiki]

#31379: Get error message "Error loading tickets." On the 'Create New Ticket' 
page
after writing to the 'summery' input box
--+--
 Reporter:  xhdix |  Owner:  anarcat
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by anarcat):

 * owner:  qbi => anarcat
 * status:  new => assigned


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

Re: [tor-bugs] #26742 [Internal Services/Service - trac]: Where did the search bar on trac go? What did the 力 say?

[Tor Bug Tracker & Wiki]

#26742: Where did the search bar on trac go? What did the 力 say?
--+
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by anarcat):

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


Comment:

 i don't understand what this ticket is about: the search box is still here
 and works.

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

Re: [tor-bugs] #30608 [Internal Services/Tor Sysadmin Team]: Have a SMTP out only server

[Tor Bug Tracker & Wiki]

#30608: Have a SMTP out only server
-+-
 Reporter:  dgoulet  |  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 we reached a conclusion for this in Stockholm, which was documented here:

 
https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Notes/EmailNotEmail

 the next steps are:

  1. shutdown the Jabber server
  2. optionally, setup a separate email server to accept submissions and
 keep mail servers aware that not only eugeni sends email
  3. hook up the webRTC password as authentication in Postfix in that
 server (or eugeni)
  4. do tests with the users in this ticket, and if this works, propagate
 to all current LDAP users
  5. create LDAP accounts for more users who want to use the system

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31699 [Core Tor/Tor]: Remove unused configure.ac checks

[Tor Bug Tracker & Wiki]

#31699: Remove unused configure.ac checks
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:  #31698
   Points:|   Reviewer:
  Sponsor:|
--+--
 Here is a little script to find macros in orconfig.h.in that are not
 actually mentioned in our code:
 {{{
 #/bin/bash
 for macroname in $(grep '#undef' orconfig.h.in | awk -e '{ print $2; }') ;
 do
 git grep -l "$macroname" src >/dev/null || echo "$macroname"
 done
 }}}

 Some of these macros are used in system header files, but we can safely
 remove the autoconf checks for the ones that are not.  I think they are:
 {{{
 HAVE_EVENT2_BUFFEREVENT_SSL_H
 HAVE_EVENT2_DNS_H
 HAVE_EVENT2_EVENT_H
 HAVE_EVP_SHA3_256
 HAVE_GETPASS
 HAVE_HTONLL
 HAVE_LIBCAP
 HAVE_MALLOC_MALLOC_H
 HAVE_MALLOC_NP_H
 HAVE_STRUCT_TCP_INFO_TCPI_SND_MSS
 HAVE_STRUCT_TCP_INFO_TCPI_UNACKED
 HAVE_SYS_SYSLIMITS_H
 HAVE_U_CHAR
 SRCDIR
 }}}

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

Re: [tor-bugs] #31698 [Core Tor/Tor]: Reconsider HAVE_XXX_H usage in the Tor code

[Tor Bug Tracker & Wiki]

#31698: Reconsider HAVE_XXX_H usage in the Tor code
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 (We'll need to hand-check each of these, but it might be a good list to
 start with.)

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

Re: [tor-bugs] #31698 [Core Tor/Tor]: Reconsider HAVE_XXX_H usage in the Tor code

[Tor Bug Tracker & Wiki]

#31698: Reconsider HAVE_XXX_H usage in the Tor code
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * Attachment "count_include_checks.sh" 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] #31698 [Core Tor/Tor]: Reconsider HAVE_XXX_H usage in the Tor code

[Tor Bug Tracker & Wiki]

#31698: Reconsider HAVE_XXX_H usage in the Tor code
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 This list might be helpful.  It lists every system header we include that
 has a guard defined in orconfig.h.  The first column is the number of
 times we check HAVE_FOO_H before we include it; the second column is the
 number of times we include it.  I will attach the kludgey script I used to
 generate it.

 {{{
 0   102 stdlib.h
 0   10  event2/event.h
 0   1   crt_externs.h
 0   1   net/pfvar.h
 0   1   sys/select.h
 0   2   libscrypt.h
 0   2   seccomp.h
 0   2   stdatomic.h
 0   32  stdint.h
 0   3   event2/dns.h
 0   3   inttypes.h
 1   1   android/log.h
 1   1   mach/vm_inherit.h
 1   1   malloc.h
 1   1   readpassphrase.h
 1   1   sys/eventfd.h
 1   1   sys/fcntl.h
 1   1   sys/limits.h
 1   1   syslog.h
 1   1   sys/random.h
 1   1   sys/statvfs.h
 1   1   sys/utime.h
 1   2   cygwin/signal.h
 1   2   execinfo.h
 1   2   grp.h
 1   2   sys/file.h
 1   2   sys/syscall.h
 1   2   sys/sysctl.h
 1   2   ucontext.h
 1   3   ifaddrs.h
 1   3   sys/ucontext.h
 2   145 string.h
 2   2   crypto_scalarmult_curve25519.h
 2   2   linux/netfilter_ipv4.h
 2   2   linux/netfilter_ipv6/ip6_tables.h
 2   2   nacl/crypto_scalarmult_curve25519.h
 2   2   sys/capability.h
 2   3   sys/prctl.h
 2   3   sys/un.h
 2   4   pthread.h
 2   6   netdb.h
 2   8   limits.h
 3   3   linux/if.h
 3   3   linux/types.h
 3   4   sys/resource.h
 3   4   sys/wait.h
 3   6   pwd.h
 4   17  time.h
 4   35  errno.h
 4   4   utime.h
 4   5   arpa/inet.h
 4   6   net/if.h
 4   7   sys/mman.h
 4   8   signal.h
 5   5   netinet/in6.h
 5   5   sys/ioctl.h
 9   12  sys/param.h
 10  10  netinet/in.h
 15  16  sys/socket.h
 15  18  sys/time.h
 22  26  fcntl.h
 30  32  sys/stat.h
 30  41  sys/types.h
 58  65  unistd.h
 }}}

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

Re: [tor-bugs] #31464 [Applications/Tor Browser]: meek and moat are broken on macOS 10.9 with the switch to Go 1.12

[Tor Bug Tracker & Wiki]

#31464: meek and moat are broken on macOS 10.9 with the switch to Go 1.12
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, meek |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:2 dcf]:
 > I suppose this is a problem not only with the meek from meek.git, but
 also when using meek_lite with obfs4proxy (#29430)? Or does obfs4proxy
 somehow avoid using the problematic `_unlinkat` symbol? If the latter is
 the case, then #29430 would seem to solve it.

 In fact, obfs4proxy seems to avoid this problem. See 30126#comment:56

 > According to https://github.com/golang/go/wiki/Darwin, OS X 10.9 is not
 supported past Go 1.10.8.

 I guess we should try to support macOS 10.9.x as long as we can, but it
 may be a losing battle. And even though Mozilla still supports it for
 Firefox, we should not recommend it since 10.9 only rarely receives
 security updates from Apple.

 Georg, should we close this ticket since this issue seems to be resolved
 with Tor Browser 9.0a6 (after the switch to meek_lite)?

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

Re: [tor-bugs] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201909  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Replying to [comment:53 gk]:
 > Hrm, okay. Let's first test whether my signing attempts now succeed by
 following your instructions closer (I think I messed up the stapling at
 least yesterday) and appease our Gatekeeper:
 >
 > https://people.torproject.org/~gk/testbuilds/TorBrowser-9.0a6-osx64_en-
 US_30126.dmg
 > https://people.torproject.org/~gk/testbuilds/TorBrowser-9.0a6-osx64_en-
 US_30126.dmg.asc
 >
 > I then thought, testing with 8.5.5 as well because maybe the crash you
 saw is esr68-based. Here is the result:
 >
 > https://people.torproject.org/~gk/testbuilds/TorBrowser-8.5.5-osx64_en-
 US_30126.dmg
 > https://people.torproject.org/~gk/testbuilds/TorBrowser-8.5.5-osx64_en-
 US_30126.dmg.asc

 Both of these builds work fine on both 10.15 beta 7 and 10.14.6. Even the
 `TorBrowser-Data` weirdness and content process crashes have disappeared.

 Kathy and I also tested the 9.0a6 build on macOS 10.9.x and confirmed that
 the #31464 problem is gone too.  Good news all the way around!

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

[tor-bugs] #31698 [Core Tor/Tor]: Reconsider HAVE_XXX_H usage in the Tor code

[Tor Bug Tracker & Wiki]

#31698: Reconsider HAVE_XXX_H usage in the Tor code
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We currently sometimes have code like:

 {{{
 #ifdef HAVE_STRING_H
 #  include 
 #endif
 }}}

 But we don't expect to work on systems that do not have, for example,
 string.h available. We should not do these check in every .c and .h file,
 but instead just have our configure script fail if these headers are not
 available.

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

Re: [tor-bugs] #31696 [Core Tor/Tor]: Assertion failure in map-anon.c:218

[Tor Bug Tracker & Wiki]

#31696: Assertion failure in map-anon.c:218
-+-
 Reporter:  gk   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  regression crash 041-regression  |  Actual Points:  .1
  BugSmashFund 042-must dgoulet-merge|
Parent ID:   | Points:  .1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression crash 041-regression BugSmashFund 042-must =>
 regression crash 041-regression BugSmashFund 042-must dgoulet-merge


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

Re: [tor-bugs] #31570 [Core Tor/Tor]: INTERNAL ERROR: raw assertion failed (core dump) in termux

[Tor Bug Tracker & Wiki]

#31570: INTERNAL ERROR: raw assertion failed (core dump) in termux
-+-
 Reporter:  foremtehan   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  042-should, regression?, mmap,   |  Actual Points:  .1
  android, crash BugSmashFund dgoulet-merge  |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:  042-should, regression?, mmap, android, crash BugSmashFund =>
 042-should, regression?, mmap, android, crash BugSmashFund dgoulet-
 merge


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

Re: [tor-bugs] #31696 [Core Tor/Tor]: Assertion failure in map-anon.c:218

[Tor Bug Tracker & Wiki]

#31696: Assertion failure in map-anon.c:218
-+-
 Reporter:  gk   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  regression crash 041-regression  |  Actual Points:  .1
  BugSmashFund 042-must  |
Parent ID:   | Points:  .1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Looks good. Again, unable to reproduce locally.

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

Re: [tor-bugs] #30857 [Internal Services/Services Admin Team]: migrate (some projects? everything?) from trac to gitlab

[Tor Bug Tracker & Wiki]

#30857: migrate (some projects? everything?) from trac to gitlab
-+-
 Reporter:  anarcat  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:  tickets-migration|  Actual Points:
Parent ID:  #29400   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 > Tickets will be imported by team/project. It will not work for us to
 have ALL trac tickets in one project in gitlab.

 I don't see why that has to be the case. We could (more!) easily import
 ''everything'' in a ''single'' project and then, '''post-import''', split
 tickets up between projects.

 '''Not''' doing so will make it '''impossible''' to fill that first
 requirement, as there will not be a stable URL on GitLab's side for ticket
 #1234 from Trac.

 > And that brings me the question on where are we going to have sysadmin
 tickets in gitlab? I was thinking as its own group in gitlab but you may
 have other idea for it.

 Sure, they can be moved to its own group after the import, like everything
 else.

 > Sorry that I was not clear. Any new ticket in gitlab will have a number
 that has not being assigned in trac yet. We preserve the number for
 tickets that already exist.

 Agreed, although you need to understand that ticket numbering is *per
 project* in GitLab. (Strictly speaking, that's also the case in Trac, but
 we have only a single project in Trac, while we already have multiple
 project in GitLab.)

 So in practice, we will have multiple #1234 tickets in GitLab. This is why
 we need to import everything in a single project at first so that we have
 consistent numbering. *Then* when we move issues around in GitLab, the
 numbers will change, but there will be a note in the "legacy" tickets
 pointing to the new one.

 I don't know how else you could implement those constraints otherwise.

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

Re: [tor-bugs] #31626 [Core Tor/Tor]: Move confparse.[ch] into lib/confmgt

[Tor Bug Tracker & Wiki]

#31626: Move confparse.[ch] into lib/confmgt
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  042-should|  Actual Points:
Parent ID:  #29211| Points:  0
 Reviewer:|Sponsor:  Sponsor31-can
--+

Comment (by nickm):

 Branch is `ticket31626`; PR at https://github.com/torproject/tor/pull/1319
 .  I'll wait for CI to pass before I put this in 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] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 Replying to [comment:42 JeremyRand]:
 > This issue is becoming confusing to follow due to the existence of two
 different patches (ARM target with x86 host, versus ARM target with ARM
 host).  May I request that this issue be split into 2 issues?  Both
 patches are independently useful, and I think they should both be merged
 when complete (regardless of which is completed first).  Having 2 separate
 issues for them makes it easier to follow the discussion, and allows the
 issues to be independently closed as fixed whenever the respective patches
 are merged.  (I don't particularly care which patch is assigned to a new
 issue, or if both patches are assigned to a new issue and this issue
 becomes a parent/metaissue.)

 That's a good point. I am fine either way. Maybe having this ticket a
 parent and the respective approaches child tickets seems to be the
 cleanest one?

 [snip]

 > I also now have an ESR 68 patch at https://notabug.org/JeremyRand/tor-
 browser-build/src/armhf-esr68-draft .  It doesn't build yet, and I suspect
 that rebasing it against a newer version of `tor-browser-build` master
 branch is likely to fix a lot of the build issues I'm running into.  I get
 the impression that `tor-browser-build` was in a pretty bad state at the
 point I rebased against, which was August 8.  (Georg, can you confirm that
 the August 8 version of `tor-browser-build` master branch is expected to
 have a lot of problems?)

 Yeah, sorry for the inconvenience. We were barely able to have everything
 ready for having some sort of nightly builds for Linux available at that
 time and just had switched over to esr68. `master` should be in much
 better shape now than it had been at that time.

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

Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

[Tor Bug Tracker & Wiki]

#12631: Tor Browser for ARM architecture
---+---
 Reporter:  mttp   |  Owner:  (none)
 Type:  project| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201904  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by JeremyRand):

 Correction: ESR 68 patch is at https://notabug.org/JeremyRand/tor-browser-
 build/src/armhf-esr68 (`armhf-esr68` branch).  The `armhf-esr68-draft`
 branch I linked earlier is unstable and may contain untested 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] #31696 [Core Tor/Tor]: Assertion failure in map-anon.c:218

[Tor Bug Tracker & Wiki]

#31696: Assertion failure in map-anon.c:218
-+-
 Reporter:  gk   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  regression crash 041-regression  |  Actual Points:  .1
  BugSmashFund 042-must  |
Parent ID:   | Points:  .1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 CI has passed.

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

Re: [tor-bugs] #31651 [Metrics/Library]: Release metrics-lib 2.7.0

[Tor Bug Tracker & Wiki]

#31651: Release metrics-lib 2.7.0
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 As discussed via email we're dropping the review step for releases in
 order to speed up the release process.

 Release: https://dist.torproject.org/metrics-lib/2.7.0/

 Closing.

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