Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by teor):

 Replying to [comment:13 catalyst]:
 > In ba199f789922484b8a2b2efd909ad3dab124dd62, why define
 `EXPECTED_RAND_MANTISSA_BITS` as a hardcoded number instead of using
 `DBL_MANT_DIG`?  (assuming you've already tested for `FLT_RADIX==2`)

 Because we might decide that the contract is N bits of mansissa, rather
 than DBL_MANT_DIG.
 (For example, on my machine, we get 56. Before the patch, we got 31 on
 i386 and 32 on x86_64.)

 > Not directly related to any of the changes, but `crypto_rand_double()`
 could use a comment clarifying its contract.  That would also help us make
 clear what we're trying to achieve.  Are the double values assumed to be
 uniformly distributed in the range 0.0 <= d < 1.0?  How much entropy is it
 supposed to have?  Is it supposed to produce all representable double
 values? (assuming only the values that are more frequent than `2**-b`
 where `b` is the claimed entropy; for IEC 60559 doubles, this means we can
 ignore subnormals unless we're using more than a thousand bits of entropy)

 Yes, I agree we need to define the contract better.
 We need uniform distribution.
 While it would be nice to deliver all values in the range, values below
 10^-13^ (or 2^-43^) are more likely to be produced by RAM bit errors than
 entropy, so at some point we can ignore small values.

 > Regarding the `ldexp()` approach, we could save operations by doing them
 in 32-bit chunks (because I think we can assume at least 32 bits of
 mantissa for a double).

 As long as ldexp() supports 32 bits of input.

 And we might need to modify the ldexp() approach, because the current one
 only gives 64 bits of entropy. The algorithm could be:
 1. Generate a random 64-bit double using ldexp()
 2. If it's zero, generate a random 64-bit double and scale down using
 ldexp() to the next 64 bits

 Terminate when we reach our desired entropy (the contract), which should
 be based on:
 * the RAM bit error rate,
 * the maximum subnormal double bits (DBL_EXP_DIG +
 ceil(log2(DBL_MANT_DIG)).

 Unless we expect really good RAM bit error rates in future RAM, I suggest
 we go for 64 or 128 bits of entropy, and leave it there. (Also, the
 likelihood of any smaller numbers is miniscule, and some calculations will
 turn them into zeroes or infinities anyway.)

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

Re: [tor-bugs] #23083 [Obfuscation/BridgeDB]: BridgeDB gives the same bridges even to differrent IPs. It worth nothing to block the most of them.

[Tor Bug Tracker & Wiki]

#23083: BridgeDB gives the same bridges even to differrent IPs. It worth 
nothing to
block the most of them.
--+---
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by isis):

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


Comment:

 It's designed to do that.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by catalyst):

 I think the multiple `ldexp()` approach is more understandable than
 Downey's algorithm.  Are we performance-critical here?

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by teor):

 Replying to [comment:10 catalyst]:
 > Replying to [comment:9 teor]:
 > > It might be ok to only have 48 bits of entropy. Or we could extend
 that scheme to give us 52 (or >52 with subnormals).
 >
 > Would we have to do something different to make sure the subnormal
 values are uniform with the others?

 If the architecture supports subnormals, ldexp() generates them, and +
 correctly handles them, then this code will work:
 {{{
 unsigned short rseed[4];
 crypto_rand(rseed, sizeof rseed);
 return ldexp((double) rseed[0], -64) +
ldexp((double) rseed[1], -48) +
ldexp((double) rseed[2], -32) +
ldexp((double) rseed[3], -16);
 }}}

 It's much better than bit-stuffing, because it doesn't depend on how
 subnormals are implemented.

 Modified from:
 ​https://github.com/libressl-
 portable/openbsd/blob/master/src/lib/libc/stdlib/drand48.c

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by catalyst):

 In ba199f789922484b8a2b2efd909ad3dab124dd62, why define
 `EXPECTED_RAND_MANTISSA_BITS` as a hardcoded number instead of using
 `DBL_MANT_DIG`?  (assuming you've already tested for `FLT_RADIX==2`)

 Not directly related to any of the changes, but `crypto_rand_double()`
 could use a comment clarifying its contract.  That would also help us make
 clear what we're trying to achieve.  Are the double values assumed to be
 uniformly distributed in the range 0.0 <= d < 1.0?  How much entropy is it
 supposed to have?  Is it supposed to produce all representable double
 values? (assuming only the values that are more frequent than `2**-b`
 where `b` is the claimed entropy; for IEC 60559 doubles, this means we can
 ignore subnormals unless we're using more than a thousand bits of entropy)

 Regarding the `ldexp()` approach, we could save operations by doing them
 in 32-bit chunks (because I think we can assume at least 32 bits of
 mantissa for a double).

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

Re: [tor-bugs] #22789 [Core Tor/Tor]: Tor 0.3.1.4-alpha crash on OpenBSD-current

[Tor Bug Tracker & Wiki]

#22789: Tor 0.3.1.4-alpha crash on OpenBSD-current
-+-
 Reporter:  fredzupy |  Owner:  nickm
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.4-alpha
 Severity:  Major| Resolution:
 Keywords:  tor, crash, inet_pton, c99,  |  Actual Points:  3
  openbsd, 024-backport, 025-backport,   |
  026-backport, 027-backport, 028-backport,  |
  029-backport, 030-backport, review-group-20|
  trove-2017-007 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV
-+-
Changes (by teor):

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


Comment:

 The changelog entry for this is incorrect, the problematic pattern is
 `0x[^0-9a-fA-F]`. `0xfoo` is a valid hexadecimal 15.

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 nickm]:
 > If this is a hard issue to fix, we might just say "don't do that then"
 -- we don't build Tor with weak/lazy symbol binding ourselves, and while
 we don't tell people not to do it, we could just say that it is incumbent
 on people who change our build system to keep it working with their
 changes.
 >
 > Thoughts?

 Documenting this issue seems like a sensible solution, but we should check
 if this affects iOS and Tor.framework before deciding. If it does affect
 iOS, and we want to support iOS as a first-class platform, maybe linking
 would be a good check to add.

 I'd also phrase it as "pass unusual [linker] options to our build system",
 as "change our build system" could be unclear.

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

Re: [tor-bugs] #23080 [Core Tor/Tor]: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR

[Tor Bug Tracker & Wiki]

#23080: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the
format of ExtORPort USERADDR
+-
 Reporter:  dcf |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec pt-spec needs-spec-change  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by dcf):

 Here's a patch that adds tests for the additional USERADDR formats shown
 in the ticket description.
   attachment:0001-Add-additional-tests-for-ExtORPort-USERADDR.patch​

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

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

[Tor Bug Tracker & Wiki]

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:6 cmm32]:
 > * As for the ExtORPort USERADDR command, the
 [[https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-
 ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72|documentation]]
 should make the port optional. Internally, the code calls
 `tor_addr_port_split` which
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1896|checks
 if IPv6 address is passed]] and ignores the port if it is `AF_INET6`.
 Also, port is optional, see
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1896|here]]
 and
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1940|here]].

 I opened #23080 for the USERADDR documentation inconsistency. It looks
 like, regardless of what the spec says, it'll be fine to pass in an
 address with or without a port number, and with or without square brackets
 for IPv6.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23080 [Core Tor/Tor]: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR

[Tor Bug Tracker & Wiki]

#23080: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the
format of ExtORPort USERADDR
--+
 Reporter:  dcf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  tor-spec pt-spec needs-spec-change
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 (Originally noticed in comment:3:ticket:18628.)

 Proposal 196, which defines the ExtORPort protocol, implies that the
 USERADDR command must include a port number,
 [https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72 here]:
 {{{
  [0x0001] USERADDR: an address:port string that represents the
client's address.
 }}}
 and [https://gitweb.torproject.org/torspec.git/tree/proposals/196
 -transport-control-
 ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n97 here]:
 {{{
 3.1.2.1. USERADDR

   An ASCII string holding the TCP/IP address of the client of the
   pluggable transport proxy.
 }}}

 But
 
[https://gitweb.torproject.org/tor.git/tree/src/or/ext_orport.c?h=tor-0.3.0.9#n434
 connection_ext_or_handle_cmd_useraddr] calls
 
[https://gitweb.torproject.org/tor.git/tree/src/common/address.c?h=tor-0.3.0.9#n1895
 tor_addr_port_split], which makes the port number optional.

 It seems that connection_ext_or_handle_cmd_useraddr in fact accepts all
 these formats for USERADDR:
  * `1.2.3.4` (implied port=0)
  * `1.2.3.4:5678`
  * `1:2::3:4` (implied port=0)
  * `[1:2::3:4]` (implied port=0)
  * `[1:2::3:4]:5678`
 If this is intended, then I'd like proposal 196 to say that the port is
 optional, and square brackets are optional in the case of IPv6.

 For what it's worth, [https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/tree/obfs4proxy/obfs4proxy.go?h=obfs4proxy-0.0.7#n254
 obfs4proxy] and [https://gitweb.torproject.org/pluggable-
 transports/meek.git/tree/meek-server/meek-server.go?h=0.28#n142 meek-
 server] take proposal 196 at face value and always include a port in
 USERADDR (meek-server always uses the fictitious port number 1 because it
 doesn't know the true remote port).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #21321 [Applications/Tor Browser]: .onion HTTP is shown as non-secure in Tor Browser

[Tor Bug Tracker & Wiki]

#21321: .onion HTTP is shown as non-secure in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  ff52-esr, tbb-7.0-issues, tbb-   |  Actual Points:
  usability, ux-team, tbb-7.0-frequent,  |
  TorBrowserTeam201708R, GeorgKoppen201708   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:49 gk]:
 > Updated the branch with review feeback and created a new merge request:
 https://oniongit.eu/gk/tor-browser/merge_requests/2. Arthur, could you
 have a look at that one?

 I reviewed both patches and commented on oniongit.eu. I suggested a minor
 (optional) revision, but otherwise they look good.

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

Re: [tor-bugs] #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:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 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

[tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major |   Keywords:  tor-relay
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 When I start a relay with latest Tor version, it almost instantly crashes:

 {{{
 Aug 02 11:04:45.000 [err] tor_assertion_failed_(): Bug:
 consdiffmgr.c:1601: consensus_diff_queue_diff_work: Assertion
 in_main_thread() failed; aborting. (on Tor 0.3.1.5-alpha )
 Aug 02 11:04:45.000 [err] Bug: Assertion in_main_thread() failed in
 consensus_diff_queue_diff_work at consdiffmgr.c:1601. (Stack trace not
 available) (on Tor 0.3.1.5-alpha )
 }}}

 OS: Windows 7 SP1 x64
 Tor: 0.3.1.5-alpha x64 (custom MSYS2 build)

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

Re: [tor-bugs] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 If this is a hard issue to fix, we might just say "don't do that then" --
 we don't build Tor with weak/lazy symbol binding ourselves, and while we
 don't tell people not to do it, we could just say that it is incumbent on
 people who change our build system to keep it working with their changes.

 Thoughts?

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

Re: [tor-bugs] #23088 [Obfuscation/BridgeDB]: >Please note that you must send the email using an address from one of the following email providers: Riseup, Gmail or Yahoo.

[Tor Bug Tracker & Wiki]

#23088: >Please note that you must send the email using an address from one of 
the
following email providers: Riseup, Gmail or Yahoo.
--+-
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by isis):

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


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

Re: [tor-bugs] #23086 [Obfuscation/BridgeDB]: GIMP Captcha uses insecure random number generator

[Tor Bug Tracker & Wiki]

#23086: GIMP Captcha uses insecure random number generator
--+---
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by isis):

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


Comment:

 1) /dev/urandom is not "insecure".
 2) There's no need for a CSPRNG when randomly munging pixels.

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

Re: [tor-bugs] #23085 [Applications/Tor Browser]: Clicking on Test Tor Network Settings and then click the back button and I get this error The address isn’t valid

[Tor Bug Tracker & Wiki]

#23085: Clicking on Test Tor Network Settings and then click the back button 
and I
get this error The address isn’t valid
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:1 cypherpunks]:
 > >tiff
 >
 > Are you trying to hack the users of the website?
 No, What are you talking about?

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

Re: [tor-bugs] #23087 [Obfuscation/BridgeDB]: Get rid of GIMP in GiMP captcha

[Tor Bug Tracker & Wiki]

#23087: Get rid of GIMP in GiMP captcha
--+---
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by isis):

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


Comment:

 No. Go make your own project that uses Pillow. Stop making tickets for 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] #23080 [Core Tor/Tor]: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR

[Tor Bug Tracker & Wiki]

#23080: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the
format of ExtORPort USERADDR
+--
 Reporter:  dcf |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec pt-spec needs-spec-change  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I'd rather make the parser stricter to match the spec, then have the spec
 change to require this behavior forever.

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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Good diagnosis; I think you're right.  Does the attached patch file
 (23081.patch) fix the issue 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] #23091 [Core Tor/Tor]: Broken condition in check_expired_networkstatus_callback()

[Tor Bug Tracker & Wiki]

#23091: Broken condition in check_expired_networkstatus_callback()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Patch LGTM.

 I looked to see what are the consequences of fixing this bug: Now the flag
 `need_to_update_have_min_dir_info` will be set only when we receive new
 dirinfo, instead of every 2 minutes. This means we will check if we have
 enough dirinfo to build a circuit only when needed, and not every 2
 minutes. I think that's what was intended originally, so I think we are
 good here.

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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
-+-
 Reporter:  Vort |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.5-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay regression win32 nt-   |  Actual Points:
  service|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4-can
-+-
Changes (by nickm):

 * keywords:  tor-relay regression => tor-relay regression win32 nt-service


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23087 [Obfuscation/BridgeDB]: Get rid of GIMP in GiMP captcha

[Tor Bug Tracker & Wiki]

#23087: Get rid of GIMP in GiMP captcha
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Why do we need GIMP, a full-featured and heavy graphics editor, to just
 make a captcha? Replace it with PILlow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23089 [Obfuscation/Pluggable transport]: What if 194.132.0.0/16 and 149.202.98.0/24 get blocked?

[Tor Bug Tracker & Wiki]

#23089: What if 194.132.0.0/16 and 149.202.98.0/24 get blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-


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

Re: [tor-bugs] #23085 [Applications/Tor Browser]: Clicking on Test Tor Network Settings and then click the back button and I get this error The address isn’t valid

[Tor Bug Tracker & Wiki]

#23085: Clicking on Test Tor Network Settings and then click the back button 
and I
get this error The address isn’t valid
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 >tiff

 Are you trying to hack the users of the website?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23086 [Obfuscation/BridgeDB]: GIMP Captcha uses insecure random number generator

[Tor Bug Tracker & Wiki]

#23086: GIMP Captcha uses insecure random number generator
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://github.com/isislovecruft/gimp-captcha/blob/master/gimp-
 captcha/captcha.py#L26L125L142L163L199L250L

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

Re: [tor-bugs] #23080 [Core Tor/Tor]: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the format of ExtORPort USERADDR

[Tor Bug Tracker & Wiki]

#23080: connection_ext_or_handle_cmd_useraddr and proposal 196 disagree on the
format of ExtORPort USERADDR
+--
 Reporter:  dcf |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec pt-spec needs-spec-change  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by asn):

 * milestone:   => Tor: 0.3.2.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] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
--+
 Reporter:  dcf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * milestone:   => Tor: 0.3.2.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] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+
Changes (by asn):

 * cc: ahf (added)
 * sponsor:   => Sponsor4-can
 * milestone:  Tor: unspecified => Tor: 0.3.2.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] #22926 [Core Tor/Tor]: The Tor compression code can call functions that are NULL

[Tor Bug Tracker & Wiki]

#22926: The Tor compression code can call functions that are NULL
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by ahf):

 This is going to be an issue for all external dependencies that we use via
 pkg-config I think. The old `TOR_SEARCH_LIBRARY()` macro is probably
 unaffected since it tries to build a small test file.

 I will try to do the same as we do in `TOR_SEARCH_LIBRARY()` when the
 library is found to ensure that we can link against the .so and that the
 headers are present.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
--+
 Reporter:  dcf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 tor_addr_parse allows these surprising address formats:
  * `[192.0.2.1]` (IPv4 in square brackets) → 192.0.2.1
  * `[11.22.33.44` (IPv4 with left square bracket only) → 11.22.33.4
  * `[11:22::33:44` (IPv6 with left square bracket only) → 11:22::33:44
  * `11:22::33:44:` (IPv6 with trailing colon) → 11:22::33:44

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23084 [- Select a component]: Make all .onion services of TorProject use HTTPS over Tor to prevent MitM

[Tor Bug Tracker & Wiki]

#23084: Make all .onion services of TorProject use HTTPS over Tor to prevent 
MitM
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

[tor-bugs] #23083 [Obfuscation/BridgeDB]: BridgeDB gives the same bridges even to differrent IPs. It worth nothing to block the most of them.

[Tor Bug Tracker & Wiki]

#23083: BridgeDB gives the same bridges even to differrent IPs. It worth 
nothing to
block the most of them.
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--


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

[tor-bugs] #23085 [Applications/Tor Browser]: Clicking on Test Tor Network Settings and then click the back button and I get this error The address isn’t valid

[Tor Bug Tracker & Wiki]

#23085: Clicking on Test Tor Network Settings and then click the back button 
and I
get this error The address isn’t valid
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Clicking on Test Tor Network Settings and then click the back button and I
 get this error "The address isn’t valid" every time.

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

Re: [tor-bugs] #23089 [Obfuscation/Pluggable transport]: What if 194.132.0.0/16 and 149.202.98.0/24 and 192.36.31.0/24 got blocked? (was: What if 194.132.0.0/16 and 149.202.98.0/24 and 192.36.31.0/32

[Tor Bug Tracker & Wiki]

#23089: What if 194.132.0.0/16 and 149.202.98.0/24 and 192.36.31.0/24 got 
blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #23089 [Obfuscation/Pluggable transport]: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got blocked? (was: What if 194.132.0.0/16 and 149.202.98.0/24 and 192.36.31.0/2

[Tor Bug Tracker & Wiki]

#23089: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got
blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #23089 [Obfuscation/Pluggable transport]: What if 194.132.0.0/16 and 149.202.98.0/24 and 192.36.31.0/32 got blocked? (was: What if 194.132.0.0/16 and 149.202.98.0/24 get blocked?)

[Tor Bug Tracker & Wiki]

#23089: What if 194.132.0.0/16 and 149.202.98.0/24 and 192.36.31.0/32 got 
blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
--+
 Reporter:  dcf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dcf):

 attachment:0001-Add-tests-for-tor_addr_parse-separate-from-
 tor_addr_.patch​ adds tests for tor_addr_parse, including the cases in the
 ticket description.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23088 [Obfuscation/BridgeDB]: >Please note that you must send the email using an address from one of the following email providers: Riseup, Gmail or Yahoo.

[Tor Bug Tracker & Wiki]

#23088: >Please note that you must send the email using an address from one of 
the
following email providers: Riseup, Gmail or Yahoo.
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 >Please note that you must send the email using an address from one of the
 following email providers:
 >Riseup
 shit not allowed to people
 >Gmail or Yahoo.
 NSA sluts

 What the fuck?

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

Re: [tor-bugs] #23071 [Core Tor/Tor]: test_hs_ntor.sh fails with recent pysha3

[Tor Bug Tracker & Wiki]

#23071: test_hs_ntor.sh fails with recent pysha3
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  python tests hs  |  Actual Points:  .1
Parent ID:   | Points:  .1
 Reviewer:  asn  |Sponsor:  SponsorR
-+
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by Sebastian):

 First it would be good to learn whether set_main_thread has been called.
 So I guess a patch along the lines of
 {{{
 --- a/src/common/compat_threads.c
 +++ b/src/common/compat_threads.c
 @@ -90,6 +90,7 @@ set_main_thread(void)
  int
  in_main_thread(void)
  {
 +  tor_assert(main_thread_id != -1);
return main_thread_id == tor_get_thread_id();
  }

 }}}
 could help debug 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] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
-+-
 Reporter:  Vort |  Owner:
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.5-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay regression win32 nt-   |  Actual Points:
  service|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4-can
-+-

Comment (by Vort):

 > Does the attached patch file (23081.patch) fix the issue for you?

 No, that is wrong `do_main_loop()`.
 This variant works:
 attachment:23081_v2.patch

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

Re: [tor-bugs] #23092 [Core Tor/Tor]: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Using the minimum is a one-line change. This one:
 {{{
 diff --git a/src/or/circuituse.c b/src/or/circuituse.c
 index d77020f19d..531456b259 100644
 --- a/src/or/circuituse.c
 +++ b/src/or/circuituse.c
 @@ -1402,7 +1402,8 @@ circuit_expire_old_circuits_clientside(void)
last_expired_clientside_circuits = now.tv_sec;

if (! circuit_build_times_disabled(get_options()) &&
 -  circuit_build_times_needs_circuits(get_circuit_build_times())) {
 +  circuit_build_times_needs_circuits(get_circuit_build_times()) &&
 +  IDLE_TIMEOUT_WHILE_LEARNING < get_options()->CircuitIdleTimeout) {
  /* Circuits should be shorter lived if we need more of them
   * for learning a good build timeout */
  cutoff.tv_sec -= IDLE_TIMEOUT_WHILE_LEARNING;
 }}}

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

Re: [tor-bugs] #23092 [Core Tor/Tor]: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_revision


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

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

[Tor Bug Tracker & Wiki]

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:8 dcf]:
 > Replying to [comment:6 cmm32]:
 > I know that in comment:5 I made a fuss about moving the SDP parsing
 logic into webrtcConn.RemoteAddr. But for some reason, doing that makes it
 stop working for me to run proxy-go and snowflake-client on the same
 computer! The code hangs forever inside the call to
 c.pc.RemoteDescription(). I don't know why (it might be a bug in go-
 webrtc), but I bisected and
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=2c0cfdfb953d3b37254c0a4dff5b61ca2be795cf
 2c0cfdfb] is definitely the commit that causes a change. So as a
 workaround, we might need to put the SDP parsing back where it was, until
 we figure out the cause. I can do that, if it's okay with you, because I'm
 easily able to reproduce the problem.

 Okay, I applied
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=be4c2fdd5e0780d11386e7157cf92a9ea035b4c3
 a small workaround]: just calls conn.RemoteAddr() before entering the
 goroutine instead of inside. I wonder if there is some kind of locking
 around RemoteDescription that was making it hang when called from
 different threads.

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

[tor-bugs] #23092 [Core Tor/Tor]: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.2-alpha
 Severity:  Normal|   Keywords:  doc easy
Actual Points:|  Parent ID:
   Points:  0.2   |   Reviewer:
  Sponsor:|
--+
 When I set CircuitIdleTimeout in chutney, it doesn't always work, because
 IDLE_TIMEOUT_WHILE_LEARNING is used instead. We should document this.

 Or maybe we should use min(CircuitIdleTimeout,
 IDLE_TIMEOUT_WHILE_LEARNING) when learning?

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

Re: [tor-bugs] #22874 [Obfuscation/Snowflake]: Standalone broker (independent of App Engine)

[Tor Bug Tracker & Wiki]

#22874: Standalone broker (independent of App Engine)
---+--
 Reporter:  dcf|  Owner:  cmm32
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 I merged the standalone-broker branch in [https://gitweb.torproject.org
 /pluggable-
 transports/snowflake.git/commit/?id=36debdfdd24e978fc323ec352852fc4af0bc4ae5
 36debdfdd2].

 There's a standalone broker running at https://snowflake-
 broker.bamsoftware.com/.

 I think now we just need https://snowflake-reg.appspot.com/ to upload the
 code from [https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/appengine?id=36debdfdd24e978fc323ec352852fc4af0bc4ae5
 appengine] so that clients start communicating with the standalone broker.

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

Re: [tor-bugs] #22343 [Applications/Tor Browser]: Save as... in the context menu results in using the catch-all circuit

[Tor Bug Tracker & Wiki]

#22343: Save as... in the context menu results in using the catch-all circuit
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  tbb-7.0-must, tbb-7.0-issues, tbb-regression,  |
  tbb-7.0-frequent, TorBrowserTeam201708R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:
 tbb-linkability, ff52-esr, tbb-7.0-must, tbb-7.0-issues, tbb-
 regression, tbb-7.0-frequent, TorBrowserTeam201708
 =>
 tbb-linkability, ff52-esr, tbb-7.0-must, tbb-7.0-issues, tbb-
 regression, tbb-7.0-frequent, TorBrowserTeam201708R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:16 gk]:
 > I still get exceptions:

 Good catch!

 Here's a new version for review, with this issue fixed, and rebased to the
 latest TBB alpha branch:
 https://github.com/arthuredelstein/tor-browser/commit/22343+5

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

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

[Tor Bug Tracker & Wiki]

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:6 cmm32]:
 > * Most comments addressed.

 Great. Thanks. I think this is getting close. I'll ask arlolra and serene
 to take a look too.

  *
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=bug18628=2846bbec9adeb7b2e06aa5b204982496c1ece5ce=db2251345d16a530cf27fe951b235719515c2b88
 cumulative bug18628 diff for snowflake]
  * [https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/diff/?h=bug18628=02a8eb6d7a236f8b805dbd086f1c46f5dfb51149=6dc990ad6a898bc507605c51a5aa860fb9f74201
 cumulative diff for websocket]

 

 In websocket:

 {{{
 +   // Request
 +   request http.Request
 }}}
 {{{
 +   ws.request = *req
 }}}
 I'm thinking it would be better to make request a pointer; i.e. `request
 *http.Request`, `ws.request = req`, in order to avoid copying the struct.
 I'm not sure it's safe to shallow-copy a Request struct, which may contain
 other recursive structures.

 

 In snowflake:

 I'm a little concerned about parsing the SDP in order to get the remote
 address. Ideally, of course, we'd find another way to do it, or use a
 proper library to parse the SDP. But in the meantime, I
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=485538bcf00bd4ddaeb5f81dd05e3caaa89ffd6d
 pushed some tests] to cover some additional syntax options that I took
 from RFC 4566. Can you pull those changes and update the code so that all
 the tests pass with `go test`?

 {{{
 +   if conn.RemoteAddr() != nil && conn.RemoteAddr().String() != "" {
 }}}
 I don't think we need the `!= ""` comparison here. Unless there's a kind
 of Addr you're thinking of that can return an empty string?

 I know that in comment:5 I made a fuss about moving the SDP parsing logic
 into webrtcConn.RemoteAddr. But for some reason, doing that makes it stop
 working for me to run proxy-go and snowflake-client on the same computer!
 The code hangs forever inside the call to c.pc.RemoteDescription(). I
 don't know why (it might be a bug in go-webrtc), but I bisected and
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=2c0cfdfb953d3b37254c0a4dff5b61ca2be795cf
 2c0cfdfb] is definitely the commit that causes a change. So as a
 workaround, we might need to put the SDP parsing back where it was, until
 we figure out the cause. I can do that, if it's okay with you, because I'm
 easily able to reproduce the problem.

 {{{
 +   if clientIP == nil {
 +   // Set client addr to empty
 +   log.Printf("failed to validate client_ip: %s", addr)
 +   addr = ""
 +
 }}}
 Let's not log an IP address here. We can add it (behind an "unsafe
 logging" option) if we need it later.

 > Note client IP address is now added to `opt.relayURL` before dialing
 websocket.

 I think that doing it this way creates a race condition. You have a bunch
 of goroutines reading a writing global state. Better to make a copy of the
 global relay URL (e.g., via url.Parse) that you can mutate each time. In
 fact, opt.relayURL should probably be removed completely
 ([https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=dbe1ef4fa55569e5d17c405df5707f6eb05bb56c
 I just did that on the master 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] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by nickm):

 exactly the same errors, or something different?

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

Re: [tor-bugs] #23085 [Applications/Tor Browser]: Clicking on Test Tor Network Settings and then click the back button and I get this error The address isn’t valid

[Tor Bug Tracker & Wiki]

#23085: Clicking on Test Tor Network Settings and then click the back button 
and I
get this error The address isn’t valid
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

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


Comment:

 This is a duplicate of #21948; the fix will be included in an upcoming
 version of Tor Browser.

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

Re: [tor-bugs] #23090 [Core Tor/Tor]: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32

[Tor Bug Tracker & Wiki]

#23090: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 seccomp-bpf was added in Linux 3.5.  Failure is to be expected.

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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by nickm):

 So, here are the possibilities I can think of:
   1. The work is being queued from somewhere other than the main thread.
   2. The `main_thread_id` variable has not been set.
   3. The main thread has somehow changed its thread ID.

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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by Vort):

 Sebastian, I see the same errors with this change.

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

Re: [tor-bugs] #23089 [Obfuscation/Pluggable transport]: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got blocked?

[Tor Bug Tracker & Wiki]

#23089: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got
blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by yawning):

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


Comment:

 Then other people should step up and run bridges, instead of just
 Torservers.  But this isn't a bug, it's more an outreach problem.

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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+
Changes (by nickm):

 * priority:  Medium => High
 * keywords:  tor-relay => tor-relay regression


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

Re: [tor-bugs] #23090 [Core Tor/Tor]: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32

[Tor Bug Tracker & Wiki]

#23090: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal| Resolution:
 Keywords:  crash |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Yeah; we can't make the sandbox work when the kernel doesn't support it.
 But we should at least give a useful error message -- "-22 (Invalid
 argument)!" isn't going to help anybody.

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

Re: [tor-bugs] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by Vort):

 > exactly the same errors, or something different?

 Exactly the same.

 > 1. The work is being queued from somewhere other than the main thread.

 Looks like most probable reason.

 One more note:
 Error happens only if relay is under the load.
 I have two keys: first have weight ~1000, second is unmeasured now.
 And with second key Tor did not hit this error 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] #21948 [Applications/Tor Browser]: Going back to about:tor page gives a "The address isn’t valid"-error

[Tor Bug Tracker & Wiki]

#21948: Going back to about:tor page gives a "The address isn’t valid"-error
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-e10s, tbb-7.0-issues,  |  Actual Points:
  tbb-regression, TorBrowserTeam201706   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: Dbryrtfbcbhgf (added)


Comment:

 Resolved #23085 as a duplicate.

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

Re: [tor-bugs] #23089 [Obfuscation/Pluggable transport]: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got blocked?

[Tor Bug Tracker & Wiki]

#23089: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got
blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 It seems like you disclose some information fetched from bridges.tpo,
 please don't do that.

 If bridge got blocked you can to request new one.

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

[tor-bugs] #23090 [Core Tor/Tor]: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32

[Tor Bug Tracker & Wiki]

#23090: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.9
 Severity:  Normal|   Keywords:  crash
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 A relay operator reports a sandbox failure on Tor 0.3.0.9 with the
 following log lines:
 {{{
 sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
 sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
 sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
 install_syscall_filter(): Bug: (Sandbox) failed to load: -22 (Invalid
 argument)! (on Tor 0.3.0.9 )
 tor_main(): Bug: Failed to create syscall sandbox filter (on Tor 0.3.0.9 )
 main process exited, code=exited, status=1/FAILURE
 }}}

 See https://lists.torproject.org/pipermail/tor-
 relays/2017-August/012694.html

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

Re: [tor-bugs] #23071 [Core Tor/Tor]: test_hs_ntor.sh fails with recent pysha3

[Tor Bug Tracker & Wiki]

#23071: test_hs_ntor.sh fails with recent pysha3
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  python tests hs  |  Actual Points:  .1
Parent ID:   | Points:  .1
 Reviewer:  asn  |Sponsor:  SponsorR
-+
Changes (by asn):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #23071 [Core Tor/Tor]: test_hs_ntor.sh fails with recent pysha3

[Tor Bug Tracker & Wiki]

#23071: test_hs_ntor.sh fails with recent pysha3
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  python tests hs  |  Actual Points:  .1
Parent ID:   | Points:  .1
 Reviewer:  asn  |Sponsor:  SponsorR
-+

Comment (by asn):

 Hmm, the code is now:


 {{{
 try:
 import sha3
 except ImportError:
 # In python 3.6, the sha3 functions are in hashlib whether we
 # import sha3 or not.
 pass

 try:
 # Pull the sha3 functions in.
 from hashlib import sha3_256, shake_256
 shake_squeeze = shake_256.digest
 except ImportError:
 if hasattr(sha3, "SHA3256"):
 }}}

 I think there is a problem here: If the `sha3` import fails, and the `from
 hashlib...` import fails, then the `if hasattr(sha3, "SHA3256"):` will
 also fail since sha3 is undefined. That's when we should return 77, right?

 How about the following patch on top of your patch?
 {{{
 -if hasattr(sha3, "SHA3256"):
 +if "sha3" in sys.modules and hasattr(sha3, "SHA3256"):
 }}}

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by catalyst):

 Replying to [comment:9 teor]:
 > It might be ok to only have 48 bits of entropy. Or we could extend that
 scheme to give us 52 (or >52 with subnormals).

 Would we have to do something different to make sure the subnormal values
 are uniform with the others?

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

Re: [tor-bugs] #22876 [Internal Services/Service - trac]: The cypherpunks account can be deleted by everyone

[Tor Bug Tracker & Wiki]

#22876: The cypherpunks  account can be deleted by everyone
--+---
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 #13269 has nothing to do with this.

 This is a dupe of #17547

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

Re: [tor-bugs] #22876 [Internal Services/Service - trac]: The cypherpunks account can be deleted by everyone

[Tor Bug Tracker & Wiki]

#22876: The cypherpunks  account can be deleted by everyone
--+---
 Reporter:  cypherpunks   |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 #13629 is the correct one

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

Re: [tor-bugs] #23089 [Obfuscation/Pluggable transport]: What if 0.0.0.0/0 got blocked? (was: What if 194.132.209.0/24 and 149.202.98.0/24 and 192.36.31.0/24 got blocked?)

[Tor Bug Tracker & Wiki]

#23089: What if 0.0.0.0/0 got blocked?
-+-
 Reporter:  cypherpunks  |  Owner:  asn
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #23088 [Obfuscation/BridgeDB]: >Please note that you must send the email using an address from one of the following email providers: Riseup, Gmail or Yahoo.

[Tor Bug Tracker & Wiki]

#23088: >Please note that you must send the email using an address from one of 
the
following email providers: Riseup, Gmail or Yahoo.
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > What the fuck?

 Use Kwangmyong, comrade!

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

Re: [tor-bugs] #23090 [Core Tor/Tor]: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32

[Tor Bug Tracker & Wiki]

#23090: Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.9
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, log, error-message, |  Actual Points:
  usability  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  crash => sandbox, log, error-message, usability


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

Re: [tor-bugs] #23064 [Applications/Tor Browser]: Tor doesn't open on OS X anymore

[Tor Bug Tracker & Wiki]

#23064: Tor doesn't open on OS X anymore
--+---
 Reporter:  nirvanh   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Thanks for trying those things. The messages from 3) indicate that Tor
 Browser's firefox process got far enough to launch the tor process, but
 the firefox process then crashed (which caused tor to exit as well).

 Here are some follow up questions:
 - Do you know if any version of Tor Browser 7.x has ever worked on your
 OSX system? Tor Browser 7.0 was released in early June 2017 and there have
 been a couple of follow up releases for OSX (7.0.1 and 7.0.2).
 - If you remove your TorBrowser-Data directory again and try to open Tor
 Browser 6.5.2, does it work correctly? You can download 6.5.2 from here:
 https://archive.torproject.org/tor-package-archive/torbrowser/6.5.2/ (but
 note that you should not use 6.5.2 for normal browsing; it is obsolete and
 contains known security bugs).
 - Do you have any antivirus or antimalware software installed? Does it
 help to disable or remove it?
 - Does Firefox 52.x ESR work on that same OSX system? You can download
 Firefox ESR from here: https://www.mozilla.org/en-
 US/firefox/organizations/all/

 Thanks for your help in debugging this problem.

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

Re: [tor-bugs] #23082 [Core Tor/Tor]: tor_addr_parse is overly permissive

[Tor Bug Tracker & Wiki]

#23082: tor_addr_parse is overly permissive
--+
 Reporter:  dcf   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dcf):

 Here is a fuzzer for tor_addr_parse: attachment:fuzz_addr.c.

 I ran it and didn't find any other unexpected inputs accepted by
 tor_addr_parse: attachment:fuzz_addr_findings.tar.gz
 {{{
 $ for a in fuzz_addr_findings/queue/*; do ./fuzz-addr --info < $a; done |
 grep -v error
 }}}

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

Re: [tor-bugs] #23071 [Core Tor/Tor]: test_hs_ntor.sh fails with recent pysha3

[Tor Bug Tracker & Wiki]

#23071: test_hs_ntor.sh fails with recent pysha3
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  python tests hs  |  Actual Points:  .1
Parent ID:   | Points:  .1
 Reviewer:  asn  |Sponsor:  SponsorR
-+
Changes (by nickm):

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


Comment:

 Looks good, but maybe simpler to just do "sha3 = None" if the sha3 import
 fails.  I've taken that approach and merged.  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] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by Vort):

 Caught!
 Look at the screenshot:
 attachment:tor_threads_bad.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23091 [Core Tor/Tor]: Broken condition in check_expired_networkstatus_callback()

[Tor Bug Tracker & Wiki]

#23091: Broken condition in check_expired_networkstatus_callback()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Turns out that this condition in `check_expired_networkstatus_callback()`:

 {{{
   if (ns && ns->valid_until < now+NS_EXPIRY_SLOP &&
   router_have_minimum_dir_info()) {
 router_dir_info_changed();
   }
 }}}

 ... is always true if we have all our needed directory info which means
 that `router_dir_info_changed()` is called every 2 minutes (the callback
 interval).

 Nick suggested that it should be `now - NS_EXPIRY_SLOP` which goes like
 this:

 If `valid_until` is 6am today, then `now - 24h` == 1pm yesterday, and
 `valid_until < (now - 24h)` is false. But at 6:01am tomorrow, `valid_until
 < now - 24h` becomes true.

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

Re: [tor-bugs] #23091 [Core Tor/Tor]: Broken condition in check_expired_networkstatus_callback()

[Tor Bug Tracker & Wiki]

#23091: Broken condition in check_expired_networkstatus_callback()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 See branch: `bug23091_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] #23081 [Core Tor/Tor]: Tor relay crashes at consensus_diff_queue_diff_work() with assertion in_main_thread() failed

[Tor Bug Tracker & Wiki]

#23081: Tor relay crashes at consensus_diff_queue_diff_work() with assertion
in_main_thread() failed
--+
 Reporter:  Vort  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Major | Resolution:
 Keywords:  tor-relay regression  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4-can
--+

Comment (by Vort):

 This bug may be related to Windows services.
 `tor --service start` -> error
 `tor.exe -f torrc` -> no error
 But I am not sure about 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] #23075 [Applications/Tor Browser]: Add an option to select the number of cores used for building in tor-browser-build.git

[Tor Bug Tracker & Wiki]

#23075: Add an option to select the number of cores used for building in tor-
browser-build.git
--+
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #17379| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

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


Comment:

 This is done with commit 60ba86636df928e97e265417b2c19bea4e85ea3a.

 It is possible to set the `RBM_NB_PROCS` environment variable to change
 the number of processes used. It is also possible to change it by defining
 `buildconf/nb_procs` in `rbm.local.conf`.

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

Re: [tor-bugs] #23091 [Core Tor/Tor]: Broken condition in check_expired_networkstatus_callback()

[Tor Bug Tracker & Wiki]

#23091: Broken condition in check_expired_networkstatus_callback()
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => asn


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