date:20171120

Re: [tor-bugs] #24348 [Internal Services/Service - lists]: Please make tor-packagers@ list

2017-11-20 Thread Tor Bug Tracker & Wiki

#24348: Please make tor-packagers@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 I set up the list. Please add the list to
 https://trac.torproject.org/projects/tor/wiki/doc/emailLists and close the
 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] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

2017-11-20 Thread Tor Bug Tracker & Wiki

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 Replying to [comment:7 cypherpunks]:
 > always support OFFICIAL TBB.

 While we're being complete: it's Tor Browser, not Tor Browser Bundle, and
 has been this way for years. The reason is that it's now just a browser
 with some extensions (which means e.g. that the browser update feature can
 update the whole thing).

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

Re: [tor-bugs] #24317 [Core Tor/Tor]: Do not use same country in the Tor circuits

2017-11-20 Thread Tor Bug Tracker & Wiki

#24317: Do not use same country in the Tor circuits
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:  #22339| Points:
 Reviewer:|Sponsor:
--+---
Changes (by arma):

 * parent:   => #22339


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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node()

2017-11-20 Thread Tor Bug Tracker & Wiki

#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactor, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by teor):

 Ok, looks good to me.

 Do you want to write a changes file?
 Any code changes get a changes file, even simple refactoring.

 Also, we should check this compiles and passes the tests before we merge.

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

Re: [tor-bugs] #24318 [Core Tor/Tor]: Clarify that the RelayBandwidth* options exclude directory fetches by relays

2017-11-20 Thread Tor Bug Tracker & Wiki

#24318: Clarify that the RelayBandwidth* options exclude directory fetches by
relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Thanks for the patch.

 Looks fine to me, let's get it 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] #24364 [- Select a component]: can not use internet bytor browser

2017-11-20 Thread Tor Bug Tracker & Wiki

#24364: can not use internet bytor browser
--+
 Reporter:  Kua_3357547@… |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 It looks like you're censored -- that is, default Tor isn't going to work
 for you.

 You will probably need to use one of the pluggable transports:
 https://www.torproject.org/docs/pluggable-transports

 If you need more help, you might try the support mechanisms:
 https://www.torproject.org/about/contact#support

 (Trac isn't intended for helping users use our programs.)

 Good luck!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24364 [- Select a component]: can not use internet bytor browser

2017-11-20 Thread Tor Bug Tracker & Wiki

#24364: can not use internet bytor browser
--+
 Reporter:  Kua_3357547@… |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 11/21/2017 9:27:52 AM.600 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 11/21/2017 9:28:03 AM.000 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 11/21/2017 9:28:03 AM.000 [NOTICE] Switching to guard context "default"
 (was using "bridges")
 11/21/2017 9:28:03 AM.000 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 11/21/2017 9:28:03 AM.000 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 11/21/2017 9:28:03 AM.000 [NOTICE] Opening Socks listener on
 127.0.0.1:9150
 11/21/2017 9:28:03 AM.100 [NOTICE] Bootstrapped 5%: Connecting to
 directory server
 11/21/2017 9:28:03 AM.200 [NOTICE] Bootstrapped 10%: Finishing handshake
 with directory server
 11/21/2017 9:38:52 AM.100 [WARN] Problem bootstrapping. Stuck at 10%:
 Finishing handshake with directory server. (DONE; DONE; count 10;
 recommendation warn; host 456C1E39B5780CD05267F8EFEF123A2FA8DB7715 at
 79.137.116.43:443)
 11/21/2017 9:38:52 AM.100 [WARN] 10 connections have failed:
 11/21/2017 9:38:52 AM.100 [WARN]  9 connections died in state handshaking
 (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
 11/21/2017 9:38:52 AM.100 [WARN]  1 connections died in state connect()ing
 with SSL state (No SSL object)
 11/21/2017 9:38:55 AM.900 [NOTICE] Closing no-longer-configured Socks
 listener on 127.0.0.1:9150
 11/21/2017 9:38:55 AM.900 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 11/21/2017 9:38:55 AM.900 [NOTICE] Closing old Socks listener on
 127.0.0.1:9150
 11/21/2017 9:38:55 AM.900 [WARN] Problem bootstrapping. Stuck at 10%:
 Finishing handshake with directory server. (DONE; DONE; count 11;
 recommendation warn; host CF6D0AAFB385BE71B8E111FC5CFF4B47923733BC at
 154.35.175.225:443)
 11/21/2017 9:38:55 AM.900 [WARN] 11 connections have failed:
 11/21/2017 9:38:55 AM.900 [WARN]  10 connections died in state handshaking
 (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
 11/21/2017 9:38:55 AM.900 [WARN]  1 connections died in state connect()ing
 with SSL state (No SSL object)
 11/21/2017 9:38:55 AM.900 [NOTICE] Delaying directory fetches:
 DisableNetwork is set.

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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node()

2017-11-20 Thread Tor Bug Tracker & Wiki

#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactor, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by neel):

 I have an updated patch under the filename
 002-node_get_extend_info-r1.patch which makes curve_pubkey a const.

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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node()

2017-11-20 Thread Tor Bug Tracker & Wiki

#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactor, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by neel):

 * Attachment "002-node_get_extend_info-r1.patch" added.

 Patch to introduce node_get_curve25519_onion_key() in
 extend_info_from_node() (Revision 1)

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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node()

2017-11-20 Thread Tor Bug Tracker & Wiki

#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactor, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  new => needs_revision


Comment:

 Hi neel, thanks for the patch!

 node_get_curve25519_onion_key() returns a const pointer, so the variable
 also has to be const. Otherwise, some compilers will complain.

 The rest of the patch looks good!

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

2017-11-20 Thread Tor Bug Tracker & Wiki

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Cloudflare and Incapsula. Both HTTP/HTTPS connections to them needs to be
 blocked as MiTM attack against TBB.

 https://www.incapsula.com/

 Not many use Incapsula though. Most of their customers moved to Cloudflare
 because of price and popularity. And we the tor users are blocked to read
 their site. Such a shame LOL

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

2017-11-20 Thread Tor Bug Tracker & Wiki

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 @same guy,
 Using cloudflare means all traffic route to cloudflare. This is not just
 about free HTTPS.
 HTTP connection to cloudflare and HTTPS connection to cloudflare, both are
 fucked up.

 "If you're using their free cache, proxy, certificate service, YOU ARE THE
 PRODUCT."



 @nullius,
 I have no argue with that - you wrote what I wanna write.

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

2017-11-20 Thread Tor Bug Tracker & Wiki

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Hi,

 Thanks for this revision!

 Replying to [comment:21 callumw]:
 > Thanks for the advice regarding the header files. I moved the function
 to address.c as you recommended and that resolved the issue.
 >
 > I have attached a new patch file with the new function implementation
 in. The first test under 'make check' fails but this behaviour can be
 replicated in a newly checkout-out repo so I assume it is unrelated to my
 changes here.

 `make check-spaces` will fail due to this line:
 {{{
 if(getsockname(sock, (struct sockaddr *), _len) < 0){ return
 -1; }
 }}}

 We have a coding style that puts spaces between `if` and `(`, and `)` and
 `{` and we typically have `if` blocks on multiple lines. Try to match the
 existing coding style, and run `make check-spaces` to confirm.

 Code review:

 I think we'd be ok with adding .vimrc to .gitignore, but we would want
 that in a separate commit. Alternately, you can add .vimrc to your own
 ~/.gitignore_global (there's a git config option for a global ignore
 file).

 We don't need to do the MOCK_IMPL/MOCK_DECL on these functions, because
 they're not being mocked in the unit tests.

 We should use tor_getsockname() in tor_addr_from_getsockname(), so we can
 mock tor_getsockname() in the unit tests if we need to.

 tor_addr_from_sockaddr() returns a port in port_out. So `uint16_t
 port_num` needs to be a pointer, and should probably be called something
 like `port_out`. Similarly, `tor_addr_t *tor_addr` should probably be
 called `addr_out`. And our convention is to put `out` parameters at the
 end of the argument list.

 The function needs a comment that describes what each argument does, and
 what the return value is. You can use the one on tor_addr_from_sockaddr()
 as an example.

 Next Steps:

 Once we introduce this function, we can use it to replace code that calls
 [tor_]getsockname() then tor_addr_from_sockaddr().

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

Re: [tor-bugs] #24348 [Internal Services/Service - lists]: Please make tor-packagers@ list

2017-11-20 Thread Tor Bug Tracker & Wiki

#24348: Please make tor-packagers@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by atagar):

 Hi Jens. It'll be a moderated list of package maintainers for debian,
 gentoo, freebsd, etc where developers can notify package maintainers of
 new releases or pitch for their project to be packaged.

 Honestly I'm struggling a bit to come up with a good description. Maybe
 "Platform specific package maintainers (debs, rpms, etc)."?

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

Re: [tor-bugs] #24316 [Applications/Tor Browser]: Tor Browser doesn't filter ads anymore?

2017-11-20 Thread Tor Bug Tracker & Wiki

#24316: Tor Browser doesn't filter ads anymore?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 (this is indeed Tails specific and ublock works outside of the way it's
 installed in Tails, so this should remain closed but for completeness:

 On Tails it seems to be related to the version of ublock shipped with
 debian stretch, installing it from the debian sid repos during the build
 process seems to resolve this issue, at least in my test 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] #24228 [Core Tor/Tor]: Tor keeps on creating new circuits even when it's idle

2017-11-20 Thread Tor Bug Tracker & Wiki

#24228: Tor keeps on creating new circuits even when it's idle
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, regression, |  Actual Points:
  backport-031   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Replying to [comment:13 asn]:
 > Replying to [comment:10 mikeperry]:
 > > The goal is to learn a circuit build timeout within 30 minutes, so
 that unused orconn connections aren't padded for too long while we learn
 this timeout (which wastes bandwidth for clients that want less padding).
 It sounds like we may actually learn it within 10. We could make this 3X
 slower I suppose.
 > >
 > > But I don't really think new clients are going to put that much of a
 strain on the network with this. The ntor handshake completes in tens of
 microseconds, IIRC. And the rate of new clients arriving is not that high.
 >
 > Hmm, not sure if it's just new clients. IIRC, CBT is per-guard, so when
 a client switches to a new guard (or its current guard gets
 offline/unreachable), it will start learning CBT of its next guard, aka
 destroy and create tons of idle circs over time.

 CBT is not per-guard. I first wrote it back when we used 3 guards, and
 does not associate any state with a guard id. It is only reset if you time
 out 18 out of 20 circuits in a rolling window. Otherwise it just gradually
 adjusts to changes like this.

 Maybe you were confusing it with path bias? That info is per guard.

 > Why is it important to learn CBT fast? What would happen if we learned
 CBT over a longer period of time, and used a bigger idle timeout value so
 that we don't destroy so many idle circuits?

 As I said to Catalyst, and in my previous comments, I lowered the CBT
 learning time so that we don't waste client battery and bandwidth on
 padding while keeping client connections opened for huge amounts of time
 while building test circuits. We're talking about the cost of crypto ops
 that take microseconds to complete vs the overhead of radio activity, CPU
 wake time, and bandwidth costs for keeping padded connections opened for
 *hours*.

 > Alternatively, perhaps we could disable the predictive circuit building
 while we area learning CBT for a guard? Or is this too much effort?

 I don't think this accomplished what we want. Again, the point is to get
 the circuit building out of the way quickly, so we don't waste resources
 on keeping connections opened forever (and needlessly padding them during
 that time).

 That said, 10 minutes *is* 3X faster than we really need. We could lower
 this by a factor of three and still get it done inside of the connection
 idle time for reduced padding clients.

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

Re: [tor-bugs] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

2017-11-20 Thread Tor Bug Tracker & Wiki

#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25|
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_revision => 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] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

2017-11-20 Thread Tor Bug Tracker & Wiki

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25|
Parent ID:  #23100   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * status:  needs_revision => 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] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node()

2017-11-20 Thread Tor Bug Tracker & Wiki

#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactor, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by neel):

 I have a patch to resolve this. The filename is
 001-node_get_extend_info.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] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node()

2017-11-20 Thread Tor Bug Tracker & Wiki

#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
+
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  refactor, easy  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by neel):

 * Attachment "001-node_get_extend_info.patch" added.

 Patch to introduce node_get_curve25519_onion_key() in
 extend_info_from_node()

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

Re: [tor-bugs] #24348 [Internal Services/Service - lists]: Please make tor-packagers@ list

2017-11-20 Thread Tor Bug Tracker & Wiki

#24348: Please make tor-packagers@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by qbi):

 Would it be possible to come up with another/better description? What
 will/should be discussed/announced 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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

2017-11-20 Thread Tor Bug Tracker & Wiki

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nullius):

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


Comment:

 Replying to [comment:7 cypherpunks]:
 > You can't tell unless you have access to a site owner's Cloudflare
 account whether they have full SSL with Cloudflare or whether Cloudflare
 is MiTMing them, so this doesn't seem possible.

 Either you are obfuscating, or you are technologically incompetent.  Quick
 proof:  Assume the opposite.  If Cloudflare did not act as a MITM proxy
 with full, active access sufficient to read ''and modify'' TLS plaintext
 of all connections passing through them, then they would be unable to
 inject the HTTP headers which this bug proposes to detect for blocking.
 [Sequential dotted initials “Q.”, “E.”, “D.” forbidden by Trac spam
 filter.]

 Cloudflare is a MITM, ''by design''.  That is the primary (only?) service
 they offer.  It does not matter what the site’s service level with them
 is.  From the connecting user-agent’s perspective (here apropos), it does
 not even matter if the site uses its
 [https://web.archive.org/web/20171118213855/https://blog.cloudflare.com
 /keyless-ssl-the-nitty-gritty-technical-details/ so-called “keyless SSL”]
 service to preserve secrecy of its ''long-term'' private keys.  Cloudflare
 always, always has the symmetric key to the session; and within the
 ostensibly encrypted session, Cloudflare is by definition a Man-In-The-
 Middle which decrypts, modifies, and proxies the plaintext.

 Why, it is exactly as if Cloudflare were designed as a mass surveillance
 tool!  So, what rationalizations could be supposed for those who use their
 services, or ignore them as a global threat?

 “But Cloudflare is a trustworthy provider of Internet infrastructure.”
 Then, why do we need TLS at all?  Just make peering arrangements with
 trustworthy networks who agree to pass your packets only through
 trustworthy routers!  TLS eliminates trust in the network:  By design, TLS
 promises end-''to-end'' encryption.  Meaning, with the ''endpoint''.  By
 design, Cloudflare makes a mockery of this promise.

 “But most sites are on third-party hardware, anyway.”  Irrelevant:
 Cloudflare centralizes trust.

 Without the Cloudflare MITM proxy, `little-newbie-web-shop.com`’s TLS is
 handled by `cheap-shared-web-host.com`; `chic-trendy-cloud-buzzword-
 startup.com`’s TLS is handled by AWS; `at-risk-controversial-activism.org`
 and `high-security-bitcoin-services.com` should (we hope) do all their
 crypto on hardware under their respective owners’ physical control.  The
 site visitor is responsible for deciding which endpoints to trust with
 private information.  (N.b.:  Reading interests and “clicktrails” are
 private information.)  When all these sites sign up for Cloudflare, then
 Cloudflare becomes the one-stop decryption shop.  Do you trust Cloudflare
 to ''be'' the “secure” Internet, or some huge proportion thereof?

 Centralizing trust has a much worse effect than allowing access to many
 individual sites:  It creates a single point at which to perform mass
 dragnet surveillance.  As of today, Cloudflare has access to the plaintext
 data of more TLS sessions to more endpoints than anybody else on
 Earth.![1]  Here, the whole is more than the sum of the parts:  They are
 in a position to track, tap, ''and link'' Internet activity across a wide
 range of sites.  This is why they have been declared a [ticket:18361
 Global Active Adversary].

 If I were the NSA or another TLA, and I sat down to design a mass-
 interception network to MITM TLS on a large portion of the Internet, then
 the result would look exactly like Cloudflare.  They are in a position
 where they in fact do intercept the communications of billions of people
 with millions of websites.  That is not a hypothetical:  It is a
 description of what they actually do—every day, ''right now''.  Then, they
 cross their fingers and promise to respect people’s privacy.  “Trust us;
 we will make you ‘safer’.”  Again—why use any encryption at all?

 On that level, Cloudflare is even worse than “key escrow” or another
 backdoor

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

2017-11-20 Thread Tor Bug Tracker & Wiki

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, I did a really simple untested implementation of the backend
 functions.  It turned out not to actually need any refactoring, which is
 good, because that code is a mess. :)

 It's in a branch `rust_log_backend` in my public repository, and it should
 be a good basis to build on.

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

Re: [tor-bugs] #23709 [Core Tor/Tor]: channel: `outgoing_queue` and `incoming_queue` are always empty

2017-11-20 Thread Tor Bug Tracker & Wiki

#23709: channel: `outgoing_queue` and `incoming_queue` are always empty
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  High  |  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:  SponsorV
--+

Comment (by dgoulet):

 On going work is in: `ticket23709_033_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] #24342 [Core Tor]: Various spec fixes to dir-spec, rend-spec-v3

2017-11-20 Thread Tor Bug Tracker & Wiki

#24342: Various spec fixes to dir-spec, rend-spec-v3
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by filippo):

 It would disrupt v3 HS across versions, but it wouldn't impact their
 addresses. I'm happy either way. Seems to be a decision above my pay
 grade.

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

Re: [tor-bugs] #24327 [Metrics/ExoneraTor]: Sort results under technical details by timestamp and, if necessary, by fingerprint

2017-11-20 Thread Tor Bug Tracker & Wiki

#24327: Sort results under technical details by timestamp and, if necessary, by
fingerprint
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Moving the sorting code to `QueryServlet` sounds good to me. Good point
 about also having to implement `equals()` and so on, that's not really
 what we want here. Changed in a subsequent commit in the same branch.

 Regarding your question about the reason for moving sorting from the
 database to Java, I can't give you a definite answer. We changed a few
 things when combining multiple database queries into one. The new code did
 not require ordered query results in order to produce correct output, and
 it still does not. We took out the ORDER BY statements, because that was
 easier than replacing numbers with names. We just overlooked that this
 would affect the order of entries in the technical results. Now, we could
 put the sorting back to the database, but then we'd have to find a way to
 use column names rather than numbers, and I didn't find an easy way to do
 that with all the UNIONs. I'd say it's simply easier to sort things in the
 servlet.

 I also agree that tests would be great. I even spent some time thinking
 about testing this in `QueryResponseTest` until realizing that it should
 rather be tested in a new `QueryServletTest`. But writing useful tests for
 `QueryServlet` is not a trivial task and shouldn't delay merging this
 bugfix.

 Please take another look at
 [https://gitweb.torproject.org/user/karsten/exonerator.git/log/?h=task-24327
 task-24327 branch]. If this looks okay to you, I'll squash and merge
 tomorrow.

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

Re: [tor-bugs] #24095 [Webpages/Website]: Add press clips to website

2017-11-20 Thread Tor Bug Tracker & Wiki

#24095: Add press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by steph):

 * Attachment "Press clips for website - 2017 - new (1).csv" added.

 newest

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 Thanks for the upload!  I've cherrypicked the fix onto `bug23817_031`, and
 re-merged that into 0.3.2 and forward.  Calling that a backport candidate
 again.

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

Re: [tor-bugs] #24275 [Webpages/Website]: Testing Lecktor as a possible framework to be used for all portals related to website redesign project

2017-11-20 Thread Tor Bug Tracker & Wiki

#24275: Testing Lecktor as a possible framework to be used for all portals 
related
to website redesign project
--+--
 Reporter:  isabela   |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #21222| Points:
 Reviewer:|Sponsor:
--+--

Comment (by t0mmy):

 o/

 I just spent some time tinkering with Lektor -- it seems like a good way
 of editing the site! I haven't tinkered with oniongit yet because I need
 an account, but I got Lektor up and running!

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

Re: [tor-bugs] #23783 [Core Tor/Tor]: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7

2017-11-20 Thread Tor Bug Tracker & Wiki

#23783: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7
-+-
 Reporter:  Bizarre™ |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  0.3.2.2-alpha-blogpost-bugreport,|  Actual Points:
  windows, mingw |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 dgoulet says "looks plausible", so merging into maint-0.3.2.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24363 [Core Tor/Tor]: Remove /usr/athena from search path in configure.ac

2017-11-20 Thread Tor Bug Tracker & Wiki

#24363: Remove /usr/athena from search path in configure.ac
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It may have made sense to use this directory in 2002, but even MIT project
 Athena systems don't have it any more, I'm told.

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

Re: [tor-bugs] #22871 [Obfuscation/BridgeDB]: Implement backend for moat

2017-11-20 Thread Tor Bug Tracker & Wiki

#22871: Implement backend for moat
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  enhancement   | Status:  closed
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-captcha  |  Actual Points:  5
Parent ID:| Points:  3
 Reviewer:|Sponsor:  SponsorM
--+--
Changes (by isis):

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


Comment:

 This was deployed last week but there's some issues with the all the
 tunneling through meek and apache that still need to be 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] #13589 [Core Tor/Tor]: bridge authority could do bandwidth test along with reachability test

2017-11-20 Thread Tor Bug Tracker & Wiki

#13589: bridge authority could do bandwidth test along with reachability test
-+-
 Reporter:  arma |  Owner:  isis
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-bridge, tor-bridgeauth,  |  Actual Points:
  measuring bandwidth|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by isis):

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


Comment:

 This is currently being implemented as an external (Rust) program by an
 intern, which seems safer than doing more HTTP fetches and servers in C.
 Closing for now, but feel free to reopen if we really want the tor process
 on the BridgeAuth to do the bandwidth testing.

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

Re: [tor-bugs] #1839 [Obfuscation/BridgeDB]: Rotate available bridges over time

2017-11-20 Thread Tor Bug Tracker & Wiki

#1839: Rotate available bridges over time
---+
 Reporter:  arma   |  Owner:  isis
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/BridgeDB   |Version:
 Severity:  Blocker| Resolution:  fixed
 Keywords:  bridgedb-dist, bridgedb-0.3.2  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by isis):

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


Comment:

 The above comment on subhashrings should be a different ticket, if/when we
 decide to do 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] #23596 [Obfuscation/BridgeDB]: BridgeDB does not give out bridges but complains with "Processing Failed"

2017-11-20 Thread Tor Bug Tracker & Wiki

#23596: BridgeDB does not give out bridges but complains with "Processing 
Failed"
--+
 Reporter:  gk|  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by isis):

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


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

Re: [tor-bugs] #23953 [Core Tor/Tor]: Use stdatomic counters where available

2017-11-20 Thread Tor Bug Tracker & Wiki

#23953: Use stdatomic counters where available
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-25  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 * The destroy function, can't we just NOP it instead of doing this
 function call that I think the compiler will never optimize out because of
 this `(void)` thing?

 {{{
 +void
 +atomic_counter_destroy(atomic_counter_t *counter)
 +{
 +  (void)counter;
 +}
 }}}

 Into something like:

 {{{
 #define atomic_counter_destroy(c)
 }}}

 Second thing, in terms of performance, shouldn't those be better as
 `static inline`? I'm not sure how much they are used in Tor but if it is a
 _lot_, that could help a bit instead of a function jump.

 One last tiny thing, if you could put the comment in the #else and #endif,
 it would be grand!

 {{{
 #ifdef HAVE_STDATOMIC_H
 ...
 #else /* HAVE_STDATOMIC_H */
 ...
 #endif /* HAVE_STDATOMIC_H */
 }}}

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

Re: [tor-bugs] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+

Comment (by dgoulet):

 Oh true, it is "artificial" there. Fair enough, patch lgtm;

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

Re: [tor-bugs] #23783 [Core Tor/Tor]: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7

2017-11-20 Thread Tor Bug Tracker & Wiki

#23783: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7
-+-
 Reporter:  Bizarre™ |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  0.3.2.2-alpha-blogpost-bugreport,|  Actual Points:
  windows, mingw |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_review


Comment:

 I have a quick branch for review as `bug23783`.

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

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox incompatible with glibc 2.26 (openat() not handled for all our files)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24315: sandbox incompatible with glibc 2.26 (openat() not handled for all our
files)
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 After review and testing from dgoulet, merging this to 0.3.2 and forward;
 marking for possible backport.

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

Re: [tor-bugs] #24198 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall kill)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24198: (Sandbox) Caught a bad syscall attempt (syscall kill)
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 030-backport|  Actual Points:
  030-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 After initial review, and testing from dgoulet, merging this to 0.3.2 and
 forward; marking for possible backport.

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

Re: [tor-bugs] #24360 [Core Tor/Nyx]: When I open nyx and then Immediately click "qq" it will get in a state where nix disappears

2017-11-20 Thread Tor Bug Tracker & Wiki

#24360: When I open nyx and then Immediately click "qq" it will get in a state
where nix disappears
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:2 atagar]:
 > Thanks Dbryrtfbcbhgf, definitely sounds funky. Just tried several times
 to reproduce this but couldn't. Please run 'nyx --debug', reproduce the
 issue, and attach the debug log with anything you consider sensitive
 stripped out. Not sure if it'll help, but the next step to see if I can
 spot what's up.
 When I run the command I keep getting this error.
 nyx --debug
 option --debug requires argument (for usage provide --help)
 I installed nyx using "pip install nyx"

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 (If not, please let me know where to find them.)

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Did you forget to upload these 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] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+

Comment (by Hello71):

 {{{
 /** Try to create a memory mapping for filename and return it.  On
  * failure, return NULL.  Sets errno properly, using ERANGE to mean
  * "empty file". */
 tor_mmap_t *
 tor_mmap_file(const char *filename)
 }}}

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

Re: [tor-bugs] #23840 [Community/Outreach]: Cloudflare and Google Captcha failed 100%

2017-11-20 Thread Tor Bug Tracker & Wiki

#23840: Cloudflare and Google Captcha failed 100%
+--
 Reporter:  cypherpunks |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Immediate   |  Milestone:
Component:  Community/Outreach  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by indigotime):

 "New Tor Circuit for this Site" keeps current cookies, including
 cloudflare/recaptcha cookies. Cloudflare and Google can use cookies to
 detect (and blacklist) new Tor exit nodes.

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

Re: [tor-bugs] #24360 [Core Tor/Nyx]: When I open nyx and then Immediately click "qq" it will get in a state where nix disappears

2017-11-20 Thread Tor Bug Tracker & Wiki

#24360: When I open nyx and then Immediately click "qq" it will get in a state
where nix disappears
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Thanks Dbryrtfbcbhgf, definitely sounds funky. Just tried several times to
 reproduce this but couldn't. Please run 'nyx --debug', reproduce the
 issue, and attach the debug log with anything you consider sensitive
 stripped out. Not sure if it'll help, but the next step to see if I can
 spot what's up.

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

Re: [tor-bugs] #20699 [Core Tor/Tor]: prop224: Add control port events and commands

2017-11-20 Thread Tor Bug Tracker & Wiki

#20699: prop224: Add control port events and commands
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, needs-proposal,  |  Actual Points:
  prop224-extra, tor-control, prop284|
Parent ID:   | Points:  6
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * keywords:  tor-hs, needs-proposal, prop224-extra, tor-control => tor-hs,
 needs-proposal, prop224-extra, tor-control, prop284
 * status:  accepted => needs_review


Comment:

 This is pretty massive that is 25 commits but I think well separated and
 each of them aren't that big.

 Branch: `ticket20699_033_01`
 OnionGit: https://oniongit.eu/dgoulet/tor/merge_requests/10

 As discussed earlier in this ticket, `HSFETCH` is not implemented for now.
 It follows proposal 284 (see spec 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] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

2017-11-20 Thread Tor Bug Tracker & Wiki

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+--
 Reporter:  Zakhar|  Owner:  (none)
 Type:  enhancement   | Status:  assigned
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  docs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

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


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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

2017-11-20 Thread Tor Bug Tracker & Wiki

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 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:
--+

Comment (by nickm):

 (On IRC, catalyst suggested that we should globally upcase these macros
 and any other magic macros that don't behave like C functions.  I agree;
 let's do that in another 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] #24361 [Applications/rbm]: rbm gives an error if a build script contains a wide character

2017-11-20 Thread Tor Bug Tracker & Wiki

#24361: rbm gives an error if a build script contains a wide character
+--
 Reporter:  boklm   |  Owner:  boklm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/rbm|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201712R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  new => needs_review
 * keywords:  tbb-rbm, TorBrowserTeam201712 => tbb-rbm,
   TorBrowserTeam201712R


Comment:

 The branch `bug_24361` in my git repo has a patch to fix this:
 
https://gitweb.torproject.org/user/boklm/rbm.git/commit/?h=bug_24361=134cad4e79471d7baa82f00b4a6e2d7f7d11868a

 This change should not modify the sha256sum of build scripts which do not
 contain any wide character. I checked that the `var/build_id` value (which
 is doing a `sha256` on the build script and all dependencies) reported by
 the following commands is identical with and without the patch:
 {{{
 ./rbm/rbm showconf --target alpha --target torbrowser-linux-x86_64 tor-
 browser var/build_id
 ./rbm/rbm showconf --target alpha --target torbrowser-windows-x86_64 tor-
 browser var/build_id
 ./rbm/rbm showconf --target alpha --target torbrowser-osx-x86_64 tor-
 browser var/build_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] #2878 [Core Tor/Tor]: Don't bootstrap from an old consensus if we're about to replace it

2017-11-20 Thread Tor Bug Tracker & Wiki

#2878: Don't bootstrap from an old consensus if we're about to replace it
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  performance, bootstrap, tor-client,  |  Actual Points:
  s8-performance, s8-errors  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * keywords:  performance, bootstrap, tor-client, sponsor8-maybe =>
 performance, bootstrap, tor-client, s8-performance, s8-errors
 * sponsor:   => Sponsor8-can


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

Re: [tor-bugs] #24119 [Core Tor/Tor]: channel_rsa_id_group_set_badness spends a lot of time in malloc/free

2017-11-20 Thread Tor Bug Tracker & Wiki

#24119: channel_rsa_id_group_set_badness spends a lot of time in malloc/free
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-channel, tor-sched,  |  Actual Points:
  032-backport, review-group-25  |
Parent ID:  #23777   | Points:
 Reviewer:  isis |Sponsor:
 |  Sponsor8-can
-+-
Changes (by isis):

 * reviewer:   => isis
 * sponsor:   => Sponsor8-can


Comment:

 Calling this a Sponsor8 because resource consumption effects mobile; feel
 free to change if there's a better 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] #24086 [Core Tor/Tor]: consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failed

2017-11-20 Thread Tor Bug Tracker & Wiki

#24086: consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion
!(ent->entry == NULL) failed
--+
 Reporter:  cypherpunks   |  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.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by ahf):

 * reviewer:   => ahf


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

Re: [tor-bugs] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by ahf):

 * reviewer:   => ahf


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

Re: [tor-bugs] #23953 [Core Tor/Tor]: Use stdatomic counters where available

2017-11-20 Thread Tor Bug Tracker & Wiki

#23953: Use stdatomic counters where available
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-25  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

 * reviewer:   => dgoulet


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2017-11-20 Thread 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):

 There is a patch branch of metrics-web available now on ticket #24175.  It
 is not completely finished yet, but usable for web testing and looking at
 how to integrate a new module, see
 [https://trac.torproject.org/projects/tor/ticket/24175#comment:2
 #24175#comment:2] for more details especially //How to test web related
 things and new modules//.

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

Re: [tor-bugs] #24362 [Core Tor/Tor]: Add logging backend for Android

2017-11-20 Thread Tor Bug Tracker & Wiki

#24362: Add logging backend for Android
--+
 Reporter:  ahf   |  Owner:  ahf
 Type:  enhancement   | Status:  assigned
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:
 Keywords:  s8|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8
--+
Changes (by ahf):

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


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

[tor-bugs] #24362 [Core Tor/Tor]: Add logging backend for Android

2017-11-20 Thread Tor Bug Tracker & Wiki

#24362: Add logging backend for Android
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor |   Keywords:  s8
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8  |
--+
 On some devices the Android platform will send messages send to the
 classical Unix syslog service to Android's ringbuffer log that can be read
 via a USB cable with the `adb` tool.

 Since we are unsure if *every* Android device does this automatic
 conversion from Syslog to Android's logging system, it might make sense to
 have an "Log  android" line for `torrc` like we currently have
 with "Log  syslog" in the case we have a technical user with a
 device that does NOT send syslogs to the Android log who found, or is
 willing to debug, some issues for us.

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

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

2017-11-20 Thread 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:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please find a first [https://gitweb.torproject.org/user/iwakeh/metrics-
 web.git/log/?h=task-24175 patch branch].
 There is only one commit as this consists in moving files around,
 replacing scripts accordingly etc., all in all nothing that can be easily
 done incrementally.
 Please test thoroughly and with some more data than I have available with
 some emphasis on the R related functionality.

 == What changed
 Major changes are the move to an embedded Jetty and finally the move to
 using metrics-base only.
 For the latter, the interim step ([https://gitweb.torproject.org/metrics-
 web.git/commit/shared/build-
 base.xml?id=40d3d39361d513c083aa0f871afc518371e18be5 from a year ago]) of
 first making all modules use a common build environment really helped with
 the current step to finally apply Metrics' java structure and use metrics-
 base.

 I'm also going for a two-step-solution for configuration and operation
 issues here:
 The current patch replaces all operational/deployment bash scripts with
 ant tasks and keeps the overall directory structure, as well as the
 current configuration situation, i.e., this patch is taylored to the
 current deployment server and not yet to easy test configuration, which is
 tackled in ticket #24328.
 I didn't change any package names nor script (R, sql, python) names nor do
 we have a consistent logging approach as these are all new tickets:
 #24328, #24329, #24330, (and the ticket for moving ernie and renaming
 packages, need to look up the number).

 == Comparison to the old situation:
 `ant run-web-prepare` is the former `run-web.sh`.
 The scripts from `shared/bin` are replaced by ant tasks: advbwdist,
 connbidirect, hidserv, clients, legacy, onionperf, webstats, collectdescs.
 Task `make-data-available` copies everything as the earlier script `99
 -copy-stats-files.sh`.
 The R server start.sh is replaced by `ant run-rserver`.
 The various modules run in their own sub-folders (if not changed in
 build.xml these will be generated/modules/ and logging for the
 logback parts happens to generated/modules/logs/...).

 `ant legacy-create-config` copies the legacy config template to
 `${basedir}/legacy.config`, which is used by `ant legacy` as config file.
 This is just because I found it, but it shouldn't be this way, discussion
 about such topics are referred to ticket #24328.

 The creation of metrics-lib's javadoc has its own sub-task, which is
 called as part of the war file creation.


 == How to test web related things and new modules:
 It is not necessary to run all modules nor to start an R server.
 The war should run fine locally using `java  -DLOGBASE=logs -jar
 generated/dist/metrics-web-1.0.0-dev.war` and then open 127.0.0.1:8080 in
 a browser, of course no graphs or tables will be supplied.


 == Open topic
 On a fresh installation with only current data running detection.py only
 generates an empy (except for the header) userstats-ranges.csv, which
 prevents further processing.
 Also, many other tasks take ages to complete on a fresh system and the
 chain of deployment in build.xml needs some tweaking.
 Please, take a closer look and improve during this first round.

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

Re: [tor-bugs] #24062 [Core Tor/Tor]: CPU profiling of Tor on Android device

2017-11-20 Thread Tor Bug Tracker & Wiki

#24062: CPU profiling of Tor on Android device
+
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  s8-perf, s8-201710  |  Actual Points:
Parent ID:  #24061  | Points:
 Reviewer:  |Sponsor:  Sponsor8
+
Changes (by ahf):

 * status:  assigned => needs_review


Comment:

 Added some simpleperf instructions in
 https://gitlab.com/ahf/tor/merge_requests/21

 Please don't close this ticket when this is pushed to `tor.git`.

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

Re: [tor-bugs] #20628 [Applications/Tor Browser]: More locales for Tor Browser

2017-11-20 Thread Tor Bug Tracker & Wiki

#20628: More locales for Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton, tbb-easy, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by kscanne):

 Just adding a note to ensure that our Irish translation (ISO 639 "ga")
 doesn't fall through the tracks, since we're not included in the list of
 potential locales above.  We're translated/reviewed to 100% in Transifex
 in all Tor projects, and have support in Firefox-ESR (all versions back to
 FF1.0).  Anything I can do to help move this forward?  Even short of a
 full release, a nightly build so we can test the localisation would be a
 big help.

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

Re: [tor-bugs] #24062 [Core Tor/Tor]: CPU profiling of Tor on Android device

2017-11-20 Thread Tor Bug Tracker & Wiki

#24062: CPU profiling of Tor on Android device
+
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  s8-perf, s8-201710  |  Actual Points:
Parent ID:  #24061  | Points:
 Reviewer:  |Sponsor:  Sponsor8
+

Comment (by ahf):

 https://people.torproject.org/~ahf/sponsor8/ contains data from both
 bootstrap (clean data directory when starting Tor for the first time) and
 some samples from downloading a large file via Tor on an already
 bootstrapped client.

 Patch coming up with some documentation on how to read and analyse the
 `perf.data` files.

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:52 nickm]:
 > So, `num_reachable_filtered_guards()` is O(N) in the total number of
 guard nodes in the network; I don't think we want to re-run it for every
 guard that we check in `guard_obeys_md_dirserver_restriction`, or this
 will be an O(N^2^) computation.

 Thanks for pointing this out. I think my idea of moving the guard-size
 check on restriction enforcing time, instead of keeping it at restriction
 creation time was a bad one.

 The guard restriction is applied on the `circuit_guard_state_t` which gets
 applied on the `dir_connection_t` so everytime we want to fetch new mds we
 will do the guard-size check and create a new restriction, which works
 fine with the current design, so no need to change it.

 I have two new branches with annoying names:
 `bug23817_usable_filtered_033_v2` and `bug23817_usable_filtered_032_v2`
 which should be the minimal change here.

 Let me know how you feel about this 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] #24361 [Applications/rbm]: rbm gives an error if a build script contains a wide character

2017-11-20 Thread Tor Bug Tracker & Wiki

#24361: rbm gives an error if a build script contains a wide character
---+---
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component: |Version:
  Applications/rbm |
 Severity:  Normal |   Keywords:  tbb-rbm, TorBrowserTeam201712
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 When a build script contains a wide character, rbm fails with the
 following error:
 {{{
 Error: Template Error:
 undef error - Wide character in null operation at input text line 1.
 }}}

 The reason is that in `var/build_id`, we call `sha256` on the content of
 the build script, which is using the `sha256_hex` function, which doesn't
 support wide characters:
 http://perldoc.perl.org/Digest/SHA.html#UNICODE-AND-SIDE-EFFECTS

 We currently don't use any build script with wide character in `tor-
 browser-build`. However the file `projects/tor-browser/RelativeLink/start-
 tor-browser` does contain a wide character (curly quotes: ”), which is a
 problem if we want to use it as a template (for #21998).

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

2017-11-20 Thread Tor Bug Tracker & Wiki

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 Replying to [comment:5 nickm]:
 > So my first thought is to take this approach:
 >* Refactor the C a bit, though, so that there is a tor_log_string()
 function taking a severity, domain, and message.  It should work the same
 as `tor_log(severity, domain, message);`, but instead it should be safe to
 call it function with strings containing `%`.  (I can write this one if
 you want: it will involve refactoring `logv` a little.

 This sounds great- I was hesitant to add a bunch of functionality to Rust
 just to make it compatible with the existing C api. If you have time to do
 this, that would be great! Otherwise I can take a stab at it this week.

 >* Expose that function to rust.
 >* Write a single rust macro that takes severity, domain, message, and
 some format arguments, and uses the `format!` mechanism to generate the
 log message.

 This is approximately what I have, with the ability to optionally compile
 with a no-op implementation (for running tests at the rust module level).

 > Optionally afterwards:
 >* Expose a view of `log_global_min_severity` to rust, maybe via a
 function.
 >* Update the rust macro to compare `log_global_min_severity` to the
 declared severity, and avoid formatting the message if no logs actually
 want it.
 This sounds great- we can do this either in this ticket or an enhancement.

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

Re: [tor-bugs] #24318 [Core Tor/Tor]: Clarify that the RelayBandwidth* options exclude directory fetches by relays

2017-11-20 Thread Tor Bug Tracker & Wiki

#24318: Clarify that the RelayBandwidth* options exclude directory fetches by
relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * Attachment "0001-Clarify-the-RelayBandwidth-options-in-man-file.patch"
 added.


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

Re: [tor-bugs] #24086 [Core Tor/Tor]: consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failed

2017-11-20 Thread Tor Bug Tracker & Wiki

#24086: consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion
!(ent->entry == NULL) failed
--+
 Reporter:  cypherpunks   |  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.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => 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] #24086 [Core Tor/Tor]: consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion !(ent->entry == NULL) failed

2017-11-20 Thread Tor Bug Tracker & Wiki

#24086: consdiffmgr.c:637: consdiffmgr_find_diff_from: Non-fatal assertion
!(ent->entry == NULL) failed
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Okay, I think I have a fix for this.  The problem here is that we were
 mis-handling a partial success from a diff operation -- but that could
 happen if (for example) LZMA failed and the other compressors succeeded.
 (This seems to be happening here.)

 I've got a patch for this in my branch `bug24086_031`.

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

Re: [tor-bugs] #24141 [Core Tor/Tor]: consdiffmgr.c:329: cdm_diff_ht_purge: Non-fatal assertion

2017-11-20 Thread Tor Bug Tracker & Wiki

#24141: consdiffmgr.c:329: cdm_diff_ht_purge: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => closed
 * resolution:   => 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] #24346 [Core Tor/Tor]: prop224: Service stops uploading one of its two descriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#24346: prop224: Service stops uploading one of its two descriptors
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  new => accepted
 * owner:  (none) => dgoulet
 * cc: dgoulet (removed)
 * keywords:  prop224 => prop224, tor-hs


Comment:

 Agree, I've looked at the logs and notice here, the next descriptor stops
 being uploaded:

 {{{
 Nov 16 21:30:21.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 16 22:49:34.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 17 00:23:30.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 17 01:08:16.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 5/3
 introduction points.
 }}}

 And then before 01:08:16, the current is discarded, the next is the new
 current (`current = next`) and we create a new next descriptor. So at that
 point, the current descriptor becomes the one never uploading and the next
 is fine because it is a brand new one. Interestingly enough, this pattern
 comes back hours later...

 I can't tell from the logs why this is happening so as suggested, we need
 to log every failing condition in `should_service_upload_descriptor()` so
 we can have more information on why it is deciding to not upload the
 descriptor...

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

Re: [tor-bugs] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 I'm a bit confused here, `ERANGE` is not documented as an errno value from
 `mmap(2)` both on Linux and FreeBSD. It seems that the range issue is
 handled with:

 {{{
   EINVAL We don't like addr, length, or offset (e.g., they are too large,
 or not aligned on a page boundary).
 }}}

 @Hello71, what is your kernel version here? I've checked (on kernel 4.14)
 and XFS doesn't seem to be returning `ERANGE` in the case of a mmap...

 The fix lgtm; but this `ERANGE` thing is just weird and confusing to me
 from which syscall this can come. The `open()`, `fstat()` and `mmap()`
 don't seem to never return that :S ...

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

Re: [tor-bugs] #24141 [Core Tor/Tor]: consdiffmgr.c:329: cdm_diff_ht_purge: Non-fatal assertion

2017-11-20 Thread Tor Bug Tracker & Wiki

#24141: consdiffmgr.c:329: cdm_diff_ht_purge: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Yeah, it was indeed a duplicate of #24086, but the analysis wasn't easy.
 :)

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

Re: [tor-bugs] #24327 [Metrics/ExoneraTor]: Sort results under technical details by timestamp and, if necessary, by fingerprint

2017-11-20 Thread Tor Bug Tracker & Wiki

#24327: Sort results under technical details by timestamp and, if necessary, by
fingerprint
+
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by iwakeh):

 And, a some tests for this would be great :-)

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

Re: [tor-bugs] #24327 [Metrics/ExoneraTor]: Sort results under technical details by timestamp and, if necessary, by fingerprint

2017-11-20 Thread Tor Bug Tracker & Wiki

#24327: Sort results under technical details by timestamp and, if necessary, by
fingerprint
+
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by iwakeh):

 Is there a particular reason to implement sorting in Java now instead of
 having the db query sort the results?

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

Re: [tor-bugs] #24327 [Metrics/ExoneraTor]: Sort results under technical details by timestamp and, if necessary, by fingerprint

2017-11-20 Thread Tor Bug Tracker & Wiki

#24327: Sort results under technical details by timestamp and, if necessary, by
fingerprint
+
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 As the ordering is simply for sorting the matches for returning them, it
 should rather be given as special comparator argument to the
 Collections.sort method than defining it as the Comparator of the Match
 class.  Defining it as the Comparator with the Match class somewhat
 indicates that this is a natural ordering, which ought be consistent with
 equals, which is not the case and not intended here.  (Of course, from the
 data point of view there shouldn't be matches not differing in the two
 fields used for comparison and differing in other fields of the Match
 class, but that is not always guaranteed.)

 Better to limit the changes to the one place where the sorting is done:
 {{{
 --- a/src/main/java/org/torproject/exonerator/QueryServlet.java
 +++ b/src/main/java/org/torproject/exonerator/QueryServlet.java
 @@ -18,6 +18,7 @@ import java.text.ParseException;
  import java.text.SimpleDateFormat;
  import java.util.ArrayList;
  import java.util.Calendar;
 +import java.util.Collections;
  import java.util.List;
  import java.util.SortedSet;
  import java.util.TimeZone;
 @@ -338,6 +339,15 @@ public class QueryServlet extends HttpServlet {
  }
}
if (!matches.isEmpty()) {
 +Collections.sort(matches,
 +(m1, m2) -> {
 +if (m1 == m2) {
 +  return 0;
 +} else if (!m1.timestamp.equals(m2.timestamp)) {
 +  return m1.timestamp.compareTo(m2.timestamp);
 +} else {
 +  return m1.fingerprint.compareTo(m2.fingerprint);
 +}});
  response.matches = matches.toArray(new QueryResponse.Match[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] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

2017-11-20 Thread Tor Bug Tracker & Wiki

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So my first thought is to take this approach:
* Refactor the C a bit, though, so that there is a tor_log_string()
 function taking a severity, domain, and message.  It should work the same
 as `tor_log(severity, domain, message);`, but instead it should be safe to
 call it function with strings containing `%`.  (I can write this one if
 you want: it will involve refactoring `logv` a little.
* Expose that function to rust.
* Write a single rust macro that takes severity, domain, message, and
 some format arguments, and uses the `format!` mechanism to generate the
 log message.

 Optionally afterwards:
* Expose a view of `log_global_min_severity` to rust, maybe via a
 function.
* Update the rust macro to compare `log_global_min_severity` to the
 declared severity, and avoid formatting the message if no logs actually
 want 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] #24099 [Core Tor/Tor]: tor should remove empty/invalid consensus cache files (Unable to map file from consensus cache: Numerical result out of range)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24099: tor should remove empty/invalid consensus cache files (Unable to map 
file
from consensus cache: Numerical result out of range)
--+
 Reporter:  Hello71   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * keywords:   => 031-backport


Comment:

 Branch `bug24099_031` tries to fix this. Please 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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

2017-11-20 Thread Tor Bug Tracker & Wiki

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 You can't tell unless you have access to a site owner's Cloudflare account
 whether they have full SSL with Cloudflare or whether Cloudflare is
 MiTMing them, so this doesn't seem possible.

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

Re: [tor-bugs] #24033 [Core Tor/Tor]: Require all directory documents to be utf-8

2017-11-20 Thread Tor Bug Tracker & Wiki

#24033: Require all directory documents to be utf-8
+
 Reporter:  nickm   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  rust-wants prop285  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #24265 [Core Tor/Tor]: Fuzz all rust functions that are used by authorities to make sure they match C

2017-11-20 Thread Tor Bug Tracker & Wiki

#24265: Fuzz all rust functions that are used by authorities to make sure they
match C
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  Rust protover fuzz  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #24318 [Core Tor/Tor]: Clarify that the RelayBandwidth* options exclude directory fetches by relays

2017-11-20 Thread Tor Bug Tracker & Wiki

#24318: Clarify that the RelayBandwidth* options exclude directory fetches by
relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  new => needs_review


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

Re: [tor-bugs] #24318 [Core Tor/Tor]: Clarify that the RelayBandwidth* options exclude directory fetches by relays

2017-11-20 Thread Tor Bug Tracker & Wiki

#24318: Clarify that the RelayBandwidth* options exclude directory fetches by
relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by ffmancera):

 Added clarifying information in man file about RelayBandwidthRate and
 RelayBandwidthBurst options that exclude directory fetches by relays.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

2017-11-20 Thread Tor Bug Tracker & Wiki

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 I have been working on this and hopefully will have a patch within the
 week. One thing that has taken some time is deciding which logging
 function to use- on the C side, we have several macros which wrap log_fn_.
 We can implement similar functionality in Rust, or we can create helper
 functions in C- if anyone has arguments for/against either of these, let
 me know.

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

Re: [tor-bugs] #24318 [Core Tor/Tor]: Clarify that the RelayBandwidth* options exclude directory fetches by relays

2017-11-20 Thread Tor Bug Tracker & Wiki

#24318: Clarify that the RelayBandwidth* options exclude directory fetches by
relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy doc  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * Attachment "0001-Clarify-the-RelayBandwidth-options-in-man-file.patch"
 added.


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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

2017-11-20 Thread Tor Bug Tracker & Wiki

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by chelseakomlo):

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


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

Re: [tor-bugs] #20699 [Core Tor/Tor]: prop224: Add control port events and commands

2017-11-20 Thread Tor Bug Tracker & Wiki

#20699: prop224: Add control port events and commands
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, needs-proposal,  |  Actual Points:
  prop224-extra, tor-control |
Parent ID:   | Points:  6
 Reviewer:   |Sponsor:
 |  SponsorR-must
-+-

Comment (by asn):

 Spec patch at `ticket20699_02` LGTM.

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

Re: [tor-bugs] #24311 [Metrics/Atlas]: Incorrect encoding frontent input -> backend request

2017-11-20 Thread Tor Bug Tracker & Wiki

#24311: Incorrect encoding frontent input -> backend request
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Wow, good catch!

 I think we're doing things wrong in at least two places:

 First, Atlas encodes characters using HTML names, for example, `<` as
 ``. But Onionoo does not decode that, and without decoding this is not
 a valid search parameter value. Hence the 400 status code. Is there a way
 for Atlas to encode characters differently or avoid encoding and just
 include characters like `<` in the request to Onionoo? Otherwise we'd have
 to teach Onionoo how to decode HTML names, and I'm not sure whether that's
 even a good idea.

 Second, Oniono does not decode percent-encoded characters in qualified
 search terms, even though it probably should do that. That means that even
 if Atlas sent over a query like
 `https://onionoo.torproject.org/summary?search=contact:%3Cnone%3E`,
 Onionoo wouldn't decode it. It would just return an empty result set,
 because there are no contact lines with `%3Cnone%3E`. That's different
 from the `contact` parameter which is decoded correctly.

 (It might be that we just ran into this issue in #21366, but it seems
 related here, too. So, even if Atlas switches from HTML encoding to
 percent encoding, we'd still have to fix this part in Onionoo.)

 Oh 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] #21366 [Metrics/Onionoo]: Support whitespace in search term (as does Onionoo)

2017-11-20 Thread Tor Bug Tracker & Wiki

#21366: Support whitespace in search term (as does Onionoo)
-+---
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  reopened
 Priority:  Medium   |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 See https://trac.torproject.org/projects/tor/ticket/24311#comment:1 for a
 possible explanation what went wrong.

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => 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] #24339 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall mprotect)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24339: (Sandbox) Caught a bad syscall attempt (syscall mprotect)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Only libasan, yes.

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

Re: [tor-bugs] #24340 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall prctl)

2017-11-20 Thread Tor Bug Tracker & Wiki

#24340: (Sandbox) Caught a bad syscall attempt (syscall prctl)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox, libasan  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Yes libasan specific... We could also just call it "not supported with
 libasan" and be done with this ticket? :)

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

Re: [tor-bugs] #24342 [Core Tor]: Various spec fixes to dir-spec, rend-spec-v3

2017-11-20 Thread Tor Bug Tracker & Wiki

#24342: Various spec fixes to dir-spec, rend-spec-v3
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Concerning commit
 
https://github.com/FiloSottile/torspec/commit/73f26437470e4b4b360a484daaa1ce94efad317f
 ... I wonder if we should actually patch that upstream in tor. It has been
 released in tor-0.3.2.1-alpha so not stable yet. We could just fix that
 mistake right now and be done with 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] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

2017-11-20 Thread Tor Bug Tracker & Wiki

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, 031-backport,   |  Actual Points:
  030-backport   |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by nickm):

 * keywords:  prop224, tor-hs => prop224, tor-hs, 031-backport, 030-backport
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 Okay.  So, I've rebased it onto 0.2.9 (since if I understand you right,
 that's as far as we might ''ever'' want to backport) and squashed it as
 `bug23681_029_01_squashed`.  Only taking it in 0.3.2 and later for now
 though.  (Merging to 0.3.2 and forward!)

 (Git note: From a git convenience POV, it's easiest to have a branch
 that's based on the earliest convenient* version that we think we might
 want to backport onto.  That way, I can merge the branch to 0.3.2 now, and
 then later either merge the branch to 0.3.1 or 0.2.9 or not.)

 ([*] Of course, this isn't a good idea when the code has changed a lot
 between branches.  If there are huge conflicts, it makes sense to do
 separate 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] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

2017-11-20 Thread Tor Bug Tracker & Wiki

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 So, `num_reachable_filtered_guards()` is O(N) in the total number of guard
 nodes in the network; I don't think we want to re-run it for every guard
 that we check in `guard_obeys_md_dirserver_restriction`, or this will be
 an O(N^2^) computation.

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

Re: [tor-bugs] #24358 [Applications/Tor Browser]: flex error 32 linux build??? binutils

2017-11-20 Thread Tor Bug Tracker & Wiki

#24358: flex error 32 linux build??? binutils
--+--
 Reporter:  fedora0penchaos@… |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

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


Comment:

 This is probably caused by some changes you made. Please reopen if it
 happens with unmodified `tor-browser-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] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

2017-11-20 Thread Tor Bug Tracker & Wiki

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+

Comment (by dgoulet):

 Replying to [comment:15 nickm]:
 > Should we consider a backport for this, or  is it too minor and/or too
 risky?

 I'm a bit puzzled about a backport. It has some inconvenience in terms of
 usability but doesn't break the HS feature per-se. I think I would be more
 comfortable keeping that in 032 for now so at least v3 is fixed.

 I wouldn't object going up to 030 with it but definitely not in 029 for
 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] #24313 [Core Tor/Tor]: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]

2017-11-20 Thread Tor Bug Tracker & Wiki

#24313: Tor 0.3.2.3-alpha crash: died: Caught signal 11 [crash from
rend_consider_services_intro_points]
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Probs bug introduced by `1125a4876b455d41b4c858cc97e8f8feef0fa8d0` as part
 of #8239.

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

Re: [tor-bugs] #24358 [Applications/Tor Browser]: flex error 32 linux build??? binutils

2017-11-20 Thread Tor Bug Tracker & Wiki

#24358: flex error 32 linux build??? binutils
--+---
 Reporter:  fedora0penchaos@… |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 Did you modify anything in `tor-browser-build`?

 By the way eec1680 is old. Is there a reason for using that commit?

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

Re: [tor-bugs] #24358 [Applications/Tor Browser]: flex error 32 linux build??? binutils

2017-11-20 Thread Tor Bug Tracker & Wiki

#24358: flex error 32 linux build??? binutils
--+---
 Reporter:  fedora0penchaos@… |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by fedora0penchaos@…):

 I am using commit eec1680 (tor browser build)
 and (latest) commit 236fcaa (rbm)

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

2017-11-20 Thread Tor Bug Tracker & Wiki

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => 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

1 2 >

1 - 100 of 149 matches

Mail list logo