Re: [tor-bugs] #29310 [Core Tor/Tor]: control-spec: "limits/max-mem-in-queues" appears to be undocumented

[Tor Bug Tracker & Wiki]

#29310: control-spec: "limits/max-mem-in-queues" appears to be undocumented
-+
 Reporter:  nusenu   |  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, 041-should  |  Actual Points:  0
Parent ID:   | Points:  0
 Reviewer:  mikeperry|Sponsor:
-+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 lgtm

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

Re: [tor-bugs] #22619 [Core Tor/Tor]: SessionGroup = Reading config failed

[Tor Bug Tracker & Wiki]

#22619: SessionGroup = Reading config failed
-+-
 Reporter:  acceleraTor  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  SessionGroup configuration   |  Actual Points:  0
  SocksPort option 032-unreached 035-backport|
  040-backport 041-can   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 This looks fine; sorry for the delay.

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

Re: [tor-bugs] #21235 [Internal Services/Services Admin Team]: Try dividing up services by vegas teams

[Tor Bug Tracker & Wiki]

#21235: Try dividing up services by vegas teams
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * cc: anarcat (added)


Comment:

 cc'ing Anarcat so he can follow along too. Maybe this ticket is even
 redundant, now, with some more recent initiatives?

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

Re: [tor-bugs] #21235 [Internal Services/Services Admin Team]: Try dividing up services by vegas teams

[Tor Bug Tracker & Wiki]

#21235: Try dividing up services by vegas teams
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * component:  Internal Services => Internal Services/Services Admin Team


Comment:

 note that this ticket isn't about the support wiki -- it is about becoming
 more organized about who is 'in charge of' each service, and getting
 better at noticing services that have fallen through the cracks and
 finding them a home.

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

Re: [tor-bugs] #23007 [Webpages/Blog]: Get a second blog maintainer

[Tor Bug Tracker & Wiki]

#23007: Get a second blog maintainer
---+--
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * cc: anarcat (added)


Comment:

 cc'ing Anarcat so he can know about this ticket (and its goal) 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] #24956 [Community/Outreach]: put labs.tp.o on hiatus?

[Tor Bug Tracker & Wiki]

#24956: put labs.tp.o on hiatus?
+---
 Reporter:  arma|  Owner:  mikeperry
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by arma):

 * cc: anarcat (added)


Comment:

 Looks like labs.torproject.org doesn't ping. And the IP address doesn't
 reverse-resolve to anything.

 Does that mean we closed down the machine?

 Or does it mean we lost track of it and somebody is still paying for a
 machine that isn't on anymore? :)

 cc'ing Anarcat so he can follow along.

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

Re: [tor-bugs] #24956 [Internal Services/Tor Sysadmin Team]: put labs.tp.o on hiatus?

[Tor Bug Tracker & Wiki]

#24956: put labs.tp.o on hiatus?
-+-
 Reporter:  arma |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * component:  Community/Outreach => Internal Services/Tor Sysadmin Team


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

[tor-bugs] #30819 [- Select a component]: tour packages

[Tor Bug Tracker & Wiki]

#30819: tour packages
---+--
 Reporter:  jeslyjosetourpackages  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  - Select a component
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Everybody wishes to spend some good time with our friends and
 relatives.Going out for a tour helps in increasing the bond between our
 friends and relatives. Tourism industry is one of the fast growing
 industry in the world. There are many types of tourist activities now
 available. https://www.fundayholidays.com/   Many tourist activities like
 echo tourism , Ayurveda tourism etc are now available.  Kerala is the
 center for many tourist activities. Every year thousands of people are
 visiting this area to enjoy various tourist activities in Kerala.  Touring
 with your friends and relatives is a best method to get relaxed and to
 feel great.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30818 [- Select a component]: tour packages

[Tor Bug Tracker & Wiki]

#30818: tour packages
---+--
 Reporter:  jeslyjosetourpackages  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  - Select a component
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Everybody wishes to spend some good time with our friends and
 relatives.Going out for a tour helps in increasing the bond between our
 friends and relatives. Tourism industry is one of the fast growing
 industry in the world. There are many types of tourist activities now
 available. [kerala holiday packages](https://www.fundayholidays.com/)
 Many tourist activities like echo tourism , Ayurveda tourism etc are now
 available.  Kerala is the center for many tourist activities. Every year
 thousands of people are  visiting this area to enjoy various tourist
 activities in Kerala.  Touring with your friends and relatives is a best
 method to get relaxed and to feel great.

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

Re: [tor-bugs] #30784 [Core Tor/Tor]: Windows put its timeval definitions in winsock2.h

[Tor Bug Tracker & Wiki]

#30784: Windows put its timeval definitions in winsock2.h
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  041-should, windows, compilation-|  Actual Points:
  error, 029-backport-maybe, 034-backport,   |
  035-backport, 040-backport |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by saurik):

 So, I'm the reason this ticket exists (having filed a pull request on
 GitHub), and I've now spent some more time trying to figure out why this
 would work for you but not for me; I had originally thought it was because
 I was using MinGW (and so tend to run into issues with subtle differences
 in header files), but when I saw your CI system was using MinGW I figured
 I should dig deeper... and I tracked it down to my toolchain setup
 (incorrectly) having hardcoded WIN32_LEAN_AND_MEAN, which meant that the
 #include you already have for  wasn't sufficient, but it should
 have been, so I'm sorry: you can just close this ticket as invalid.
 (Again: sorry.)

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #27435, #23620, #23863, #24654, ...

[Tor Bug Tracker & Wiki]

Batch modification to #27435, #23620, #23863, #24654, #25347, #30746 by teor:


Comment:
#16844 and #21969 have conflicting goals, so we need to write a proposal that 
balances these goals. See #30817.

--
Tickets URL: 

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-guard, tor-  |  Actual Points:
  bridge, tor-client, tbb-usability-website, |
  tbb-needs, 034-triage-20180328,|
  034-removed-20180328   |
Parent ID:  #30817   | Points:  1.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-guard, tor-bridge, tor-client, tbb-usability-website, tbb-needs,
 034-triage-20180328, 034-removed-20180328
 =>
 needs-proposal, tor-guard, tor-bridge, tor-client, tbb-usability-
 website, tbb-needs, 034-triage-20180328, 034-removed-20180328
 * parent:   => #30817


Comment:

 #16844 and #21969 have conflicting goals, so we need to write a proposal
 that balances these goals. See #30817.

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

Re: [tor-bugs] #16844 [Core Tor/Tor]: Slow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting

[Tor Bug Tracker & Wiki]

#16844: Slow clients can't bootstrap because they expire their consensus fetch 
but
then receive all the bytes from it anyway, making them expire their next
fetch, putting them in a terrible loop
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-client, low- |  Actual Points:
  bandwidth, sponsor4, bootstrap, 032-unreached  |
Parent ID:  #30817   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by teor):

 * keywords:  tor-client, low-bandwidth, sponsor4, bootstrap, 032-unreached
 =>
 needs-proposal, tor-client, low-bandwidth, sponsor4, bootstrap,
 032-unreached
 * parent:   => #30817


Comment:

 #16844 and #29729 have conflicting goals, so we need to write a proposal
 that balances these goals. See #30817.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30817 [Core Tor/Tor]: Write a proposal for tor bootstrapping that works on slow links, but avoids slow relays

[Tor Bug Tracker & Wiki]

#30817: Write a proposal for tor bootstrapping that works on slow links, but 
avoids
slow relays
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  tor-bootstrap
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+--
 In #16844, clients on slow links time out before they can download a full
 consensus

 In #21969 and children, relays fail to bootstrap because a directory
 authority limits DirPort download speeds (a similar bug exists for clients
 which try slow relays)

 We need to redesign tor's bootstrap so that tor works when the link is
 slow, but tries another relay when the relay is slow.

 We should implement multiple concurrent downloads for all directory
 documents, not just consensuses. Once we have multiple concurrent
 downloads, we can increase the timeouts substantially.

 We should limit the number of concurrent downloads to 3, because if 3 fast
 relays are all slow, it's probably the link that it slow. And a 3x
 download size is an acceptable cost. (It probably won't be that bad,
 because we delay starting the 2nd and 3rd fetches, and terminate them when
 the first one completes.)

 We could also be a bit more clever, and terminate the download that would
 take the longest time to finish, after a soft timeout. And then reduce the
 number of concurrent downloads by one.

 We could also simplify the relay/authority selection logic:
 * relays try authorities first, then after a delay, they try other relays
 (most relays are directory mirrors, so they do this anyway)
 * clients try relays first, then after a delay, they try authorities

 And simplify the ORPort/DirPort selection logic for directory downloads:
 * clients always download via ORPorts on relays and authorities, for
 security
 * relays always download via DirPorts on authorities, to avoid SSL CPU
 load on a small number of machines
 * relays always download via ORPorts on other relays, for security (CPU
 load doesn't matter that much)

 We could design a new directory download module to implement this logic,
 using pieces of the existing modules, but with a cleaner, high-level
 interface:
 * request a download of a particular directory document, or set of
 directory documents
 * pass a download configuration with:
   * an optional directory cache,
   * ORPort / DirPort preference,
   * number of permitted concurrent connections,
   * relay and authority initial delays,
   * status and completion handlers.

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

Re: [tor-bugs] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

[Tor Bug Tracker & Wiki]

#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance, 035-roadmap-master, 035  |
  -triaged-in-20180711   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * cc: neel (added)


Comment:

 Is any work being done on this? Do we require Rust support before work can
 start?

 I'd love to have multicore relays as well (for my home server hosted on
 residential FTTH).

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

Re: [tor-bugs] #28290 [Applications/Tor Browser]: Don't allow fingerprinting via navigator.userAgent

[Tor Bug Tracker & Wiki]

#28290: Don't allow fingerprinting via navigator.userAgent
-+-
 Reporter:  indigotime   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os, user- |  Actual Points:
  feedback, blog |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 @gk: FYI: upstream https://bugzilla.mozilla.org/show_bug.cgi?id=1556223

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:10 nickm]:
 > My branch `chutney-obfs4` now supports obfs4 as well.  PR at
 https://github.com/torproject/chutney/pull/29 .

 Looks good to me, I had a few minor comments and questions.
 I haven't run it yet.

 > There will be some followup work here to improve test-network.sh, to
 document all of this better, and to support more PTs, and to make it work
 with #30459.

 Did you want to make those changes in this ticket, or open another ticket?

 > To start this network yourself, run these:
 > {{{
 > # configure and launch everything except the bridge client
 > CHUTNEY_CONFIG_PHASE=1 ./chutney configure networks/bridges-obfs4
 > CHUTNEY_LAUNCH_PHASE=1 ./chutney start networks/bridges-obfs4
 > # wait a moment for the PT to launch
 > sleep 2
 > # configure and launch the bridge client.
 > CHUTNEY_CONFIG_PHASE=2 ./chutney configure networks/bridges-obfs4
 > CHUTNEY_LAUNCH_PHASE=2 ./chutney start networks/bridges-obfs4
 > }}}
 >
 > As noted above, this happens in two phases because the bridge line can't
 be constructed until the bridge and its PT are running.

 I wonder if we could expose a better interface to two-phase launches. I
 guess we can do that in test-network.sh.

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

Re: [tor-bugs] #30459 [Core Tor/Chutney]: Let chutney tell Tor whether a network is supported

[Tor Bug Tracker & Wiki]

#30459: Let chutney tell Tor whether a network is supported
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 041-accepted-20190115,   |  Actual Points:  1
  network-team-roadmap-2019-Q1Q2, tor-ci,|
  041-deferred-20190530  |
Parent ID:  #29024   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Looks good to me, but I have a few questions about the details.

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

Re: [tor-bugs] #30816 [Core Tor/Tor]: Remove ping ::1 from tor's test-network-all and simplify the logic

[Tor Bug Tracker & Wiki]

#30816: Remove ping ::1 from tor's test-network-all and simplify the logic
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, simplify, network-team-|  Actual Points:
  roadmap-2019-Q1Q2, tor-ci  |
Parent ID:  #30459   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * points:   => 1


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

[tor-bugs] #30816 [Core Tor/Tor]: Remove ping ::1 from tor's test-network-all and simplify the logic

[Tor Bug Tracker & Wiki]

#30816: Remove ping ::1 from tor's test-network-all and simplify the logic
-+-
 Reporter:  teor |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  refactor, simplify, network-team-
 Severity:  Normal   |  roadmap-2019-Q1Q2, tor-ci
Actual Points:   |  Parent ID:  #30459
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor31-can  |
-+-
 After #30459 is merged into chutney, and everyone updates, we can remove
 the complicated checks for IPv6 from tor's test-network-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] #29729 [Core Tor/Chutney]: Work out which networks to run in Chutney's CI

[Tor Bug Tracker & Wiki]

#29729: Work out which networks to run in Chutney's CI
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  chutney-ci, network-team-|  Actual Points:  3
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  Sponsor19
-+-

Comment (by teor):

 I'm going to merge #29729 soon, so we can merge #29024 and #30459.

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

Re: [tor-bugs] #29280 [Core Tor/Tor]: Use Chutney in Tor's CI

[Tor Bug Tracker & Wiki]

#29280: Use Chutney in Tor's CI
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  CI, PTs, 029-backport,   |  Actual Points:  1
  034-backport, 035-backport, 040-backport,  |
  network-team-roadmap-2019-Q1Q2, reviewer-was-  |
  teor-20190422, tor-ci, 041-deferred-20190530   |
Parent ID:  #29267   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-

Comment (by teor):

 Hi nickm, would you like to do the revisions in comments 16 and 17, or
 would you like me to do them?

 I'm going to merge #29729 soon, so we can merge #29024 and #30459.

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

Re: [tor-bugs] #30630 [Core Tor/Tor]: Put CI URLs in ReleasingTor.md

[Tor Bug Tracker & Wiki]

#30630: Put CI URLs in ReleasingTor.md
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, doc, 041-can  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  teor|Sponsor:  Sponsor31-can
+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks good, 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] #27530 [Core Tor/Tor]: Configure: Use AC_TRY_RUN() to check that --enable-gcc-hardening works

[Tor Bug Tracker & Wiki]

#27530: Configure: Use AC_TRY_RUN() to check that --enable-gcc-hardening works
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, postfreeze-ok, 041-can,|  Actual Points:  .1
  041-should |
Parent ID:  #28611   | Points:  .2
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

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

Re: [tor-bugs] #30279 [Core Tor/Chutney]: Test IPv6-only v3 onion services in Chutney's CI, once tor master supports them

[Tor Bug Tracker & Wiki]

#30279: Test IPv6-only v3 onion services in Chutney's CI, once tor master 
supports
them
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, ipv6, single-onion, fast-|  Actual Points:  0.1
  fix, chutney-ci, network-team- |
  roadmap-2019-Q1Q2, 041-deferred-20190530   |
Parent ID:  #29729   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor19-can
-+-
Changes (by teor):

 * reviewer:   => nickm


Comment:

 I wrote this ticket, so nickm should review 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] #25632 [Core Tor/Stem]: Improve stem torrc logging options for integration testing

[Tor Bug Tracker & Wiki]

#25632: Improve stem torrc logging options for integration testing
---+--
 Reporter:  dmr|  Owner:  atagar
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  testing easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

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


Comment:

 No, these changes are still useful.

 I'm not sure what we want to do about ProtocolWarnings, but having them in
 the logs or console output would be helpful.

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

Re: [tor-bugs] #16844 [Core Tor/Tor]: Slow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting

[Tor Bug Tracker & Wiki]

#16844: Slow clients can't bootstrap because they expire their consensus fetch 
but
then receive all the bytes from it anyway, making them expire their next
fetch, putting them in a terrible loop
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, low-bandwidth,   |  Actual Points:
  sponsor4, bootstrap, 032-unreached |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by teor):

 Replying to [comment:35 arma]:
 > Still an important ticket! Real users are getting hurt by this.

 If you think we should fix this ticket, please:
 * work out which sponsor can fund this ticket, assign it to that sponsor,
 and ask Gaba to put it on the roadmap, or
 * ask Gaba to put it on the roadmap as unfunded work

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: SBWS does not detect changes in max advertised bandwidth

[Tor Bug Tracker & Wiki]

#30733: SBWS does not detect changes in max advertised bandwidth
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Our acceptance criteria for sbws is a 50% variance from the consensus,
 because that's what torflow's variance was before we started deploying
 sbws. See #27339.

 Replying to [comment:9 starlight]:
 > Defect is extremely severe.  SBWS should be removed from production
 until this is fixed.

 This defect has a limited impact. So we won't remove sbws from production.

 > Longclaw has thirteen percent of listed relays with incorrect descriptor
 information more than 7% away from the published consensus.

 Why pick 7%?

 The total consensus weight of the bandwidth authorities now varies by up
 to +43%, -14% from the consensus.
 https://metrics.torproject.org/totalcw.html

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: SBWS does not detect changes in max advertised bandwidth (was: SBWS does not detect some changes in max advertised bandwidth)

[Tor Bug Tracker & Wiki]

#30733: SBWS does not detect changes in max advertised bandwidth
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

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

[tor-bugs] #30815 [Applications/Tor Browser]: Mouse scrolling bookmarks list from menu

[Tor Bug Tracker & Wiki]

#30815: Mouse scrolling bookmarks list from menu
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor
 |  Browser
  Version:  Tor: unspecified |   Severity:  Normal
 Keywords:  bookmarks list, mouse-   |  Actual Points:
  scroll, scroll, faster |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Used to be able to use mouse-scroll to quickly scroll through the
 bookmarks. This was a useful function because it allowed me to quickly get
 down the bookmark list without having to open "show all bookmarks". Why
 was it removed? Can we get it back?

 This is on latest "Extended Support Release 8.5.1 based on Firefox
 60.7.0esr x64".

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

Re: [tor-bugs] #28556 [Applications/Tor Browser]: Detect other installed circumvention tools and offer them as transports

[Tor Bug Tracker & Wiki]

#28556: Detect other installed circumvention tools and offer them as transports
+--
 Reporter:  arma|  Owner:  tbb-team
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, tor-pt, ex-sponsor-19  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  Sponsor30-can
+--

Comment (by arma):

 Somebody put up a video of how to hook Tor Browser up to ShadowsocksR:
 https://www.youtube.com/watch?v=VRGZ4dOYv1Q
 https://lists.torproject.org/pipermail/anti-censorship-
 team/2019-June/19.html

 This seems like a good example to team up better between these two apps.

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

Re: [tor-bugs] #16844 [Core Tor/Tor]: Slow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting

[Tor Bug Tracker & Wiki]

#16844: Slow clients can't bootstrap because they expire their consensus fetch 
but
then receive all the bytes from it anyway, making them expire their next
fetch, putting them in a terrible loop
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, low-bandwidth,   |  Actual Points:
  sponsor4, bootstrap, 032-unreached |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by arma):

 Still an important ticket! Real users are getting hurt by 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] #30814 [Applications/Tor Browser]: Consider resetting security.enable_tls_session_tickets

[Tor Bug Tracker & Wiki]

#30814: Consider resetting security.enable_tls_session_tickets
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by acat):

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


Comment:

 Sorry, now I saw that the pref does not have any effect anymore, so this
 is not strictly needed. I think it's not worth adding code just to reset
 this unused pref, so closing 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

[tor-bugs] #30814 [Applications/Tor Browser]: Consider resetting security.enable_tls_session_tickets

[Tor Bug Tracker & Wiki]

#30814: Consider resetting security.enable_tls_session_tickets
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Taking a look at #28746 I realized `torbutton_update_isolation_prefs()`
 still sets `security.enable_tls_session_tickets = !isolate`. This should
 have been removed in #17252. For users which never played with
 `privacy.firstparty.isolate` this will still have the default value, but
 at least in my browser tls session tickets were disabled. I guess it might
 be the same for other developers/advanced users.

 I don't see a way of knowing whether `security.enable_tls_session_tickets
 = false` was set manually by the user or by `torbutton`. But I think we
 should consider resetting the pref to the default value to enable tls
 session tickets for all users.

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

Re: [tor-bugs] #30813 [Core Tor/Tor]: Fails to build with the latest libevent-2.1.10: Undefined symbol "evutil_secure_rng_add_bytes"

[Tor Bug Tracker & Wiki]

#30813: Fails to build with the latest libevent-2.1.10: Undefined symbol
"evutil_secure_rng_add_bytes"
--+---
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

 * status:  new => closed
 * resolution:   => not a bug
 * component:  - Select a component => Core Tor/Tor


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

Re: [tor-bugs] #30813 [Core Tor/Tor]: Fails to build with the latest libevent-2.1.10: Undefined symbol "evutil_secure_rng_add_bytes"

[Tor Bug Tracker & Wiki]

#30813: Fails to build with the latest libevent-2.1.10: Undefined symbol
"evutil_secure_rng_add_bytes"
--+---
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 (glad you got it working!)

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

Re: [tor-bugs] #29697 [Internal Services]: archive.tpo is soon running out of space

[Tor Bug Tracker & Wiki]

#29697: archive.tpo is soon running out of space
---+--
 Reporter:  boklm  |  Owner:  anarcat
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:5 anarcat]:
 > If git-annex is too complicated, we can talk to IA directly. I would
 recommend, however, against using their web-based upload interface which,
 even they acknowledge, is terrible and barely useable. I packaged the
 [https://tracker.debian.org/pkg/python-internetarchive internetarchive]
 python client in Debian to work around that problem and it works much
 better.
 >
 > Moving files to IA only shifts the problem, in my opinion: then we have
 only a single copy, elsewhere and while we don't need to manage that space
 anymore, we also don't manage backups and will never know if they drop
 stuff on us (and they do, sometimes, either deliberately or by mistake). I
 would propose that if stuff moves out of our "backed-up" infrastructure,
 it should be stored in at least two administratively distinct locations.

 Recently I had the idea to archive some early flash proxy/pyobfsproxy
 browser bundles from circa 2013--some of them were only ever present under
 !https://people.torproject.org/~dcf/ and so what I have locally is a
 superset of what's at archive.torproject.org (for this specific group of
 packages). The problem I'm encountering with IA is the automatic malware
 scan--as soon as I upload a self-extracting Windows .exe package, the
 virus scan returns positive and automatically darks (hides) the entire
 item. Here are some attempted uploads that got darked:
  * https://archive.org/details/tor-flashproxy-browser-2.4.6-alpha-1
  * https://archive.org/details/tor-flashproxy-browser-2.4.6-alpha-2
  * https://archive.org/details/tor-flashproxy-pyobfsproxy-
 browser-2.4.7-alpha-1
 Here's a
 
[https://www.virustotal.com/gui/file/358c6b2b96ad4d8137a835b987a6a0bc7ab85f5b8a010863e101a7f2a40c74f4/detection
 sample report] from the upload log. Notice some of the matches say
 "Not-a-virus" and are simply reporting the presence of tor, but it's
 enough to fail the IA check.
  * Kaspersky: Not-a-virus:NetTool.Win32.Tor.k
  * Qihoo-360: Win32/Virus.NetTool.c06
  * Microsoft: PUA:Win32/Presenoker
  * ZoneAlarm by Check Point: Not-a-virus:NetTool.Win32.Tor.k
 It seems that I can avoid the virus check by structuring the uploads:
 upload all files except the .exe, let them be virus scanned, then upload
 the .exe. The upload log says "item already had a curatenote indicating it
 had been checked, no need to update" and the item remains undarked. But
 this is no solution; besides being an apparent bug in the malware scanning
 system, it'll only work until the next time someone runs a batch scan or
 something, and then the items will disappear. For the sake of example,
 here are items I managed to upload in that way:
  * https://archive.org/details/tor-flashproxy-pyobfsproxy-
 browser-2.4.7-test-1
  * https://archive.org/details/tor-pluggable-transports-
 browser-2.4.11-alpha-1
 TL;DR: archiving at IA will probably require talking to someone there and
 getting them to make a special collection for us with
 [https://archive.org/services/docs/api/metadata-
 schema/index.html#viruscheck viruscheck] disabled.

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: SBWS ceases import of changes in descriptor bandwidth values (was: SBWS does not detect some changes in max advertised bandwidth)

[Tor Bug Tracker & Wiki]

#30733: SBWS ceases import of changes in descriptor bandwidth values
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  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] #30733 [Core Tor/sbws]: SBWS does not detect some changes in max advertised bandwidth

[Tor Bug Tracker & Wiki]

#30733: SBWS does not detect some changes in max advertised bandwidth
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by starlight):

 correction:  neglected to take absolute value of the difference, longclaw
 has 33% of relays more than 7% away from the consensus.

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: SBWS does not detect some changes in max advertised bandwidth

[Tor Bug Tracker & Wiki]

#30733: SBWS does not detect some changes in max advertised bandwidth
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by starlight):

 * Attachment "sbws_longclaw_30733_fail.txt" added.

 list of relays where longclaw descriptor differs more than 7% from
 consensus

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: SBWS does not detect some changes in max advertised bandwidth

[Tor Bug Tracker & Wiki]

#30733: SBWS does not detect some changes in max advertised bandwidth
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by starlight):

 * Attachment "sbws_longclaw_30733_fail.txt" added.

 list of relays where longclaw descriptor differs more than 7% from
 consensus

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: SBWS does not detect some changes in max advertised bandwidth

[Tor Bug Tracker & Wiki]

#30733: SBWS does not detect some changes in max advertised bandwidth
---+---
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Critical   | Resolution:
 Keywords:  sbws-majority-blocker  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by starlight):

 Defect is extremely severe.  SBWS should be removed from production until
 this is fixed.  Longclaw has thirteen percent of listed relays with
 incorrect descriptor information more than 7% away from the published
 consensus.

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

Re: [tor-bugs] #30813 [- Select a component]: Fails to build with the latest libevent-2.1.10: Undefined symbol "evutil_secure_rng_add_bytes"

[Tor Bug Tracker & Wiki]

#30813: Fails to build with the latest libevent-2.1.10: Undefined symbol
"evutil_secure_rng_add_bytes"
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yurivict271):

 Sorry, this was something related to the system update on FreeBSD, which
 now has been resolved.

 Please close this ticket.

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

Re: [tor-bugs] #29533 [Core Tor/Tor]: Lint all our shell scripts with shellcheck on CI

[Tor Bug Tracker & Wiki]

#29533: Lint all our shell scripts with shellcheck on CI
--+--
 Reporter:  rl1987|  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by rl1987):

 * status:  new => needs_review


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30813 [- Select a component]: Fails to build with the latest libevent-2.1.10: Undefined symbol "evutil_secure_rng_add_bytes"

[Tor Bug Tracker & Wiki]

#30813: Fails to build with the latest libevent-2.1.10: Undefined symbol
"evutil_secure_rng_add_bytes"
-+--
 Reporter:  yurivict271  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Undefined symbol "evutil_secure_rng_add_bytes"

 See the FreeBSD bug report:
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238433

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

Re: [tor-bugs] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling it

[Tor Bug Tracker & Wiki]

#10760: Integrate TorButton to TorBrowser core to prevent users from disabling 
it
-+-
 Reporter:  Rezonansowy  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-parity,|  Actual Points:
  TorBrowserTeam201905, GeorgKoppen201905, ux-   |
  team, TorBrowserTeam201906R|
Parent ID:  #24855   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_information => new


Comment:

 Replying to [comment:53 acat]:

 [snip]

 > Should we do the review of this in #30429 or here? And should we wait
 for reviewing until the next steps of this torbutton integration are done?
 (moving current torbutton code to tor-browser, refactoring, etc.)?

 I think we should do the review here as #30429 is for all the things
 rebased and the Torbutton patches are not rebased but new. And, no, please
 move ahead full steam while I try to review things. You could probably
 start with just removing code not needed anymore before starting tighter
 integration of the parts we want to keep and exposing functionality in a
 new way (like the new New Identity button instead of the onion button on
 the toolbar)

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

Re: [tor-bugs] #11506 [Applications/Tor Browser]: Users are confused by the 2000-01-01 00:00 UTC timestamp

[Tor Bug Tracker & Wiki]

#11506: Users are confused by the 2000-01-01 00:00 UTC timestamp
-+-
 Reporter:  lunar|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-helpdesk-frequent,   |  Actual Points:
  TorBrowserTeam201601, GeorgKoppen201601, tbb-  |
  rbm, AffectsTails  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: intrigeri (added)
 * keywords:
 tbb-helpdesk-frequent, TorBrowserTeam201601, GeorgKoppen201601, tbb-
 rbm
 =>
 tbb-helpdesk-frequent, TorBrowserTeam201601, GeorgKoppen201601, tbb-
 rbm, AffectsTails


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

Re: [tor-bugs] #30810 [Applications/Tor Browser]: about:addons says that NoScript was last updated on Jan 1, 2000 ⇒ user confusion

[Tor Bug Tracker & Wiki]

#30810: about:addons says that NoScript was last updated on Jan 1, 2000 ⇒ user
confusion
--+---
 Reporter:  intrigeri |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  AffectsTails  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Yes, we should do that at some point, see #23559 and #11506. Duping this
 over to the last one.

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

Re: [tor-bugs] #30657 [Applications/Tor Browser]: Tor Browser locale is leaked via title of link tag on non-html page

[Tor Bug Tracker & Wiki]

#30657: Tor Browser locale is leaked via title of link tag on non-html page
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-locale, ff68  |  Actual Points:
  -esr-will-have |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-fingerprinting-locale => tbb-fingerprinting-locale, ff68
 -esr-will-have


Comment:

 Replying to [comment:2 Thorin]:
 > FWIW: this behavior (or at least the PoC) stopped working as of FF68+,
 so you should be good to go in the next ESR cycle. It returns a blank.

 Interesting, I wonder what bugfix on Mozilla's side is responsible for
 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