Re: [tor-bugs] #24633 [Core Tor/Tor]: to->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。

[Tor Bug Tracker & Wiki]

#24633: to->pending->tqh_last is 0x。
-+-
 Reporter:  sx5486510|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  msvc 029-backport 030-backport   |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sx5486510):

 It works!  thx bro!

 Replying to [comment:8 nickm]:
 > If you can test (running the bitops tests and running tor) using the
 patch here, that would be confirmation that the approach works:
 >
 > {{{
 > diff --git a/src/ext/timeouts/timeout-bitops.c b/src/ext/timeouts
 /timeout-bitops.c
 > index a018f33b958500..45466f6cb313ca 100644
 > --- a/src/ext/timeouts/timeout-bitops.c
 > +++ b/src/ext/timeouts/timeout-bitops.c
 > @@ -40,7 +40,7 @@ static __inline int clz32(unsigned long val)
 >  {
 > DWORD zeros = 0;
 > _BitScanReverse(, val);
 > -   return zeros;
 > +   return 31 - zeros;
 >  }
 >  #ifdef _WIN64
 >  /* According to the documentation, these only exist on Win64. */
 > @@ -54,7 +54,7 @@ static __inline int clz64(uint64_t val)
 >  {
 > DWORD zeros = 0;
 > _BitScanReverse64(, val);
 > -   return zeros;
 > +   return 63 - zeros;
 >  }
 >  #else
 >  static __inline int ctz64(uint64_t val)
 > }}}
 >
 > Also available in my public git repo in a branch called `bug24633_029`.

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

Re: [tor-bugs] #24665 [Core Tor/Tor]: sched: In KIST, the extra_space kernel value needs to be allowed to be negative

[Tor Bug Tracker & Wiki]

#24665: sched: In KIST, the extra_space kernel value needs to be allowed to be
negative
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 Replying to [comment:3 dgoulet]:
 > Replying to [comment:2 yawning]:
 > > The branch looks sensible to me.
 > >
 > > My inner pedant will say that "If a connection to a relay was
 unreliable meaning tor was struggling to flush bytes towards the relay" is
 misleading at best, since the congestion window shrinking (by quite a bit)
 is an expected part of how TCP/IP works and not particularly indicative of
 an overloaded condition on it's own.
 >
 > Ah I think I failed to explain my comment correctly. The point of that
 line was a reason for KIST to actually consider the `notsent` queue size
 *because* it could be that the connection is struggling towards the relay.
 >
 > How would you phrase it in a proper English?

 "The KIST scheduler did not correctly account for data already enqueued in
 each connection's send socket buffer, particularly in cases when the
 TCP/IP congestion window was reduced between scheduler calls.  This
 situation lead to excessive per-connection buffering in the kernel, and a
 potential memory DoS.  Fixes bug 24665; bugfix on 0.3.2.1-alpha."

 Maybe not human friendly enough.

 > > While you're here, assuming the scheduler is called significantly
 faster than the RTT of most links (read that as "If 10 ms is lower than
 the RTT of most if not all links"), you can/should reduce
 `sock_buf_size_factor` as well, because you aren't going to get a full
 congestion window worth of ACKs back between scheduler calls in common
 cases.
 >
 > Interesting... if the channel is quite active, yes the scheduler tick
 for it should be 10ms.
 >
 > What is a reasonable size factor in your opinion? It seems we can get
 some RTT information with the `getsockopt()` call within `struct
 tcp_info`, maybe we could adjust a scaling factor based on those values?
 (If that is an idea, we should open a ticket to make way for this one to
 be merged)

 There isn't a good "one size fits all" solution.  Setting it too low will
 gimp performance on fast low latency links, setting it too high right now
 bloats the various buffers.  I would personally opt more toward avoiding
 the latter given all the Fun that's happening.

 As you noted, `tcpi_rtt` gives the smoothed RTT estimate (and
 `tcpi_rttvar` the RTT variance if you need it), which is probably
 sufficient to give a better reasonable guess here, as a first pass, I
 would recommend doing something based on the the scheduler interval to
 smoothed RTT ratio, with a hard maximum at `1.0`, but as you noted this is
 probably best discussed in a separate 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] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc, man  |  Actual Points:
Parent ID:  #24497| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 the changes file says:
 > Document in **more** places...

 That was not documented / was not a requirement before, right? So the
 changes file could say something like the following?

 Documentation:
  - Operators running multiple relays or bridges are required to set
 ContactInfo.
  - Operators running multiple relays are required to set a proper (mutual)
 MyFamily.


 I'm also no longer convinced we should make any distinction between single
 relay and group relay operator.

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc, man  |  Actual Points:
Parent ID:  #24497| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Thanks for making it even more clear and adding it to MyFamily as well!

 > MyFamily MUST be set if you run more than one relay or bridge.

 Maybe we should make it clear that it is not enough to just set it but to
 also be a proper (mutual) MyFamily?
 I removed " or bridge." since the man page also says: "Do not list any
 bridge relay ..."

 {{{
 A proper (mutual) MyFamily MUST be set if you run more than one relay
 across multiple /16 networks.
 }}}

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

Re: [tor-bugs] #24683 [Applications/Tor Browser]: Sig file verification fail

[Tor Bug Tracker & Wiki]

#24683: Sig file verification fail
--+---
 Reporter:  xninaznx  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by xninaznx):

 Thanks for pointing that out. new output

 52daf2edb60735cb804abdc53cdd945704bf1072fcc682609ae2f0b2a09b64d8
 TorBrowser-7.0.11-osx64_en-US.dmg

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

Re: [tor-bugs] #24636 [Obfuscation/BridgeDB]: moat-transports response not sent

[Tor Bug Tracker & Wiki]

#24636: moat-transports response not sent
--+--
 Reporter:  mcs   |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-moat |  Actual Points:
Parent ID:  #24689| Points:  1
 Reviewer:|Sponsor:  SponsorV
--+--
Changes (by isis):

 * priority:  Medium => Very High
 * status:  new => closed
 * points:   => 1
 * resolution:   => fixed
 * sponsor:   => SponsorV


Comment:

 Fixed in my `fix/24636`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/24636
 branch].

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

Re: [tor-bugs] #24637 [Obfuscation/BridgeDB]: moat: incorrect response if no bridges available

[Tor Bug Tracker & Wiki]

#24637: moat: incorrect response if no bridges available
-+-
 Reporter:  mcs  |  Owner:  isis
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bridgedb-moat, bridgedb- |  Actual Points:
  distributors   |
Parent ID:  #24689   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by isis):

 * status:  new => closed
 * priority:  Medium => Immediate
 * points:   => 1
 * sponsor:   => SponsorV
 * keywords:   => bridgedb-moat, bridgedb-distributors
 * resolution:   => fixed


Comment:

 Fixed in my `fix/24637`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/24637
 branch], which includes the following small spec change specifying the
 error:

 {{{
  If the ``SOLUTION`` was successful for the supplied ``CHALLENGE``, but
 the
  server is unable to distribute the requested Bridges, the server responds
 ``200
  OK`` with the following JSON::

  {
 -  "error": {
 -"id": "1",
 +  "errors": [{
 +"id": "6",
 +"type": "moat-bridges",
 +"version": "0.1.0",
  "code": "404",
  "status": "Not Found",
 -"title": "Could not fetch the type of bridges you requested",
  "detail": "DETAILS",
 -  }
 +  }]
  }

  where:

  * ``DETAILS`` is some string describing the detailed nature of the issue.

 }}}

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

Re: [tor-bugs] #24548 [Core Tor]: Add Windows and mobile platforms to packages wiki

[Tor Bug Tracker & Wiki]

#24548: Add Windows and mobile platforms to packages wiki
-+
 Reporter:  teor |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

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


Comment:

 This is done

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

Re: [tor-bugs] #24643 [Internal Services/Service - trac]: ValueError: invalid literal for int() with base 10: 'johan36'

[Tor Bug Tracker & Wiki]

#24643: ValueError: invalid literal for int() with base 10: 'johan36'
--+-
 Reporter:  johan36   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by teor):

 * owner:  (none) => qbi
 * component:  - Select a component => Internal Services/Service - trac


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

Re: [tor-bugs] #24683 [Applications/Tor Browser]: Sig file verification fail

[Tor Bug Tracker & Wiki]

#24683: Sig file verification fail
--+---
 Reporter:  xninaznx  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by catalyst):

 Replying to [comment:4 xninaznx]:
 > I didn't get that response, I got:
 >
 > z:~ n$ shasum -a 256 TorBrowser-7.0.11-osx64_en-US.dmg
 > shasum: TorBrowser-7.0.11-osx64_en-US.dmg:

 That's the sort of output that might result if shasum can't find the file.
 Are you running that in the same directory that contains the .dmg file?
 Your prompt implies your current directory is `~` not `~/Downloads` which
 is the directory that your previous comments imply you downloaded the file
 to.

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

Re: [tor-bugs] #24683 [Applications/Tor Browser]: Sig file verification fail

[Tor Bug Tracker & Wiki]

#24683: Sig file verification fail
--+---
 Reporter:  xninaznx  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by xninaznx):

 I didn't get that response, I got:

 z:~ n$ shasum -a 256 TorBrowser-7.0.11-osx64_en-US.dmg
 shasum: TorBrowser-7.0.11-osx64_en-US.dmg:

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24691 [Metrics/Consensus Health]: Refactor Synthetic flags

[Tor Bug Tracker & Wiki]

#24691: Refactor Synthetic flags
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Re-read the synthetic flag section of https://blog.torproject.org/we-made-
 big-improvements-searching-relays and see if you want to change the way we
 handle some of those flags.

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

Re: [tor-bugs] #24506 [Core Tor/Torflow]: Move some bandwidth authority servers to a CDN

[Tor Bug Tracker & Wiki]

#24506: Move some bandwidth authority servers to a CDN
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  task  | Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Major | Resolution:
 Keywords:  tor-bwauth|  Actual Points:
Parent ID:  #24499| Points:
 Reviewer:|Sponsor:
--+---

Comment (by tom):

 Replying to [comment:7 teor]:
 > Thanks Tom!
 > A 15% increase in the differences between bandwidth authorities seems
 reasonable for such a major change,
 > Are you only using fastly? Or are you using fastly alongside your
 existing server?


 Only fastly.

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

Re: [tor-bugs] #24506 [Core Tor/Torflow]: Move some bandwidth authority servers to a CDN

[Tor Bug Tracker & Wiki]

#24506: Move some bandwidth authority servers to a CDN
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  task  | Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Major | Resolution:
 Keywords:  tor-bwauth|  Actual Points:
Parent ID:  #24499| Points:
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 Thanks Tom!
 A 15% increase in the differences between bandwidth authorities seems
 reasonable for such a major change,
 Are you only using fastly? Or are you using fastly alongside your existing
 server?


 Replying to [comment:6 mikeperry]:
 > FWIW, I think a better approach is to ensure we are getting the
 diversity we need by specifying a list of mirrors in specific geographic
 locations.

 We can use one or more CDNs to cover some geographic locations, and
 specifically set up servers in other locations that aren't covered by the
 CDNs.

 > If we can somehow specify which location that the CDN always uses for
 us, rather than having it picking the closest one to whichever exit, that
 would be better IMO. See also #24674.

 Fastly does not have this feature: it only allows us to select between US-
 EU POPs, and all POPs.

 Can you explain why choosing the nearest server is a bad thing?
 If our goal is to provide each client with approximately the same
 bandwidth regardless of path, then we should include paths that clients
 typically use. This includes downloads from CDNs. And it probably does
 include a bias towards the US and EU, because many websites are hosted
 there, or are hosted on CDNs that have a bias towards there. (But maybe
 not a bias that is as extreme as the one we have right now.)

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

Re: [tor-bugs] #24001 [Core Tor/Tor]: node_get_ed25519_id() should check if the microdesc ed25519 id is all zero

[Tor Bug Tracker & Wiki]

#24001: node_get_ed25519_id() should check if the microdesc ed25519 id is all 
zero
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:  #23975| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 That checks if the first byte of the object is zero. We need to check if
 every byte is zero.
 We have a function for that, I think it's called tor_mem_is_zero().

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

Re: [tor-bugs] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on operator relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on operator relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 There could be a bug in the whitelist or blacklist - they appear to be
 eliminating all relays.
 Also, the list is incomplete, we still have to do a tor-relays opt-in, and
 check with operators whose relay details have changed, but they haven't
 told 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] #24415 [Applications/Tor Browser]: Tor crashes when opening new tab, reason unknown

[Tor Bug Tracker & Wiki]

#24415: Tor crashes when opening new tab, reason unknown
--+---
 Reporter:  kouwei32  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by phoul):

 This has been reported on the help-desk as well.

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

Re: [tor-bugs] #24687 [Core Tor/Tor]: Tor eats all mbufs on FreeBSD

[Tor Bug Tracker & Wiki]

#24687: Tor eats all mbufs on FreeBSD
--+--
 Reporter:  AMDmi3|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by AMDmi3):

 Thanks for pointers, I'll read the maillist.

 While here, I need to clarify some bits. mbufs/mbuf clusters are units of
 memory management in FreeBSD kernel IPC subsystems. In particular, socket
 buffers are stored in mbufs. There's a (tunable) systemwide limit on
 maximal number of mbuf clusters, and when it's reached no more mbufs are
 allocated and incoming packets may no longer be processed, which results
 in network completely dead for a whole machine. This is what happens here.

 Since it's related to kernel memory management, it's unlikely that it
 could be fixed by tor memory options. My guess is that the attack makes
 tor open a lot of sockets and fills their buffers. In theory, on my
 FreeBSD setup it allows taking up to (sysctl net.inet.tcp.recvspace *
 min(sysctl kern.ipc.maxsockets, ulimit -n)) = (65536 * 31740) ~= 2G of
 kernel memory. The machine only has 1G, but mbuf limit is hit before the
 memory is exhausted anyway.

 This could be fixed by limiting the max number of open files for tor with
 some low value, but my graphs show that it needs at least 6k sockets as it
 is, so any sane limit (around 10k) will still allow to take a lot of
 memory. So it should probably be handled on the tor side somehow, limiting
 number of connections which take a lot of memory (I assume normal
 connections don't consume this much) or tuning socket buffer sizes.

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

Re: [tor-bugs] #24506 [Core Tor/Torflow]: Move some bandwidth authority servers to a CDN

[Tor Bug Tracker & Wiki]

#24506: Move some bandwidth authority servers to a CDN
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  task  | Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Major | Resolution:
 Keywords:  tor-bwauth|  Actual Points:
Parent ID:  #24499| Points:
 Reviewer:|Sponsor:
--+---
Changes (by tom):

 * Attachment "fastly-01.png" added.

 Very early comparison of fastly as the server for a bwauth

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

Re: [tor-bugs] #24671 [Core Tor/Tor]: sched: KISTLite should set an upper limit to write on the outbuf

[Tor Bug Tracker & Wiki]

#24671: sched: KISTLite should set an upper limit to write on the outbuf
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, dos, tor-channel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 See branch: `bug24671_032_01`

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

Re: [tor-bugs] #24683 [Applications/Tor Browser]: Sig file verification fail

[Tor Bug Tracker & Wiki]

#24683: Sig file verification fail
--+---
 Reporter:  xninaznx  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 If you are running macOS, to get the sha256sum of a file, you can run this
 command:
 {{{
 shasum -a 256 TorBrowser-7.0.11-osx64_en-US.dmg
 }}}

 This is the sha256sum I have:
 {{{
 5143e4a2141a69f66869be13eef4bcaac4e6c27c78383fc8a4c38b334759f3a2
 TorBrowser-7.0.11-osx64_en-US.dmg
 }}}
 And I can verify this file with the gpg signature.

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

Re: [tor-bugs] #24683 [Applications/Tor Browser]: Sig file verification fail

[Tor Bug Tracker & Wiki]

#24683: Sig file verification fail
--+---
 Reporter:  xninaznx  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by xninaznx):

 Sorry, I'm not sure how to do that. I used GPG to import your key and
 tried to verify the sig file in a terminal.

 gpg --keyserver pool.sks-keyservers.net --recv-keys 0x4E2C6E8793298290
 gpg: key 4E2C6E8793298290: 41 duplicate signatures removed
 gpg: key 4E2C6E8793298290: 141 signatures not checked due to missing keys
 gpg: key 4E2C6E8793298290: 1 signature reordered
 gpg: key 4E2C6E8793298290: "Tor Browser Developers (signing key)
 " not changed
 gpg: Total number processed: 1
 gpg:  unchanged: 1
 z:~ n$ gpg --fingerprint 0x4E2C6E8793298290
 pub   rsa4096 2014-12-15 [C] [expires: 2020-08-24]
   EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
 uid   [ unknown] Tor Browser Developers (signing key)
 
 sub   rsa4096 2016-08-24 [S] [expires: 2018-08-24]

 z:~ n$ gpg --verify ~/Downloads/TorBrowser-7.0.11-osx64_en-US.dmg{.asc*,}
 gpg: Signature made Fri Dec  8 05:00:23 2017 EST
 gpg:using RSA key D1483FA6C3C07136
 gpg: BAD signature from "Tor Browser Developers (signing key)
 " [unknown]

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

Re: [tor-bugs] #24683 [Applications/Tor Browser]: Sig file verification fail

[Tor Bug Tracker & Wiki]

#24683: Sig file verification fail
--+---
 Reporter:  xninaznx  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by xninaznx):

 * Attachment "TorBrowser-7.0.11-osx64_en-US.dmg.asc" 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] #24001 [Core Tor/Tor]: node_get_ed25519_id() should check if the microdesc ed25519 id is all zero

[Tor Bug Tracker & Wiki]

#24001: node_get_ed25519_id() should check if the microdesc ed25519 id is all 
zero
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:  #23975| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by aruna1234):

 Replying to [comment:5 nickm]:
 > In C, doing an "if (ptr)" check on a pointer checks whether the pointer
 is NULL, not whether the memory that the pointer points to is zero.

 If that's the case then I think this would work:
 if(*(node->ri))

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

Re: [tor-bugs] #24665 [Core Tor/Tor]: sched: In KIST, the extra_space kernel value needs to be allowed to be negative

[Tor Bug Tracker & Wiki]

#24665: sched: In KIST, the extra_space kernel value needs to be allowed to be
negative
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:2 yawning]:
 > The branch looks sensible to me.
 >
 > My inner pedant will say that "If a connection to a relay was unreliable
 meaning tor was struggling to flush bytes towards the relay" is misleading
 at best, since the congestion window shrinking (by quite a bit) is an
 expected part of how TCP/IP works and not particularly indicative of an
 overloaded condition on it's own.

 Ah I think I failed to explain my comment correctly. The point of that
 line was a reason for KIST to actually consider the `notsent` queue size
 *because* it could be that the connection is struggling towards the relay.

 How would you phrase it in a proper English?

 >
 > While you're here, assuming the scheduler is called significantly faster
 than the RTT of most links (read that as "If 10 ms is lower than the RTT
 of most if not all links"), you can/should reduce `sock_buf_size_factor`
 as well, because you aren't going to get a full congestion window worth of
 ACKs back between scheduler calls in common cases.

 Interesting... if the channel is quite active, yes the scheduler tick for
 it should be 10ms.

 What is a reasonable size factor in your opinion? It seems we can get some
 RTT information with the `getsockopt()` call within `struct tcp_info`,
 maybe we could adjust a scaling factor based on those values? (If that is
 an idea, we should open a ticket to make way for this one to be merged)

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

Re: [tor-bugs] #24666 [Core Tor/Tor]: sched: Store the circuit ID instead of the full DESTROY cell in the destroy queue

[Tor Bug Tracker & Wiki]

#24666: sched: Store the circuit ID instead of the full DESTROY cell in the 
destroy
queue
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, tor-cell, |  Actual Points:
  backport-031,backport-030, backport-029,   |
  backport-028, backport-025 |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by dgoulet):

 lgtm; Currently testing, will let you know and move it to merge_ready once
 there.

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

Re: [tor-bugs] #24690 [Core Tor/Tor]: Update to December GeoIP2 database

[Tor Bug Tracker & Wiki]

#24690: Update to December GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-relay 025-backport|  implemented
  026-backport 027-backport 028-backport |  Actual Points:
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Thanks, Karsten!

 Merged to 0.2.5 and forward.

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

Re: [tor-bugs] #24666 [Core Tor/Tor]: sched: Store the circuit ID instead of the full DESTROY cell in the destroy queue

[Tor Bug Tracker & Wiki]

#24666: sched: Store the circuit ID instead of the full DESTROY cell in the 
destroy
queue
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, tor-cell, |  Actual Points:
  backport-031,backport-030, backport-029,   |
  backport-028, backport-025 |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Branch updated as destroy_cells_025.

 I addressed the first and third points above, but didn't remove the timer,
 since I think we'll need it for the OOM handler.

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

Re: [tor-bugs] #24666 [Core Tor/Tor]: sched: Store the circuit ID instead of the full DESTROY cell in the destroy queue

[Tor Bug Tracker & Wiki]

#24666: sched: Store the circuit ID instead of the full DESTROY cell in the 
destroy
queue
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, tor-cell, |  Actual Points:
  backport-031,backport-030, backport-029,   |
  backport-028, backport-025 |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet


Comment:

 * `destroy_cell_to_packed_cell()` is supposed to free the `destroy_cell_t`
 but doesn't leading to memory leak.

  Seems a simple `tor_free(inp)` is required.

 * The `inserted_time` seems not used at all. I bet it will be useful later
 especially with the OOM but as a fix that we will be backported, I think
 we could reduce the size even more by removing it?

 * This snippet I think could use a comment that says that the destroy
 queue can NOT be empty since the `pop()` can return NULL and
 `circuitmux_get_first_active_circuit()` only returns a queue with > 0
 value.

 {{{
 +  dcell = destroy_cell_queue_pop(destroy_queue);
 +  tor_assert(dcell);
 }}}

 Rest 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

[tor-bugs] #24690 [Core Tor/Tor]: Update to December GeoIP2 database

[Tor Bug Tracker & Wiki]

#24690: Update to December GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-client tor-relay 025-backport
 Severity:  Normal   |  026-backport 027-backport 028-backport
 |  029-backport
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 ​[https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-12-06 My
 geoip-2017-12-06 branch] contains the updated `geoip` and `geoip6` files
 with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5
 and all other relevant branches.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 The test_channel_flushmux() test no longer exists in 0.3.3, since channel
 queues no longer exist. (See #23709.)

 If we want, we can remove all the redundant checks for whether
 new_fake_channel() has failed -- I have those in a branch called
 one_more_stack_fix, but I suggest that we don't actually take them, since
 these don't actually seem to cause stack warnings.

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

Re: [tor-bugs] #24685 [Applications/Tor Browser]: Lockpad icon doesn't appear and connection is labeled as insecure when loading a PDF from a secure URL

[Tor Bug Tracker & Wiki]

#24685: Lockpad icon doesn't appear and connection is labeled as insecure when
loading a PDF from a secure URL
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:2 cypherpunks]:
 > Replying to [comment:1 cypherpunks]:
 > > Fun, fun, it doesn't want to go to ​https://svn.torproject.org (if you
 paste it into the URL bar)
 > That's because there's an invisible character before the https:// that
 is put by trac, which leads to a direct search. Ok, fine, here you go for
 the plaintxt: `https://svn.torproject.org/svn/projects/design-
 paper/blocking.pdf`
 Damn trac! I tried to select carefully a part of that URL, but it copied
 that shit anyway!
 BTW, I can confirm the described issue.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+

Comment (by nickm):

 merged stack_again_032.

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

Re: [tor-bugs] #24605 [Core Tor/Tor]: Log main loop iteration count as part of the heartbeat messages

[Tor Bug Tracker & Wiki]

#24605: Log main loop iteration count as part of the heartbeat messages
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  implemented
 Keywords:  s8, s8-perf   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 lgtm; merged 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] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc, man  |  Actual Points:
Parent ID:  #24497| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I've incorporated that sentence, and noted the requirement in a few more
 places, in a new branch `bug24526` in my public repository.  I've put the
 warnings in separate paragraphs so that they stand out more.  Still
 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] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor2
--+
Changes (by cypherpunks):

 * keywords:   => tor-client


Comment:

 0.3.1.9 shows this in Tor Browser on Windows 7.

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

Re: [tor-bugs] #24384 [Metrics/Onionoo]: Decode percent-encoded characters in qualified search terms

[Tor Bug Tracker & Wiki]

#24384: Decode percent-encoded characters in qualified search terms
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

 * milestone:  Onionoo-1.9.0 => Onionoo-2.0.0


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

Re: [tor-bugs] #22261 [Metrics/Onionoo]: Remove the $ from family fingerprints

[Tor Bug Tracker & Wiki]

#22261: Remove the $ from family fingerprints
-+
 Reporter:  teor |  Owner:  karsten
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Onionoo-1.9.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

 * milestone:  Onionoo-2.0.0 => Onionoo-1.9.0


Comment:

 Done and released.

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

Re: [tor-bugs] #24626 [Metrics]: Release ExoneraTor and Metrics-Web

[Tor Bug Tracker & Wiki]

#24626: Release ExoneraTor and Metrics-Web
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


Comment:

 All released [https://dist.torproject.org/exonerator/ exonerator] and
 [https://dist.torproject.org/metrics-web/ metrics-web].

 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] #24175 [Metrics/Website]: Use an embedded Jetty in metrics-web and use metrics-base as build environment.

[Tor Bug Tracker & Wiki]

#24175: Use an embedded Jetty in metrics-web and use metrics-base as build
environment.
-+-
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by iwakeh):

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


Comment:

 Metrics-web using an embedded Jetty and improved structure
 [https://dist.torproject.org/metrics-web/1.0.3/ was released today] and is
 deployed & running.

 Closing.

 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] #24501 [Core Tor/Tor]: When we hit MaxMemInQueues, make the log message more quantitative

[Tor Bug Tracker & Wiki]

#24501: When we hit MaxMemInQueues, make the log message more quantitative
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Per discussion last night, I think we should add a unit test to verify
 that %zu works if we're going to start using it...but we can probably
 afford to start using it.

 One other thing -- Shouldn't this also log
 `cell_queues_get_total_allocation()`?

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

Re: [tor-bugs] #24687 [Core Tor/Tor]: Tor eats all mbufs on FreeBSD

[Tor Bug Tracker & Wiki]

#24687: Tor eats all mbufs on FreeBSD
--+--
 Reporter:  AMDmi3|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: unspecified


Comment:

 Most likely the ongoing DDoS on the network is affecting your relay. The
 tor-relays@ mailing list archive has many discussions going on about this.
 I'm not very familiar with `mbuf` in FreeBSD but if this is related to a
 connection limit, you can bump it higher.

 The other option is to set `MaxMemInQueues` (man tor) to a reasonable
 limit of RAM you want your relay to use and once that limit is reached,
 Tor will triggers its OOM to remove bytes from memory and thus putting
 less pressure on the network.

 Appart from that, we are currently working on fixes to improve "tor" to
 deal better with this DDoS. Please, update the tickets with any more
 information you can gather on this.

 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] #24677 [Core Tor/Tor]: Use ping ::1 on Linux when ping6 ::1 fails

[Tor Bug Tracker & Wiki]

#24677: Use ping ::1 on Linux when ping6 ::1 fails
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  easy intro test ipv6  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:  teor  |Sponsor:
--+
Changes (by nickm):

 * reviewer:   => teor


Comment:

 looks plausible to me; do you like it, 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712   |  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by mcs):

 Replying to [comment:28 mcs]:
 > Kathy and I have been gathering various tickets that need to be fixed
 before we can ship this feature. We should either add them as children of
 this ticket or create a tracking bug.

 I created a tracking ticket: #24689

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

Re: [tor-bugs] #24642 [Obfuscation/meek]: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#24642: cannot use TOR_PT_EXIT_ON_STDIN_CLOSE with meek-client-torbrowser
--+-
 Reporter:  mcs   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+-
Changes (by mcs):

 * parent:   => #24689


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

Re: [tor-bugs] #24640 [Obfuscation/meek]: improve meek behavior when target server is down

[Tor Bug Tracker & Wiki]

#24640: improve meek behavior when target server is down
--+--
 Reporter:  brade |  Owner:  dcf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * parent:   => #24689


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

Re: [tor-bugs] #24637 [Obfuscation/BridgeDB]: moat: incorrect response if no bridges available

[Tor Bug Tracker & Wiki]

#24637: moat: incorrect response if no bridges available
--+--
 Reporter:  mcs   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * parent:   => #24689


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

Re: [tor-bugs] #24636 [Obfuscation/BridgeDB]: moat-transports response not sent

[Tor Bug Tracker & Wiki]

#24636: moat-transports response not sent
--+--
 Reporter:  mcs   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb-moat |  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * parent:   => #24689


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

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:  fixed
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged per discussion on IRC!

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

Re: [tor-bugs] #24614 [Applications/Tor Browser]: update to Meek 0.28 tag

[Tor Bug Tracker & Wiki]

#24614: update to Meek 0.28 tag
--+--
 Reporter:  brade |  Owner:  brade
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek  |  Actual Points:
Parent ID:  #24689| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * parent:  #23136 => #24689


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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712   |  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * parent:   => #24689


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

Re: [tor-bugs] #24432 [Obfuscation/BridgeDB]: The meek<->moat tunneling isn't set up correctly

[Tor Bug Tracker & Wiki]

#24432: The meek<->moat tunneling isn't set up correctly
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat bridgedb-dist|  Actual Points:
Parent ID:  #24689| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+--
Changes (by mcs):

 * parent:   => #24689


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

Re: [tor-bugs] #24685 [Applications/Tor Browser]: Lockpad icon doesn't appear and connection is labeled as insecure when loading a PDF from a secure URL

[Tor Bug Tracker & Wiki]

#24685: Lockpad icon doesn't appear and connection is labeled as insecure when
loading a PDF from a secure URL
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:1 cypherpunks]:
 > Fun, fun, it doesn't want to go to ​https://svn.torproject.org (if you
 paste it into the URL bar)
 That's because there's an invisible character before the https:// that is
 put by trac, which leads to a direct search. Ok, fine, here you go for the
 plaintxt: `https://svn.torproject.org/svn/projects/design-
 paper/blocking.pdf`

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

Re: [tor-bugs] #23830 [Metrics/Website]: Update README to get a development environment for metrics-web going

[Tor Bug Tracker & Wiki]

#23830: Update README to get a development environment for metrics-web going
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 A first release with all dependencies is available
 [https://dist.torproject.org/metrics-web/1.0.3/ here]; documentation needs
 still updating.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24689 [Applications/Tor Browser]: deliver Moat feature to end-users [tracking bug]

[Tor Bug Tracker & Wiki]

#24689: deliver Moat feature to end-users [tracking bug]
--+--
 Reporter:  mcs   |  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:  Sponsor4  |
--+--
 The purpose of this ticket is to track everything we need to do to ship
 the Moat feature to Tor Browser 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] #24425 [Core Tor/Tor]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-27, 031-backport-maybe  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 added 0a1b1430c87824d5f5922827b6ca770a43e709ac to fix the unit tests

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

Re: [tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t

[Tor Bug Tracker & Wiki]

#24554: sched: Have per-scheduler type data in a channel_t
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 I need to run this a bit more on top of #24665 and #24666.

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

Re: [tor-bugs] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on operator relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on operator relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 I'm fine merging this branch once you say it's 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] #24682 [Core Tor/Fallback Scripts]: Make fallback script usage instructions create a log file

[Tor Bug Tracker & Wiki]

#24682: Make fallback script usage instructions create a log file
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  fallback   |  Actual Points:  0.1
Parent ID:  #22271 | Points:  0.1
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 merged, plus 8e5450b7524798 to clean up a leftover line from a merge
 conflict

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

Re: [tor-bugs] #23271 [Core Tor/Tor]: control_auth_cookie isn't deleted when tor stops

[Tor Bug Tracker & Wiki]

#23271: control_auth_cookie isn't deleted when tor stops
--+
 Reporter:  yurivict271   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:  easy tor-control  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Do we have to check whether the file exists before removing it?  I'd
 suggest instead:

 {{{
 void
 tor_remove_file(const char *filename)
 {
   if (tor_unlink(filename) != 0 && errno != ENOENT) {
 log_warn(LD_FS, "Couldn't unlink %s: %s",
  filename, strerror(errno));
   }
 }
 }}}

 If that's okay with you, I'll merge 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] #24425 [Core Tor/Tor]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-27, 031-backport-maybe  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 per confirmation from dgoulet, merging to 0.3.2 and forward.

 Made the corresponding tor-spec change as
 405e77f109d7963c11ad04a077e3cc7b11bc21e9

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

Re: [tor-bugs] #24468 [Core Tor/Tor]: Measure HSDir usage to guide parameter choices

[Tor Bug Tracker & Wiki]

#24468: Measure HSDir usage to guide parameter choices
+--
 Reporter:  teor|  Owner:  teor
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  privcount-experimental, tor-hs  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * parent:  #24425 =>


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

Re: [tor-bugs] #23989 [Core Tor/Tor]: entry_guards_update_all() will pretend to update primaries even if sampled set is empty

[Tor Bug Tracker & Wiki]

#23989: entry_guards_update_all() will pretend to update primaries even if 
sampled
set is empty
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 I think this might be something we could fix just by documentation -- the
 `primary_guards_up_to_date` flag now means "are the primary guards up-to-
 date with respect to the consensus and status info that we have" -- not
 necessarily "are the primary guards usable".  When
 primary_guards_up_to_date gets set with no consensus available, then
 calling update_primary_guards() again actually wouldn't be a good idea,
 since it wouldn't do anything.

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

Re: [tor-bugs] #24454 [Core Tor/Tor]: sandbox failure on arm64

[Tor Bug Tracker & Wiki]

#24454: sandbox failure on arm64
--+
 Reporter:  weasel|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #24633 [Core Tor/Tor]: to->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。

[Tor Bug Tracker & Wiki]

#24633: to->pending->tqh_last is 0x。
-+-
 Reporter:  sx5486510|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  msvc 029-backport 030-backport   |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 If you can test (running the bitops tests and running tor) using the patch
 here, that would be confirmation that the approach works:

 {{{
 diff --git a/src/ext/timeouts/timeout-bitops.c b/src/ext/timeouts/timeout-
 bitops.c
 index a018f33b958500..45466f6cb313ca 100644
 --- a/src/ext/timeouts/timeout-bitops.c
 +++ b/src/ext/timeouts/timeout-bitops.c
 @@ -40,7 +40,7 @@ static __inline int clz32(unsigned long val)
  {
 DWORD zeros = 0;
 _BitScanReverse(, val);
 -   return zeros;
 +   return 31 - zeros;
  }
  #ifdef _WIN64
  /* According to the documentation, these only exist on Win64. */
 @@ -54,7 +54,7 @@ static __inline int clz64(uint64_t val)
  {
 DWORD zeros = 0;
 _BitScanReverse64(, val);
 -   return zeros;
 +   return 63 - zeros;
  }
  #else
  static __inline int ctz64(uint64_t val)
 }}}

 Also available in my public git repo in a branch called `bug24633_029`.

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

Re: [tor-bugs] #24685 [Applications/Tor Browser]: Lockpad icon doesn't appear and connection is labeled as insecure when loading a PDF from a secure URL

[Tor Bug Tracker & Wiki]

#24685: Lockpad icon doesn't appear and connection is labeled as insecure when
loading a PDF from a secure URL
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Fun, fun, it doesn't want to go to ​https://svn.torproject.org (if you
 paste it into the URL bar)

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

Re: [tor-bugs] #24425 [Core Tor/Tor]: Set the hsdir_spread_store parameter to 4 (or maybe even 5)

[Tor Bug Tracker & Wiki]

#24425: Set the hsdir_spread_store parameter to 4 (or maybe even 5)
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27, 031-backport-maybe  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 I see that hsdir_spread_store=4 is now set in the consensus.  Ready to
 merge the the change to 032 IYO?

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

Re: [tor-bugs] #24613 [Core Tor/Tor]: Avoid monotime_coarse_absolute_msec in channelpadding code

[Tor Bug Tracker & Wiki]

#24613: Avoid monotime_coarse_absolute_msec in channelpadding code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

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


Comment:

 ok, i've made the relevant change to the tests
 60bf8f6cf6295808eec542be31649b0bd82ad926; and I'm merging this to master.
 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] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Maybe, it's time to look from both sides?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24688 [Core Tor/Tor]: timing wheels should use 32-bit math on 32-bit platforms

[Tor Bug Tracker & Wiki]

#24688: timing wheels should use 32-bit math on 32-bit platforms
--+-
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  cpu, 32-bit, timing
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8-can  |
--+-
 I think this might help our 32-bit performance a bit.

 Not putting this in needs_review yet, since it needs more analysis.

 {{{
 diff --git a/src/common/timers.c b/src/common/timers.c
 index 93cde7de5fbd4b..3c806b7f4b422a 100644
 --- a/src/common/timers.c
 +++ b/src/common/timers.c
 @@ -66,6 +66,11 @@ struct timeout_cb {
   * above TIMEOUT_MAX can also be super-inefficent. Choosing 5 here sets
   * timeout_max to 2^30 ticks, or 29 hours with our value for
 USEC_PER_TICK */
  #define WHEEL_NUM 5
 +#if SIZEOF_VOID_P == 4
 +/* On 32-bit platforms, we want to override wheel_bit, so that timeout.c
 will
 + * use 32-bit math. */
 +#define WHEEL_BIT 5
 +#endif
  #include "src/ext/timeouts/timeout.c"

  static struct timeouts *global_timeouts = NULL;
 }}}

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

Re: [tor-bugs] #23169 [Metrics/Website]: Explain why metrics are important and what we do to make sure they're safe

[Tor Bug Tracker & Wiki]

#23169: Explain why metrics are important and what we do to make sure they're 
safe
-+--
 Reporter:  arma |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:8 irl]:
 > For the relay/bridge count, I'm just taking the last line of
 servers.csv. For the users count, this is more complex as it's necessary
 to search backwards through the file until you get a line where it's the
 one that matches. I guess really I should do this for servers.csv too, to
 make sure that it's getting the right line.

 Agreed on the last part. Relying on the last line to contain the correct
 number seems too fragile. Maybe we'll also want to use the number from 2
 or 3 days ago, or whatever the graph shows as last data point.

 > Is there already Java code for parsing the CSVs?

 No. We're not using CSVs as input anywhere other than in R scripts.

 An important part when writing this code is making sure it doesn't run too
 often. Like, a few times per day at most.

 And ideally the first run would happen when the server starts, not when
 the first request comes in.

 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] #23169 [Metrics/Website]: Explain why metrics are important and what we do to make sure they're safe

[Tor Bug Tracker & Wiki]

#23169: Explain why metrics are important and what we do to make sure they're 
safe
-+--
 Reporter:  arma |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 For the relay/bridge count, I'm just taking the last line of servers.csv.
 For the users count, this is more complex as it's necessary to search
 backwards through the file until you get a line where it's the one that
 matches. I guess really I should do this for servers.csv too, to make sure
 that it's getting the right line.

 Is there already Java code for parsing the CSVs?

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

Re: [tor-bugs] #17418 [Applications/Tor Browser]: Values in about:config that aren't disabled

[Tor Bug Tracker & Wiki]

#17418: Values in about:config that aren't disabled
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-pref  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => tbb-pref


Comment:

 But #18534 looks better.

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by cypherpunks):

 Also with the doorhanger idea one functionality is lost: One has to wait
 until the doorhanger appears before you can see which circuit was chosen.
 Previously, you can leave the Torbutton window open and you can see the
 chosen circuit as soon as it's set to go.

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

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by karsten):

 I just pushed [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=tasks-24218-23761-2 a new branch tasks-24218-23761-2] to my
 repository which has all commits squash/fixup squashed and which is
 rebased to current 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

[tor-bugs] #24687 [- Select a component]: Tor eats all mbufs on FreeBSD

[Tor Bug Tracker & Wiki]

#24687: Tor eats all mbufs on FreeBSD
--+--
 Reporter:  AMDmi3|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:  Tor: 0.3.1.9
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I'm running tor relay on FreeBSD 11.1, and not long ago the system started
 to occasionally stop responding to the network with

 kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached

 accompanied with

 kernel: sonewconn: pcb 0xf80003c61570: Listen queue overflow: 193
 already in queue awaiting acceptance (211 occurrences)

 messages in the logs.

 It first happened on Dec 13 and repeated 3 times, the approximate lifetime
 of the relay is ~1 day.

 Seems like a DOS attack which makes tor open a lot of connections and eat
 all the mbuf space. I don't see any peaks on trafic or pps graphs though,
 and there are no messages in tor log.

 I'm currently trying to gather more information.

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

Re: [tor-bugs] #24573 [Core Tor/Tor]: rewrite_node_address_for_bridge() should set IPv6 preferences even if there is no ri

[Tor Bug Tracker & Wiki]

#24573: rewrite_node_address_for_bridge()  should set IPv6 preferences even if
there is no ri
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-bridge-client, easy,   |  Actual Points:
  intro  |
Parent ID:  #20916   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-

Comment (by ffmancera):

 All tests passed, it's fine with 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] #24677 [Core Tor/Tor]: Use ping ::1 on Linux when ping6 ::1 fails

[Tor Bug Tracker & Wiki]

#24677: Use ping ::1 on Linux when ping6 ::1 fails
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  easy intro test ipv6  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  new => needs_review


Comment:

 Done! Check my github
 [https://github.com/ffmancera/tor/tree/github/bug24677 branch bug24677].

 PD: I have also added failure and success message :)

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

[tor-bugs] #24686 [Applications/Tor Browser]: In Tor Browser context, should network.http.tailing.enabled be set to false?

[Tor Bug Tracker & Wiki]

#24686: In Tor Browser context, should network.http.tailing.enabled be set to
false?
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff59-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Here's what `network.http.tailing.enabled` does:
 https://www.janbambas.cz/firefox-57-delays-requests-tracking-domains/ It
 depends on Disconnect's tracking list.

 In Tor Browser context I'm not sure whether this would be beneficial.

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

Re: [tor-bugs] #24399 [Webpages/Website]: Create a consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Create a consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #24664| Points:
 Reviewer:|Sponsor:
--+

Comment (by antonela):

 ＼(＾O＾)／

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

Re: [tor-bugs] #24684 [Applications/Tor Browser]: uBlock stopped working in TB > 7.0.10

[Tor Bug Tracker & Wiki]

#24684: uBlock stopped working in TB > 7.0.10
--+---
 Reporter:  acid  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ublock, firefox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by acid):

 Replying to [comment:5 gk]:
 > Replying to [comment:4 acid]:
 > > @gk it doesn't relate really, I just stumbled across it while
 searching for uBlock bugs here. I've had those freezes since 7.0, but
 never reported them before.
 >
 > I am confused. In this ticket you claim uBlock is not working anymore
 with Tor Browser > 7.0.10 and in #22506 you say it just delays Tor
 Browser. So, it is working then for you?

 Sorry for the confusion, altough I am not sure how to phrase it otherwise.
 uBlock is "not working" as in the functionality of uBlock (e.g. blocking
 ads, displaying 3rd party sources) is not working. The settings, icon,
 etc... is still there and alive. I can install the addon just fine, it
 just doesn't do what it's supposed to do.

 The delay is mostly just there after installing/updating uBlock, and it
 has been there since TB 7. The delay was also there when uBlock was still
 working correctly before the upgrade to 7.0.11, and it is still happening
 on TB 7.0.11.

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

Re: [tor-bugs] #24684 [Applications/Tor Browser]: uBlock stopped working in TB > 7.0.10

[Tor Bug Tracker & Wiki]

#24684: uBlock stopped working in TB > 7.0.10
--+---
 Reporter:  acid  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ublock, firefox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:4 acid]:
 > @gk it doesn't relate really, I just stumbled across it while searching
 for uBlock bugs here. I've had those freezes since 7.0, but never reported
 them before.

 I am confused. In this ticket you claim uBlock is not working anymore with
 Tor Browser > 7.0.10 and in #22506 you say it just delays Tor Browser. So,
 it is working then for 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] #24675 [Webpages/Website]: Outdated return link in bitcoin donations

[Tor Bug Tracker & Wiki]

#24675: Outdated return link in bitcoin donations
--+
 Reporter:  sem   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


Comment:

 thanks for reporting 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] #24684 [Applications/Tor Browser]: uBlock stopped working in TB > 7.0.10

[Tor Bug Tracker & Wiki]

#24684: uBlock stopped working in TB > 7.0.10
--+---
 Reporter:  acid  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ublock, firefox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by acid):

 @gk it doesn't relate really, I just stumbled across it while searching
 for uBlock bugs here. I've had those freezes since 7.0, but never reported
 them before.

 @cypherpunks I even downgraded down to 1.14.12, none of them worked.

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

Re: [tor-bugs] #24154 [Applications/Tor Browser]: Look into fuzzing our tor-browser patches

[Tor Bug Tracker & Wiki]

#24154: Look into fuzzing our tor-browser patches
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201711,|  Actual Points:
  GeorgKoppen201711  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by toralf):

 I do fuzz tests the Tor git tree using the AFL. I got for enarly every
 fuzz test warnings like these :
 {{{
 torproject@mr-fox ~/done $ grep -h WARNING */fuzz.log | sort -u
 [!] WARNING: No new instrumentation output, test case may be useless.
 [!] WARNING: Some test cases are huge (277 kB) - see
 /usr/share/doc/afl-2.52b/perf_tips.txt!
 [!] WARNING: Some test cases are huge (316 kB) - see
 /usr/share/doc/afl-2.52b/perf_tips.txt!
 [!] WARNING: Some test cases are huge (79.9 kB) - see
 /usr/share/doc/afl-2.52b/perf_tips.txt!
 [!] WARNING: Some test cases look useless. Consider using a smaller set.
 [!] WARNING: You probably have far too many input files! Consider trimming
 down.
 [!] WARNING: Not binding to a CPU core (AFL_NO_AFFINITY set).
 }}}
 Maybe the fuzz_corpora directory needs an update ?

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:  tor-tls, security-low-maybe, regression =>
 * status:  needs_information => new
 * points:  1 =>
 * component:  Core Tor/Tor => Applications/Tor Browser
 * milestone:  Tor: 0.3.3.x-final =>


Comment:

 Oops, sorry, I thought this was an issue with Tor's optimistic data
 feature.
 Is there anything that Tor can do tohelp here, or is it an issue with how
 the application uses the
 SOCKSPort?

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

Re: [tor-bugs] #24684 [Applications/Tor Browser]: uBlock stopped working in TB > 7.0.10

[Tor Bug Tracker & Wiki]

#24684: uBlock stopped working in TB > 7.0.10
--+---
 Reporter:  acid  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ublock, firefox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 It could be related to this https://github.com/gorhill/uBlock/issues/3197

 This might have to do with the private browsing mode and the indexDB
 store.

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

Re: [tor-bugs] #24684 [Applications/Tor Browser]: uBlock stopped working in TB > 7.0.10

[Tor Bug Tracker & Wiki]

#24684: uBlock stopped working in TB > 7.0.10
--+---
 Reporter:  acid  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ublock, firefox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Did you try this version? https://addons.mozilla.org/en-US/firefox/addon
 /ublock-origin/versions/1.14.4

 Earlier versions won't have the most recent lists I think.

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

Re: [tor-bugs] #24684 [Applications/Tor Browser]: uBlock stopped working in TB > 7.0.10

[Tor Bug Tracker & Wiki]

#24684: uBlock stopped working in TB > 7.0.10
--+---
 Reporter:  acid  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ublock, firefox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * owner:  (none) => tbb-team
 * status:  new => needs_information
 * component:  - Select a component => Applications/Tor Browser


Comment:

 How does this ticket relate to your comment:4:ticket:22506?

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:13 gk]:
 > One thing I forgot: If we follow the doorhanger idea we should think
 quite a bit about how to communicate that change to Tor Browser users who
 are used to circuit display being behind the onion menu.
 There's https://trac.torproject.org/projects/tor/ticket/23489#comment:1
 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

Re: [tor-bugs] #23830 [Metrics/Website]: Update README to get a development environment for metrics-web going

[Tor Bug Tracker & Wiki]

#23830: Update README to get a development environment for metrics-web going
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 NB: Now the embedded jetty changes are merged to
 [https://gitweb.torproject.org/metrics-web.git the main git] repository.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24685 [Applications/Tor Browser]: Lockpad icon doesn't appear and connection is labeled as insecure when loading a PDF from a secure URL

[Tor Bug Tracker & Wiki]

#24685: Lockpad icon doesn't appear and connection is labeled as insecure when
loading a PDF from a secure URL
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 This doesn't happen all the time but it does sometimes, try to reproduce
 it by opening for example:

 https://svn.torproject.org/svn/projects/design-paper/blocking.pdf

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

Re: [tor-bugs] #23047 [Internal Services/Tor Sysadmin Team]: Please add iwakeh to the onionoo, metrics, and exonerator groups

[Tor Bug Tracker & Wiki]

#23047: Please add iwakeh to the onionoo, metrics, and exonerator groups
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 FWIW, iwakeh also does not have a home directory on meronense yet.

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

Re: [tor-bugs] #22506 [Applications/Tor Browser]: Tor Browser 7.0 dalayed startup with certain addons (with filter lists)

[Tor Bug Tracker & Wiki]

#22506: Tor Browser 7.0 dalayed startup with certain addons (with filter lists)
--+---
 Reporter:  morbis55  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by acid):

 I have the same issue. Reproducible every time when installing uBlock or
 updating it.
 Sometimes also during startup, I guess this is when uBlock is trying to
 update lists.

 System:
 Arch Linux x64
 TB v7.0.11
 uBlock Origin v1.14.22

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by irl):

 We now have an icon for the "Guard" and "Exit" concepts. If any
 iconography is to be used in the circuit display, then this should be
 consistent with other usage in Tor. antonela will be aware of these icons,
 as they did the design work. For others, see
 https://people.torproject.org/~irl/icons/

 I'm not saying that there should be icons, but if there are icons, they
 should be these icons.

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by gk):

 One thing I forgot: If we follow the doorhanger idea we should think quite
 a bit about how to communicate that change to Tor Browser users who are
 used to circuit display being behind the onion menu.

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

Re: [tor-bugs] #24676 [Internal Services/Service - trac]: Use selfhost captcha and do not rely on google captcha API

[Tor Bug Tracker & Wiki]

#24676: Use selfhost captcha and do not rely on google captcha API
--+-
 Reporter:  stupidregistration|  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

 * owner:  phoul => qbi
 * component:  Community/Tor Support => Internal Services/Service - trac


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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by cypherpunks):

 I think the shortcut `Ctrl+Shift+L` for a new circuit should be mentioned
 somewhere.

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

Re: [tor-bugs] #24175 [Metrics/Website]: Use an embedded Jetty in metrics-web and use metrics-base as build environment.

[Tor Bug Tracker & Wiki]

#24175: Use an embedded Jetty in metrics-web and use metrics-base as build
environment.
-+-
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  needs_revision => merge_ready


Comment:

 Deployment is done, except for running Rserve from Ant which we'll likely
 resolve this week. But we're not going back, so I just went ahead and
 merged everything to master. Yay! Leaving this ticket open until we have
 completed everything. 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] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:  antonela  |Sponsor:
--+--

Comment (by gk):

 Thanks! I like the idea of getting the circuit display out of the
 Torbutton menu and adding it to the doorhanger which is supposed to
 show/make accessible all the relevant website information (like TLS state,
 permissions etc.).

 I think something like version 8 is my favorite right now. My feeling is
 we should avoid versions with extra clicks to load new circuits (version 5
 and 6) as this gets annoying over time. And having this extra click just
 for the first time or until the user opts out seems overkill to me as
 well. Additionally, the button should not be "Load a New Circuit" as we
 are not loading circuits but web sites. :) And we should not lose the "for
 this site" aspect. It's not some arbitrary circuit that gets somehow
 deployed: what happens is that the website the user has open in the
 focused tab gets loaded over a new circuit. I am also inclined to add just
 a "Learn more" link next to the button and skip the guard node related
 message. It might confuse users knowing nothing about Tor. And once they
 start wondering why the first node rarely changes we have the "i" icon
 next to it AND there would still be the "Learn More" link available.

 FWIW: "All sessions will be lost" on version five is not true or at least
 highly misleading. First of all reloading the website to use a new circuit
 is only affecting sessions related to the website in question and not
 necessarily "all" (sure if there is just that one open then that statement
 is correct). Secondly, depending on how the website is detecting users
 it's not inconceivable that changing the circuit does not even affect any
 session because login cookies and other state in the browser is
 deliberately not touched by this option.

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