date:20161012

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:40 karsten]:
 > ...
 >  - Should we hold back the four `*Sync*` options until there's actual
 support for syncing?  I don't feel strongly about this, because we're
 going to add syncing support really soon.  But just in case you say "oh
 wow, I totally forgot to take them out, let me fix that!", okay.  Either
 way works for me.

 I extended the commit comment (see link below).

 >
 >  - The new options `RelayLocalOrigins` and `BridgeLocalOrigins` each
 only accept a single path.  Should we rename them to singular then?
 Again, don't feel strongly.

 Thought about that , too, but finally decided to keep it a *Options.

 >
 >  - The new option `BridgeSources` does not support `Remote` as stated in
 the comment of `collector.properties`.

 Corrected in
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -first-sync-2&id=02681a4d9722bfb21516693366be194c90910e5b here] (amended).

 >
 >  - Totally unrelated to this commit: should we kill the updateindex
 module and instead have an `IndexManager` with a `synchronized update()`
 method that gets called at the end of each module?  Happy to move this to
 another ticket, but it just came to mind while looking at all the
 options...

 Currently, there is also the create tars script changing the file
 structure.  This should become java code.  => new ticket?
 Index-update could then be changed from being a module into a feature of
 module runs.  => second 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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-06

2016-10-12 Thread Tor Bug Tracker & Wiki

#20348: Kazakhstan blocking of vanilla Tor, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:3 dcf]:
 >  * MSS=1351 is unusual...
 > dcf connected to the server with ncat from Linux 4.7. The server's
 SYN/ACK had
 >   MSS=1350,SAckOK,Timestamp,NOP,WScale=6 (20 bytes)

 This might be the key. When reached over an uncensored link, the bridge
 reports its MSS as 1350. I.e., the largest TCP segment it can handle on
 its inbound link is 1350 bytes. But when contacted over the censored kz
 link, the "bridge" reports an MSS of 1351, one byte too big to fit through
 the link.

 A middlebox might have injected the SYN/ACK with MSS=1351. That then
 causes the client to send segments with 1351 bytes of payload, which then
 get dropped somewhere between the middlebox and the server.

 That would explain why the blocking is intermittent—the middlebox might
 have limited injection capability. It would seem the middlebox can also
 drop packets, as well as ACKing the client's data (and sending keep-alive
 ACKs). It doesn't seem like this trick would work when the server has an
 MSS greater than or equal to the client's, though, hmm.

 kzblocked, if you're reading this, please try reducing your OS's MTU; that
 should make a spoofed MSS ineffective. It looks like you can change it by
 setting the registry key
   HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
 \''interface-name''\MTU
   https://technet.microsoft.com/en-us/library/cc938197.aspx

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-06

2016-10-12 Thread Tor Bug Tracker & Wiki

#20348: Kazakhstan blocking of vanilla Tor, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 kzblocked shared a pcap of trying to connect over obfs4 to the bridge
 Mosaddegh:80. I don't want to upload it without permission but I can
 summarize the interesting features.

  * The client sends a SYN with 12 bytes of TCP options:
 MSS=1460,WScale=8,NOP,NOP,SAckOK.
  * The server replies with a SYN/ACK and 8 bytes of TCP options:
 MSS=1351,NOP,NOP,NOP,EOL.
  * The client sends an empty ACK.
  * The client sends 5211 bytes of payload across 4 packets:
 1351+1351+1351+1158.
  * The server ACKs the client's payload but sends no payload of its own.
  * 5.2 seconds later, the server sends an ACK with an acknowledgement one
 less than the one it most recently sent (a TCP keep-alive).
  * The server sends 5 more keep-alives separated by 5 seconds.

 The server's TCP options are weird. MSS=1351,NOP,NOP,NOP,EOL.
  * MSS=1351 is unusual; there's only once case of it (M547) in nmap-os-db,
 "HP MSM410 WAP V. 6.2.1.1-18016 (Looks like Linux 2.6.32 --ed.)". MSS=1350
 is more common.
  * The NOP,NOP,NOP,EOL padding at the end isn't needed and it's out of
 character for a Linux server. TCP options need to be padded to a multiple
 of 4 bytes but the MSS=1351 option is already 4 bytes.
  * There's no WScale option, which is unusual for Linux.

 dcf connected to the server with ncat from Linux 4.7. His SYN had the
 options
   MSS=1460,SAckOK,Timestamp,NOP,WScale=7 (20 bytes)
 The server's SYN/ACK had
   MSS=1350,SAckOK,Timestamp,NOP,WScale=6 (20 bytes)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20349 [HTTPS Everywhere/EFF-HTTPS Everywhere]: neocities blogs support https but extension doesn't redirect to https

2016-10-12 Thread Tor Bug Tracker & Wiki

#20349: neocities blogs support https but extension doesn't redirect to https
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   |   Keywords:  neocities
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 the site keeps sending me to http version when an https version is
 available. reproduce by going to something like 2bit.neocities.org and
 you'll find it all insecure.

 extension version 5.2.5

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-06 (was: Kazakhstan blocking of vanilla Tor, 2016-08)

2016-10-12 Thread Tor Bug Tracker & Wiki

#20348: Kazakhstan blocking of vanilla Tor, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

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

Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-08

2016-10-12 Thread Tor Bug Tracker & Wiki

#20348: Kazakhstan blocking of vanilla Tor, 2016-08
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 I was talking to someone on IRC today (I'll call them kzblocked) who
 provided some information. As I understand them:
  * Vanilla Tor, obfs3, obfs4, and meek are blocked.
  * The blocking is unreliable and seems to depend on load. Sometimes
 traffic gets through that you would think would get blocked. This makes it
 harder to test. The firewall is also blocking tumblr.com (by SNI) but
 sometimes it loads.
  * Secret obfs4 bridges from bridges.torproject.org are also blocked. It
 seems to be dynamic detection, not a static blacklist. Setting `iat-
 mode=1` on the client doesn't help.
  * meek is blocked by SNI. [[doc/meek#Howtochangethefrontdomain|Changing
 the front domain]] circumvents the block. kzblocked didn't try a different
 TLS fingerprint.
  * obfs2 isn't blocked; kzblocked speculates it's because the initial
 packet is too short to get a good entropy estimate.
  * The blocking of vanilla started on June 2. Bridges were somehow lagged
 or degraded so people gradually stopped using them.
  * Behavior differs across ISPs. Someone said that in one case it's a
 Fortinet FortiGuard firewall.

 kzblocked wrote a Windows program that allows obfs4 connections to
 succeed, by shrinking the server's TCP window so the client's first packet
 is smaller. Like [https://github.com/NullHypothesis/brdgrd brdgrd] but on
 the client side. They seem to think that only the first segment is being
 looked at.
  * A first segment of 1 byte doesn't work.
  * A first segment of 16 bytes works.
  * A first segment of 16 bytes works also for unobfuscated Tor TLS.

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

2016-10-12 Thread Tor Bug Tracker & Wiki

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by chelseakomlo):

 This refactor also assumes that the same conditions met by
 purpose_needs_anonymity also hold for is_sensitive_dir_purpose.
 is_sensitive_dir_purpose was more restrictive though.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-08

2016-10-12 Thread Tor Bug Tracker & Wiki

#20348: Kazakhstan blocking of vanilla Tor, 2016-08
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   |   Keywords:  censorship
 |  block kz
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 At the beginning of June 2016, direct users in Kazakhstan fell, while
 bridge users simultaneously rose. Thereafter, bridge users slowly
 declined.
   [[Image(userstats-relay-country-kz-2016-01-01-2016-10-12-off.png)]]
 [https://metrics.torproject.org/userstats-relay-
 country.html?start=2016-01-01&end=2016-10-12&country=kz&events=off link]
   [[Image(userstats-bridge-country-kz-2016-01-01-2016-10-12.png)]]
 [https://metrics.torproject.org/userstats-bridge-
 country.html?start=2016-01-01&end=2016-10-12&country=kz link]
 The mainly used transport was obfs4.
   [[Image(userstats-bridge-combined-kz-2016-01-01-2016-10-12.png)]]
 [https://metrics.torproject.org/userstats-bridge-
 combined.html?start=2016-01-01&end=2016-10-12&country=kz link]

 The dip in bridge users during September was likely not related to
 anything happening in Kazakhstan, but is an artifact of the changeover of
 bridge authorities. See https://lists.torproject.org/pipermail/metrics-
 team/2016-September/000217.html.

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

2016-10-12 Thread Tor Bug Tracker & Wiki

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by chelseakomlo):

 Ok! Here are the latest changes.

 
https://github.com/chelseakomlo/tor_patches/commit/3343b20cc5cf73a09fc3c5d7b07841821c81473c

 I had one question when doing this:

 Outside of directory.c, this functionality is used in two other places,
 neither of which test whether the router purpose is a bridge (as is done
 throughout directory.c).

 Specifically, this change feels slightly dirty:
 
https://github.com/chelseakomlo/tor_patches/commit/3343b20cc5cf73a09fc3c5d7b07841821c81473c
 #diff-0798d3d17392dc5c15f3f58a5fc6b29aR2392

 But I'm not sure if making two interfaces for this (one specifically for
 callers who only want to check the dir_purpose) is overkill.

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

2016-10-12 Thread Tor Bug Tracker & Wiki

#20347: Put "custom" option on security slider?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Another possibility that occurs to me is to hide the security slider when
 we are in custom mode. Show a message that says
 "Browser prefs have been changed to put Tor Browser in a nonstandard
 security setting. This is dangerous because it helps to distinguish you
 from other users."
 And then a button that shows "Reset to X security", where X is Low, Medium
 or High, depending on the current value of
 "extensions.torbutton.security_slider". Once that button is pressed, the
 security slider would re-appear in the correct setting.

 I'm interested to hear opinions!

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

Re: [tor-bugs] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

2016-10-12 Thread Tor Bug Tracker & Wiki

#20347: Put "custom" option on security slider?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * keywords:   => tbb-usability
 * owner:   => tbb-team
 * component:  - Select a component => Applications/Tor Browser


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

Re: [tor-bugs] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

2016-10-12 Thread Tor Bug Tracker & Wiki

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201610R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by arthuredelstein):

 Replying to [comment:16 bugzilla]:
 > It's really great to see how you've started to go step by step into the
 right direction of redesigning UI, so that it's now a real "Torbutton UI
 flow improvement"!

 Thanks!

 > Hint: it's better to replace this checkbox with a new Security Slider
 position "Expert" above High, especially for mobile UX, which will have
 the same settings as High for the first time (so text to the right will be
 the same), and text will disappear when custom settings will have been
 made (and this position will preserve (!) custom settings while switching
 back and forth from other positions!)

 That's an interesting suggestion. I opened #20347.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20347 [- Select a component]: Put "custom" option on security slider?

2016-10-12 Thread Tor Bug Tracker & Wiki

#20347: Put "custom" option on security slider?
--+-
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 bugzilla suggested:

 > Hint: it's better to replace this checkbox with a new Security Slider
 position "Expert" above High, especially for mobile UX, which will have
 the same settings as High for the first time (so text to the right will be
 the same), and text will disappear when custom settings will have been
 made (and this position will preserve (!) custom settings while switching
 back and forth from other positions!)

 I'm not sure about this approach, because it puts the custom option on the
 same "linear dimension" as the other security options. On the other hand,
 I agree it will perhaps make the semantics somewhat clearer.

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

Re: [tor-bugs] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

2016-10-12 Thread Tor Bug Tracker & Wiki

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201610R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by arthuredelstein):

 Here is a new version based on patch 20244+1:
 https://github.com/arthuredelstein/torbutton/commit/18093+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

Re: [tor-bugs] #20244 [Applications/Tor Browser]: Move privacy checkboxes to about:preferences#privacy (proposed)

2016-10-12 Thread Tor Bug Tracker & Wiki

#20244: Move privacy checkboxes to about:preferences#privacy (proposed)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:5 mcs]:
 > Replying to [comment:2 arthuredelstein]:
 > > I've written patches for this, because it's going to make the problems
 I encountered in #18093 much easier to solve.
 >
 > Kathy and I reviewed and ran with all of the patches. Nice work!
 Comments below.

 Thanks for the review!

 > * There is a typo in the commit message for
 38f3653b89ce3790d75b8652316f7381158d0af3 ("Bug Bug").

 Fixed.

 > * You sometimes treat `privacy.thirdparty.isolate` as a Boolean pref,
 which does not seem correct.

 Oops, good catch. Fixed.

 > * When I clicked the button in about:plugins to enable plugins, no
 warning prompt was displayed. Possibly related, there is no default value
 for `plugins.disable` which caused this to appear on the browser console:
 > {{{
 > 16:26:17.523 NS_ERROR_UNEXPECTED: Component returned failure code:
 0x8000 (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]1
 torbutton.js:2323:0
 > }}}

 Turns out I had consistently mistyped "plugin.disable" as
 "plugins.disable". Fixed.

 > * Please remove the following from
 src/defaults/preferences/preferences.js:
 > {{{
 > extensions.torbutton.resist_fingerprinting
 > extensions.torbutton.restrict_thirdparty
 > }}}

 Done. I have now also removed "extensions.torbutton.block_disk" in patch
 20244.1 and use the "browser.privatebrowsing.autostart" pref instead.

 > * Can we reduce the height of the preferences window? I cannot remember
 how the height is determined, but on OSX there is now a lot of extra space
 below the slider. Or maybe it is just remembering an old height that I set
 by resizing.



 I added maxwidth and maxheight properties to stop it from getting too big.

 > * In the tor-browser patches, should we use the same labels as we have
 in src/chrome/locale/en/torbutton.dtd? Or did you intentionally make them
 different to verify that the overlay was working?

 I did, but now I have made them the same.

 > * Should we include the access keys in the overlay so they can be
 localized?

 Added.

 Here are the new versions:
 https://github.com/arthuredelstein/torbutton/commits/20244+1
 https://github.com/arthuredelstein/tor-browser/commits/20244+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] #20342 [Applications/Tor Browser]: Add tor-gencert.exe to tor expert bundle (was: Add tor-gencert.exe to tor expert bundle and tor nightlies)

2016-10-12 Thread Tor Bug Tracker & Wiki

#20342: Add tor-gencert.exe to tor expert bundle
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  testing   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * component:  Core Tor/Tor => Applications/Tor Browser
 * priority:  High => Medium
 * owner:   => tbb-team
 * points:  0.5 =>
 * milestone:  Tor: 0.2.??? =>
 * keywords:  029-proposed, testing => testing
 * type:  defect => enhancement
 * severity:  Major => Normal


Old description:

> At the recent tor developer meeting, a volunteer tried to get chutney
> working on Windows, but tor-gencert.exe wasn't in the tor expert bundle.
>
> If we want people to test Tor on Windows, we need to add at least tor-
> gencert.exe to the windows expert and nightly bundles. There might be
> other binaries we want to add as well.

New description:

 At the recent tor developer meeting, a volunteer tried to get chutney
 working on Windows, but tor-gencert.exe wasn't in the tor expert bundle.

 If we want people to test Tor on Windows, we need to add at least tor-
 gencert.exe to the windows expert ~~~and nightly~~~ bundles. ~~~There
 might be other binaries we want to add as well.~~~

--

Comment:

 Replying to [comment:4 arma]:
 > The Tor Browser build process generates the Windows expert bundles.

 Ok. Switched this ticket over to TBB.

 I wonder if it makes sense to add tor-gencert to all the tor browser
 bundles. Probably not. The likely benefit is negligible, versus the extra
 download cost.

 > ...So I guess that means this should be a Tor Browser ticket, to the
 attention of boklm.

 > teor: when you say nightlies, which ones do you mean?

 It turns out that the debian experimental / nightly / alpha builds already
 have tor-gencert, and chutney finds that OK. If we want to do that for
 other platforms, I've split it off into #20346.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20346 [Core Tor/Tor]: Do we need Tor unstable binary releases for Windows, OS X, BSD?

2016-10-12 Thread Tor Bug Tracker & Wiki

#20346: Do we need Tor unstable binary releases for Windows, OS X, BSD?
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  testing, qa
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We currently package tor alphas on a nightly basis in "experimental"
 debian packages.

 Do we want to do the same for Windows, OS X, or BSD?
 On a nightly basis, or just for alphas and release candidates?

 This would assist us in having a wider range of people QA tor unstable
 releases, but I'm not sure it's useful right now, as one of our priposed
 QA instructions is:

 "Does it build without any warnings?"

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

Re: [tor-bugs] #20342 [Core Tor/Tor]: Add tor-gencert.exe to tor expert bundle and tor nightlies

2016-10-12 Thread Tor Bug Tracker & Wiki

#20342: Add tor-gencert.exe to tor expert bundle and tor nightlies
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  029-proposed, testing  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by arma):

 * cc: boklm (added)


Comment:

 The Tor Browser build process generates the Windows expert bundles.

 teor: when you say nightlies, which ones do you mean?

 ...So I guess that means this should be a Tor Browser ticket, to the
 attention of boklm.

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

Re: [tor-bugs] #20342 [Core Tor/Tor]: Add tor-gencert.exe to tor expert bundle and tor nightlies

2016-10-12 Thread Tor Bug Tracker & Wiki

#20342: Add tor-gencert.exe to tor expert bundle and tor nightlies
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  029-proposed, testing  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:2 asn]:
 > Hm, should this be a Core Tor ticket or a Tor Browser ticket?

 I don't know.
 Who builds the tor nightlies? Do we have one for Windows?
 Who builds the tor expert bundle?

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

Re: [tor-bugs] #20262 [Core Tor/Tor]: Onion services startup time always gets revealed

2016-10-12 Thread Tor Bug Tracker & Wiki

#20262: Onion services startup time always gets revealed
-+
 Reporter:  twim |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by twim):

 Linkability hindering is more relevant to #20082.
 I can find code for this ticket in `obfuscate-startup-time` branch at
 https://github.com/nogoegst/tor or https://gitlab.com/nogoegst/tor. It's
 being rebased against branch from #20082.

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

Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

2016-10-12 Thread Tor Bug Tracker & Wiki

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, TorCoreTeam201610  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Replying to [comment:30 asn]:
 > My understanding is that the patc makes the default delay be 3s but we
 will have a torrc option to bump it up to 30s + random()?
 > I'm having trouble understanding the point of this torrc option? Who
 would enable it and for what reason? IMO, it's just going to go unused and
 contribute to our increasing torrc option bloat.

 Nope, please see changes file about how it works. `torrc` option is for
 hiding startup time for those who need it and is being discussed in
 #20262. There is not `torrc` option here.

 Plus see my previous comment.

 > I feel that there is no point in doing probabilistic delays here without
 a proper security analysis of what they offer, and I have not seen one of
 those yet. Just saying "it obfuscates startup time" is not a security
 analysis IMO. Who does it obfuscate it from, what attacks are prevented,
 and why did we choose that random value? Most importantly, _who_ should
 enable that torrc option?

 Again, there is no `torrc` option here. I have eliminated deterministic
 delay here. 3s is only for the case when networks fails and we have to
 reupload descriptor suddenly. Also, as dgoulet has mentioned, I've
 introduced small random delay in order to unlink on-disk onion services
 from each other. It's absolutely different delay (see above).

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

Re: [tor-bugs] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

2016-10-12 Thread Tor Bug Tracker & Wiki

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201610R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 The changes look okay to me (I did not try to run with them applied).
 Since most users simply discard their entire browser or their entire data
 directory when they want to restore to a known state, I do not think
 `Restore Defaults` will be missed.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:35 iwakeh]:
 > Replying to [comment:31 karsten]:
 > > Regarding your comment 29, yes, picking shorter names sounds fine to
 me.  I would avoid renaming existing config options, but picking better
 names for new config options or values sounds great.  Please prepare a
 commit with the described changes.  Thanks!
 >
 >
 > Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -first-sync-2&id=36d0b44f95d0cbf4cd38eb1dfd8a0584ffb7f194 this commit]
 with the additional changes.

 Thanks!  Here are some minor comments on 36d0b44:

  - Should we hold back the four `*Sync*` options until there's actual
 support for syncing?  I don't feel strongly about this, because we're
 going to add syncing support really soon.  But just in case you say "oh
 wow, I totally forgot to take them out, let me fix that!", okay.  Either
 way works for me.

  - The new options `RelayLocalOrigins` and `BridgeLocalOrigins` each only
 accept a single path.  Should we rename them to singular then?  Again,
 don't feel strongly.

  - The new option `BridgeSources` does not support `Remote` as stated in
 the comment of `collector.properties`.

  - Totally unrelated to this commit: should we kill the updateindex module
 and instead have an `IndexManager` with a `synchronized update()` method
 that gets called at the end of each module?  Happy to move this to another
 ticket, but it just came to mind while looking at all the options...

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

Re: [tor-bugs] #20244 [Applications/Tor Browser]: Move privacy checkboxes to about:preferences#privacy (proposed)

2016-10-12 Thread Tor Bug Tracker & Wiki

#20244: Move privacy checkboxes to about:preferences#privacy (proposed)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:2 arthuredelstein]:
 > I've written patches for this, because it's going to make the problems I
 encountered in #18093 much easier to solve.

 Kathy and I reviewed and ran with all of the patches. Nice work! Comments
 below.

 > There are 6 patches here (in which I remove checkboxes one by one and
 then clean up the UI):
 > https://github.com/arthuredelstein/torbutton/commits/20244

 * There is a typo in the commit message for
 38f3653b89ce3790d75b8652316f7381158d0af3 ("Bug Bug").
 * You sometimes treat `privacy.thirdparty.isolate` as a Boolean pref,
 which does not seem correct.
 * When I clicked the button in about:plugins to enable plugins, no warning
 prompt was displayed. Possibly related, there is no default value for
 `plugins.disable` which caused this to appear on the browser console:
 {{{
 16:26:17.523 NS_ERROR_UNEXPECTED: Component returned failure code:
 0x8000 (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]1
 torbutton.js:2323:0
 }}}
 * Please remove the following from
 src/defaults/preferences/preferences.js:
 {{{
 extensions.torbutton.resist_fingerprinting
 extensions.torbutton.restrict_thirdparty
 }}}
 * Can we reduce the height of the preferences window? I cannot remember
 how the height is determined, but on OSX there is now a lot of extra space
 below the slider. Or maybe it is just remembering an old height that I set
 by resizing.

 > and 2 patches here (where I add two checkboxes to the
 about:preferences#privacy page):
 > https://github.com/arthuredelstein/tor-browser/commits/20244
 >
 > Note that the last torbutton patch adds an overlay so that the our
 translated checkbox labels can be temporarily applied to the
 about:preferences page. If Mozilla uplifts these to Firefox and translates
 the labels themselves, then we won't need this overlay any more.

 * In the tor-browser patches, should we use the same labels as we have in
 src/chrome/locale/en/torbutton.dtd? Or did you intentionally make them
 different to verify that the overlay was working?
 * Should we include the access keys in the overlay so they can be
 localized?

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

Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

2016-10-12 Thread Tor Bug Tracker & Wiki

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, TorCoreTeam201610  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Replying to [comment:29 dgoulet]:
 > @twim, yeah you'll need a Gitlab account, sorry about that but it's
 worth it. If you had more commit, I can add them to that branch so we
 don't lose our discussion.

 Sure, I prefer to move review-specific code to something ephemeral to not
 litter trac.


 > Removing `proposal-needed?` as we don't define upload delays in the
 specification only time period HOWEVER I found this in rend-spec.txt:
 > {{{
 >When uploading descriptors, the hidden service needs to make sure
 that
 >descriptors for different clients are not uploaded at the same time
 (cf.
 >Section 1.1) which is also a limiting factor for the number of
 clients.
 > }}}
 >
 > We should make sure we actually follow this as this might be important?

 Sure, it's really important and somehow I forgot about it. I think there
 should be some __short__ random initial delay __only for on-disk
 services__ since they are being started at the same time (note that this
 code doesn't actually work now). I'll soon update my branch.
 The delay for hiding startup time has different purpose and should be
 treated separately (see #20262 and my branch `obfuscate-startup-time`).

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

Re: [tor-bugs] #19922 [Internal Services/Tor Sysadmin Team]: server set up for giant rabit

2016-10-12 Thread Tor Bug Tracker & Wiki

#19922: server set up for giant rabit
-+-
 Reporter:  isabela  |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

 * 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] #19922 [Internal Services/Tor Sysadmin Team]: server set up for giant rabit

2016-10-12 Thread Tor Bug Tracker & Wiki

#19922: server set up for giant rabit
-+-
 Reporter:  isabela  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 and we have a user too.

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

Re: [tor-bugs] #20253 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Change Ruleset for HTTPS Everywhere

2016-10-12 Thread Tor Bug Tracker & Wiki

#20253: Change Ruleset for HTTPS Everywhere
-+-
 Reporter:  cypherpunks  |  Owner:  jsha
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Critical | Resolution:  fixed
 Keywords:  ruleset, change, EFF-HTTPS   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by fuglede):

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


Comment:

 GitHub PR 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] #20335 [Metrics/CollecTor]: ReferenceChecker causes OOM

2016-10-12 Thread Tor Bug Tracker & Wiki

#20335: ReferenceChecker causes OOM
---+-
 Reporter:  iwakeh |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 I forgot: such a db could solve the microdesc validAfter-date-in-out-path
 question, too.

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

Re: [tor-bugs] #20253 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Change Ruleset for HTTPS Everywhere

2016-10-12 Thread Tor Bug Tracker & Wiki

#20253: Change Ruleset for HTTPS Everywhere
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Critical   | Resolution:
 Keywords:  ruleset, change, EFF-HTTPS |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by jsha):

 Filed a pull request to fix: https://github.com/EFForg/https-
 everywhere/pull/7326

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

Re: [tor-bugs] #20185 [Applications/Tor Browser]: Tor Browser alpha is broken on Linux (and probably OS X) if directory is nested too deep

2016-10-12 Thread Tor Bug Tracker & Wiki

#20185: Tor Browser alpha is broken on Linux (and probably OS X) if directory is
nested too deep
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201610R |  Actual Points:
Parent ID:  #14270| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * status:  new => needs_review
 * keywords:  TorBrowserTeam201610 => TorBrowserTeam201610R


Comment:

 Here is a patch for review:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20185-01&id=ee4b3ad5d22fdc3abf582afd2aca936a7cb1b778

 You will need to apply the latest patch from #20111 before applying 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

Re: [tor-bugs] #20335 [Metrics/CollecTor]: ReferenceChecker causes OOM

2016-10-12 Thread Tor Bug Tracker & Wiki

#20335: ReferenceChecker causes OOM
---+-
 Reporter:  iwakeh |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Suggestion for, how to separate statistics:

 Well, mostly the code for the stats tries to implement database
 functionality, i.e. persistence between runs, queries, and cleaning data
 items that are too old.

 I think a simple hsqldb would be fine here. This needs just the hsqldb
 dependency (available in debian).  It creates the db if it is not there,
 below the stats path for example.   The data could be written from the
 newly introduced *Persistence classes.  The clean-up would be just a query
 per table (there are foreign keys and cascades available).  Schema and
 access rights are delivered with inside collector.jar hidden from the
 user. So, there is some freedom to adapt and change with time.

 An additional benefit would be that this db could be queried by command
 line for additional information. Or, the date could easily even be
 transferred to a 'real' dbms for continuous analysis, if necessary.

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

Re: [tor-bugs] #20253 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Change Ruleset for HTTPS Everywhere

2016-10-12 Thread Tor Bug Tracker & Wiki

#20253: Change Ruleset for HTTPS Everywhere
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Critical   | Resolution:
 Keywords:  ruleset, change, EFF-HTTPS |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * severity:  Major => Critical


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

Re: [tor-bugs] #20335 [Metrics/CollecTor]: ReferenceChecker causes OOM

2016-10-12 Thread Tor Bug Tracker & Wiki

#20335: ReferenceChecker causes OOM
---+-
 Reporter:  iwakeh |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Steps to reproduce (from #18910, the discussion should take place here):
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -first-sync&id=5eb89c10a0a720c1fa4eb806e5d5b5f2dee75b65 Collector branch]:
 Run the jar in a new location, i.e. with empty recent and out. Configure
 relaydescs and sync. RunOnce will be sufficient the OOM heap dump contains
 very many Reference objects. (Your assumption in one of the previous
 comments hinted in the right direction, I think, but I couldn't verify
 that yet.)

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

Re: [tor-bugs] #20333 [Metrics/metrics-lib]: add descriptor digest to vote and streamline method name

2016-10-12 Thread Tor Bug Tracker & Wiki

#20333: add descriptor digest to vote and streamline method name
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 This could get solved by overloading with an additional parameter for the
 algorithm.
 That could also be useful for the sha*Hex methods.  So, it might be good
 to look for other candidates.

 From a developing user point of view I'd rather have these methods named
 the same and prefer a short name.  (Just having "digest()" is worth
 considering, but that is a bigger change.)  It's easier to make an api
 popular when there is a consistent and lean naming scheme.

 Some examples:
 `relayDesc.getDigest()` instead of `relayDesc.getServerDescriptorDigest()`
 `relayDesc.getDigest(Sha256)` instead of
 `relayDesc.getServerDescriptorDigest256()`
 `micro.getDigest()` instead of `micro.getMicrodescriptorDigest()`

 Of course,  there needs to be a transition and the clients' in Metrics
 products will have to be adapted.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 microdesc-sync ticket #20345 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

[tor-bugs] #20345 [Metrics/CollecTor]: add microdesc sync

2016-10-12 Thread Tor Bug Tracker & Wiki

#20345: add microdesc sync
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 cf. comments 30+ in #18910

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:37 karsten]:
 > And here are the last three commits from your initial branch, starting
 with 5eb89c1:

 Thanks for working your way through and all the useful
 comments/suggestions!
 (I still need to reply to some.)

 >
 >  - Looks good, modulo whitespace issues that should become visible with
 checkstyle.

 The commits in the second branch all are checkstyle-compliant.

 >
 > And 4722ba1:
 >
 >  - I'd want to avoid merging this and instead investigate the problem
 further.  How would I reproduce the OOM?  Run the previous commit with
 syncing from the main CollecTor instance and wait for how many hours?

 Yes, use the collector jar from the previous commit.  Run it in a new
 location, i.e. with empty recent and out.  Configure relaydescs and sync.
 RunOnce will be sufficient the OOM heap dump contains very many Reference
 objects.  (Your assumption in one of the previous comments hinted in the
 right direction, I think, but I couldn't verify that yet.)

 The sync into an empty place approximately takes an hour depending on the
 internet connection.

 >
 > Last and probably least, d2fcb1b:
 >
 >  - We should simply squash this one into the earlier commit that added
 these lines.  And we should add a note to `collector.properties` that
 microdescs are exempt from syncing.  And we should create a ticket as a
 reminder to add microdescs to the sync part later on.

 I just don't add microdescs-sync to the new branch in first place and will
 open the new 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 And here are the last three commits from your initial branch, starting
 with 5eb89c1:

  - Looks good, modulo whitespace issues that should become visible with
 checkstyle.

 And 4722ba1:

  - I'd want to avoid merging this and instead investigate the problem
 further.  How would I reproduce the OOM?  Run the previous commit with
 syncing from the main CollecTor instance and wait for how many hours?

 Last and probably least, d2fcb1b:

  - We should simply squash this one into the earlier commit that added
 these lines.  And we should add a note to `collector.properties` that
 microdescs are exempt from syncing.  And we should create a ticket as a
 reminder to add microdescs to the sync part later 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 The naming discussion should continue in #20162.  Please, see comment 6 in
 #20162.

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

Re: [tor-bugs] #20162 [Metrics/CollecTor]: reduce configuration paramaters in collector.properties

2016-10-12 Thread Tor Bug Tracker & Wiki

#20162: reduce configuration paramaters in collector.properties
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 2.0.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Streamline the naming of all properties, i.e. Relay* instead of
 Relaydescs* and similar.

 As there are many obsolete properties by now there should be a check
 informing operators of redundant properties in their config file.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:31 karsten]:
 > Regarding your comment 29, yes, picking shorter names sounds fine to me.
 I would avoid renaming existing config options, but picking better names
 for new config options or values sounds great.  Please prepare a commit
 with the described changes.  Thanks!


 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -first-sync-2&id=36d0b44f95d0cbf4cd38eb1dfd8a0584ffb7f194 this commit]
 with the additional changes.

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

Re: [tor-bugs] #20253 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Change Ruleset for HTTPS Everywhere

2016-10-12 Thread Tor Bug Tracker & Wiki

#20253: Change Ruleset for HTTPS Everywhere
---+--
 Reporter:  cypherpunks|  Owner:  jsha
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS Everywhere  |Version:
 Severity:  Major  | Resolution:
 Keywords:  ruleset, change, EFF-HTTPS |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Replying to [comment:1 cypherpunks]:
 > The issue is that you're using a self signed cert which points to dnsme.
 > If you want a free/inexpensive solution I'd recommend setting up
 letsencrypt (https://letsencrypt.org/getting-started/) on the apache
 instance to resolve this.

 Not an option for us. We don't have shell access as we use a simplified
 content management/constituent relations management service who only offer
 SSL capability for $1000/month. We need HTTPS everywhere to NOT include
 our website. This is killing our web traffic and the trustworthiness of
 our brand.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 1e07139 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Next in line is 4efd190:

  - In `SyncManager`, I think we'll have to obtain the `collectionDate`
 from the corresponding `CollecTorMain` subclass somehow, so that we're
 appending descriptors to the same files as previously downloaded or
 locally read descriptors.  Otherwise we'd have two files in the `recent/`
 directory per descriptor type, making the index larger than necessary.
 Let's avoid that if we can.

  - As stated in an earlier comment, there are unused variables and imports
 in this commit that should be removed.

  - Still in `SyncManager`, method `mergeWithLocalStorage()`, it seems that
 we're using the exact same path for parse history files for different
 descriptors.  Example: we're reading descriptor type A with history file
 X, and when we're done we're reading descriptor type B with the same
 history file X.  The effect is that we're not skipping any B descriptors
 and overwriting everything in X that has to do with A.  Basically, we're
 reading the entire directory of synced descriptors in every execution.
 What we need is a distinct history file per descriptor type.  Or we could
 use a single descriptor reader regardless of descriptor type with a single
 history file.  By the way, this could have caused your OOM troubles.

  - Your log statement "Done reading {} of type {}." is misleading.  The
 `readDescriptors()` method returns immediately, but that does not at all
 mean that there are any descriptors in the iterator at that point.  A
 better message would be "Started reading ...".

  - In `SyncPersistence`, method `storeDescs()`, the documentation says
 "OutputDirectory" where it should say "OutputPath".

  - Regarding the three `//` comments in `storeDescs()`: it's indeed
 unfortunate that we need to infer the authority fingerprint of a bridge
 network status from the file name.  We should consider adding a new line
 for that to sanitized bridge network statuses.  That's entirely unrelated
 to the changes here but probably worth a ticket.

  - The second comment there is probably moot with microdescriptor syncing
 being postponed.

  - Regarding the third comment about exit lists, we're currently using the
 initial download time for storing in `out/` and `recent/`.  But I think
 that's something to ensure in `ExitlistPersistence`, not here, so the code
 here can stay unchanged.

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

Re: [tor-bugs] #20307 [Core Tor/Tor]: [warn] Remote server sent bogus reason code 65021

2016-10-12 Thread Tor Bug Tracker & Wiki

#20307: [warn] Remote server sent bogus reason code 65021
---+
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal | Resolution:
 Keywords:  circuit, 029-proposed  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 I think we should probably aim for a real solution : there are lots of
 inconsistencies here and I think we need to think of some better way to
 have these functions signal errors.  Otherwise reason codes will continue
 to be generally messed 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Regarding your comment 29, yes, picking shorter names sounds fine to me.
 I would avoid renaming existing config options, but picking better names
 for new config options or values sounds great.  Please prepare a commit
 with the described changes.  Thanks!

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

Re: [tor-bugs] #20162 [Metrics/CollecTor]: reduce configuration paramaters in collector.properties

2016-10-12 Thread Tor Bug Tracker & Wiki

#20162: reduce configuration paramaters in collector.properties
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 2.0.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 The *OutpuDirectoryProperties are replaced cf.
 
[https://gitweb.torproject.org/collector.git/commit/?id=5003567318b8cb694cb46462c4819b8cbcf2eaf4
 master 5003567].

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Adapted the changelog and pushed that other commit for `OutPath` to
 master.  Thanks!

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

Re: [tor-bugs] #20341 [Core Tor/Tor]: torrc man page missing components for Bridge line

2016-10-12 Thread Tor Bug Tracker & Wiki

#20341: torrc man page missing components for Bridge line
---+--
 Reporter:  stefanib   |  Owner:
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torrc manual page  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by nickm):

 >That said, the documentation for the bridge line could clarify that,
 transports can add arbitrary things to the bridge line.

 +1 on this.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Oh, I just noticed the comments 25 and 26.  But, I guess the my reply to
 26, 27 won't change after reading 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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

2016-10-12 Thread Tor Bug Tracker & Wiki

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, TorCoreTeam201610  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-

Comment (by asn):

 Hello, I haven't had the time to review the patch yet.

 My understanding is that the patc makes the default delay be 3s but we
 will have a torrc option to bump it up to 30s + random()?

 I'm having trouble understanding the point of this torrc option? Who would
 enable it and for what reason? IMO, it's just going to go unused and
 contribute to our increasing torrc option bloat.

 I feel that there is no point in doing probabilistic delays here without a
 proper security analysis of what they offer, and I have not seen one of
 those yet. Just saying "it obfuscates startup time" is not a security
 analysis IMO. Who does it obfuscate it from, what attacks are prevented,
 and why did we choose that random value? Most importantly, _who_ should
 enable that torrc option?

 Till this security analysis actually arrives, I'm inclined to just change
 the default delay to constant 3s, and get done with it without extra torrc
 options. Please let me know if I'm too absolute.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 reply to comment 28:  adapted changelog, this can go to master.

 reply comment 27:
 Hmm, let me think:

 Well, `*Sources` is in use for the urls data is retrieved from, but these
 together with the path values for local imports could be named `*Origins`
 or similar.

 The naming of all descriptor sources should be more generic.  Actually,
 ImportDirectory, and SanitizedTarballs, all refer to a local import, i.e.
 the import SourceType enum provides: Cache, Local, Remote, Sync.
 The corresponding sources properties could be `Origin`, e.g.
 RelayCacheOrigins, BridgeLocalOrigins, BridgeSyncOrigins, etc.

 That would shorten the properties list.

 Ok, I can provide a commit with these changes, if we agree?

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:24 iwakeh]:
 > Here is the
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -first-sync-2&id=d8ae07bf9c6a86b9018889806b4d87920369443d second branch],
 so far only the properties changes.
 >
 > Checkstyle doesn't complain about these changes.

 Looks good!  The only request would be that we make the change log entry
 slightly more verbose, like: "Replace four properties for configuring
 where to write descriptors by a single 'OutPath' property."  Happy to make
 that change while merging.  Should I merge this commit to master 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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

2016-10-12 Thread Tor Bug Tracker & Wiki

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, TorCoreTeam201610  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-
Changes (by dgoulet):

 * keywords:  tor-hs, research, proposal-needed?, TorCoreTeam201610,
 030-proposed => tor-hs, research, TorCoreTeam201610


Comment:

 Thanks teor and twim! This required from me a bit more text and trac is
 the worst so I did a Gitlab merge request for code review here. See my
 comments there! Let's make the discussion happened there now which will
 make our life so much easier :).

 @twim, yeah you'll need a Gitlab account, sorry about that but it's worth
 it. If you had more commit, I can add them to that branch so we don't lose
 our discussion.

 https://gitlab.com/dgoulet/tor/merge_requests/12

 Removing `proposal-needed?` as we don't define upload delays in the
 specification only time period HOWEVER I found this in rend-spec.txt:
 {{{
When uploading descriptors, the hidden service needs to make sure that
descriptors for different clients are not uploaded at the same time
 (cf.
Section 1.1) which is also a limiting factor for the number of clients.
 }}}

 We should make sure we actually follow this as this might be important?

 Finally, to answer your question twim:
 > btw, can we actually get this in 029?

 Nope, no chance sorry, 029 is freezed and 030 alpha is coming around the
 corner.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:26 karsten]:
 > Let's think about it.  We have 1 module with soon 4 descriptor sources
 and 2 modules with soon 2 descriptor sources.  How would you define config
 options to let operators activate each of the modules with any possible
 combination of descriptor sources?  And keep in mind that we might want to
 add a 5th or 3rd descriptor source in the future.

 Quick idea: how about we accept a list of descriptor sources for each
 module rather than have 4 or 2 separate boolean options?  Example:

 {{{
 RelaydescsSources ImportCached, ImportDirectory, Download, Sync
 BridgedescsSources SanitizeTarballs, Sync
 ExitlistSources Download, Sync
 }}}

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

Re: [tor-bugs] #20342 [Core Tor/Tor]: Add tor-gencert.exe to tor expert bundle and tor nightlies

2016-10-12 Thread Tor Bug Tracker & Wiki

#20342: Add tor-gencert.exe to tor expert bundle and tor nightlies
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  029-proposed, testing  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--

Comment (by asn):

 Hm, should this be a Core Tor ticket or a Tor Browser 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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:23 iwakeh]:
 > This way of configuring only works for the current relaydescs module
 (whose properties are supposed to be removed partially in #20162).

 We're planning to remove properties there, but none of those properties
 would enable or disable a descriptor source.

 > The other two modules, bridgedescs and exitlists, don't have any
 additional properties that could be used for avoiding the 'SyncOnly'
 option.

 Yes, we'd have to add two boolean options for those rather than one tri-
 state.

 > In general, it is nicer to have a configuration value that expresses
 what it means.  The different download options for the relaydescs module
 where initially quite confusing.

 I admit, I forget to enable descriptor sources from time to time myself
 when setting up a new CollecTor with relaydescs module for testing.

 > But maybe, I complicate things?  So what other 'streamlined' way could
 achieve the SyncOnly setting?

 Let's think about it.  We have 1 module with soon 4 descriptor sources and
 2 modules with soon 2 descriptor sources.  How would you define config
 options to let operators activate each of the modules with any possible
 combination of descriptor sources?  And keep in mind that we might want to
 add a 5th or 3rd descriptor source in the future.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Alright, here's a review of f4026fc:

  - All classes in the new `persist` package contains unused imports or
 unused attributes.  Can you remove those in a fixup commit?

  - Can we somehow use `printf` patterns for putting together paths to make
 that bunch of `DescriptorPersistence` classes easier to read?  It should
 be possible to express all paths using placeholders for dates/times,
 strings, and chars.  And if we care about path separators being platform
 independent, we could split the resulting path at `/` characters and put
 it back together using `Paths.get()`.  Untested example for a bridge
 extra-info descriptor:

 {{{
 String.format("bridge-descriptors/%tY/%https://trac.torproject.org/projects/tor/ticket/18910#comment:25>
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Here is the
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -first-sync-2&id=d8ae07bf9c6a86b9018889806b4d87920369443d second branch],
 so far only the properties changes.

 Checkstyle doesn't complain about these changes.

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

Re: [tor-bugs] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for hidden services

2016-10-12 Thread Tor Bug Tracker & Wiki

#20082: Lower initial descriptor upload delay for hidden services
-+-
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, research, proposal-needed?,  |  Actual Points:
  TorCoreTeam201610, 030-proposed|
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
 |  SponsorR-can
-+-

Comment (by twim):

 Replying to [comment:27 teor]:
 Thanks, reworded changes file. Also note that there is no initial post
 delay anymore. The `changes` file describes precisely what the code does.

 btw, can we actually get this in 029?

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:22 karsten]:
 > ...
 > Here's how I'd explain configuring the relaydescs module to a new
 operator: "Want to collect relay descriptors?  Sure, just activate that
 module and also enable one or more descriptor sources: download from the
 directory authorities, read from a local directory, read from local cached
 descriptors, synchronize from other CollecTor instances.  If you don't
 enable any descriptor sources, you won't get any descriptors."
 >
 > This feels easier than: "Want to collect relay descriptors?  Sure, just
 activate that module and also enable between zero and three descriptors
 sources, and also consider synchronizing from other CollecTor instances."
 >

 This way of configuring only works for the current relaydescs module
 (whose properties are supposed to be removed partially in #20162).
 The other two modules, bridgedescs and exitlists, don't have any
 additional properties that could be used for avoiding the 'SyncOnly'
 option.
 In general, it is nicer to have a configuration value that expresses what
 it means.  The different download options for the relaydescs module where
 initially quite confusing.
 But maybe, I complicate things?  So what other 'streamlined' way could
 achieve the SyncOnly setting?

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

Re: [tor-bugs] #20162 [Metrics/CollecTor]: reduce configuration paramaters in collector.properties

2016-10-12 Thread Tor Bug Tracker & Wiki

#20162: reduce configuration paramaters in collector.properties
---+-
 Reporter:  iwakeh |  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 2.0.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Reminder:

 > ...
 > replace
 > * `DirectoryArchivesOutputDirectory`
 > * `SanitizedBridgesWriteDirectory`
 > * `ExitlistOutputDirectory`
 > * `TorperfOutputDirectory`
 > by a simple `OutputPath` with the default value `out`.

 This is part of #18910.
 So, any changes for the other properties should be based on the commits of
 #18910.

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

Re: [tor-bugs] #20343 [Core Tor/Chutney]: Write a setup.py for chutney

2016-10-12 Thread Tor Bug Tracker & Wiki

#20343: Write a setup.py for chutney
--+--
 Reporter:  dawuud|  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  install   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => install
 * type:  defect => enhancement


Comment:

 Do we need chutney to be versioned to have a setup.py? (#20344)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20344 [Core Tor/Chutney]: Do chutney releases with semantic versioning

2016-10-12 Thread Tor Bug Tracker & Wiki

#20344: Do chutney releases with semantic versioning
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #20091
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem

2016-10-12 Thread Tor Bug Tracker & Wiki

#17868: base64_decode_nopad() destination buffer length problem
--+
 Reporter:  dgoulet   |  Owner:  nikkolasg
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19531| Points:  2
 Reviewer:  dgoulet   |Sponsor:  SponsorR-can
--+
Changes (by nikkolasg):

 * 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] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem

2016-10-12 Thread Tor Bug Tracker & Wiki

#17868: base64_decode_nopad() destination buffer length problem
--+
 Reporter:  dgoulet   |  Owner:  nikkolasg
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19531| Points:  2
 Reviewer:  dgoulet   |Sponsor:  SponsorR-can
--+

Comment (by nikkolasg):

 I don't know what is your schedule for 030 but if possible I'd like to
 continue working on it. As you say, I also think it's a good idea to make
 the whole baseXX api uniform and I got ideas for it (uniform return type,
 uniform argument types, etc).
 Would that be more reasonable to create one big issue for the
 uniformization of the baseXX api and then one sub-issue for each
 base{16,32,64} ?

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

Re: [tor-bugs] #18379 [Applications/Tor Browser]: Mouse Tracking Defenses in Tor Browser

2016-10-12 Thread Tor Bug Tracker & Wiki

#18379: Mouse Tracking Defenses in Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by jessRD):

 You are right; I am more than sure it will cause a glitch in script-
 generated trigger.
 Same issue with [http://pimion.com| Pimion - essay writers]

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:21 iwakeh]:
 > Replying to [comment:20 karsten]:
 > > [...] Shouldn't we instead remove those config options entirely, [...]
 >
 > This is only a warning that these will be deprecated.  They're still
 used, but already adressed in #20162.  But they should be removed here.
 That wouldn't be a small commit, though, and I'd rather have it separate.
 I'll add a new branch just up to that commit later today.

 Okay.  I was confused by the comment saying "only OutputPath is used".
 Looking forward to the new branch you're mentioning.

 > >  - Speaking of, can you include a change log entry for this commit?
 >
 > Sure!

 Thanks!

 > > [...] I wonder if we could simplify the configuration by avoiding that
 tri-state SyncType option and turning it into a boolean. [...]
 >
 > Sync-Options (this description should be added to package-info, when we
 agree):
 > There are currently three modules that can be synced: relaydescs,
 bridgedescs, and exitlists.
 >
 > A module can be turned on or off via its `*Activated` option, which is
 only configurable at start-up and determines if anything is run from this
 module.
 >
 > The runtime configurable tri-state `Sync*` option values are
 >
 > * `NoSync`:  for simply running the module w/o fetching additional data.
 Useful when just the directly (from the Tor network) accessible data is of
 interest, or when having access to bridgedescs etc.
 > * `Sync` performs the module run and then fetches data from other
 instances.
 > * `SyncOnly` just fetches data from other instances.  Useful for mirrors
 that don't have access to bridgedescs, or that fetch from a main instance
 they trust and don't have net access otherwise, etc.
 >
 > `Sync*` options can be adapted during runtime.  It is possible to switch
 to syncing and then turn it off during runtime.
 >
 > So, reducing the tri-state would complicate the combination of
 'activated' and sync-settings, which is separated from sync, i.e.
 `Scheduler` doesn't and shouldn't now about syncing.

 Hmm, I don't understand how the change I suggested would affect the
 ability to reconfigure at runtime.  I admit I didn't read that code yet
 (which comes in later commits, I think), but in theory it should still be
 possible to enable or disable syncing if it's yet another descriptor
 source.

 Here's how I'd explain configuring the relaydescs module to a new
 operator: "Want to collect relay descriptors?  Sure, just activate that
 module and also enable one or more descriptor sources: download from the
 directory authorities, read from a local directory, read from local cached
 descriptors, synchronize from other CollecTor instances.  If you don't
 enable any descriptor sources, you won't get any descriptors."

 This feels easier than: "Want to collect relay descriptors?  Sure, just
 activate that module and also enable between zero and three descriptors
 sources, and also consider synchronizing from other CollecTor instances."

 The three modules could still use the same code for synchronizing, so I'm
 not asking to change much code here.  But I'm worried that the tri-state
 config option will be harder to grasp for operators than it has to be.

 > >  - I found at least one long line that checkstyle should complain
 about, though I didn't run it myself.
 >
 > Oh, I usually run this at the last commit.  Will check again.

 Okay, no rush. :)

 > > In case you want to start working on any of these comments, can you
 please write `--fixup` commits that resolve those issues in this
 particular commit?  In any case, please don't modify commits 2 to 7 in
 that branch at this point, because I already started reviewing those.
 >
 > As said above, I'll add another branch with commits we agree on and in a
 way that the commits make sense in the final master version.

 Thanks!

 > > More tomorrow.  Thanks!
 >
 > Thanks, for reading your way through all that un-commented code!

 Still reviewing the other other commits...

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

Re: [tor-bugs] #20184 [Applications/Tor Browser]: OS X builds are still not reproducible on some machines

2016-10-12 Thread Tor Bug Tracker & Wiki

#20184: OS X builds are still not reproducible on some machines
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-gitian, GeorgKoppen201610,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:8 arthuredelstein]:
 > I happened to notice in the patch the following change:
 > {{{
 > -  i686-apple-darwin11-install_name_tool -change
 $INSTDIR/libevent/lib/$LIBEVENT_FILE @executable_path/$LIBEVENT_FILE tor
 > +  x86_64-apple-darwin10-install_name_tool -change
 $INSTDIR/libevent/lib/$LIBEVENT_FILE @executable_path/$LIBEVENT_FILE tor
 > }}}
 > Is there a reason this is changing from "darwin11" to "darwin10"? I'm
 not familiar with this tool, so sorry if this is a naive question.

 The new `cctools` which we are using now is compiled for the darwin10
 target. That's the only reason for that change. We are not doing that
 compilation ourselves right now, though, yet (#9711).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20343 [Core Tor/Chutney]: Write a setup.py for chutney

2016-10-12 Thread Tor Bug Tracker & Wiki

#20343: Write a setup.py for chutney
--+--
 Reporter:  dawuud|  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I want to use the chutney API for various projects. It would make it much
 easier to use if it had a proper setup.py

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-12 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:20 karsten]:
 > ...
 >  - It seems we're deprecating a few config options by adding a comment
 to the default `collector.properties` and not paying attention to those
 options in the code anymore.  Shouldn't we instead remove those config
 options entirely, so that operators notice for sure that they need to
 change these config options?  We could mention this in the change log as
 medium change.
 >

 This is only a warning that these will be deprecated.  They're still used,
 but already adressed in #20162.  But they should be removed here.  That
 wouldn't be a small commit, though, and I'd rather have it separate.  I'll
 add a new branch just up to that commit later today.

 >  - Speaking of, can you include a change log entry for this commit?
 >

 Sure!

 >  - I wonder if we could simplify the configuration by avoiding that tri-
 state SyncType option and turning it into a boolean.  Consider
 `ImportCachedRelayDescriptors`, `ImportDirectoryArchives`, and
 `DownloadRelayDescriptors` in the relaydescs module.  We could just add a
 fourth option `SyncRelayDescriptors` that can be `true` or `false`.
 Basically, syncing descriptors from other CollecTor instances would be the
 fourth source for collecting relay descriptors.  This shouldn't change
 much in the code you wrote, but it might make things a bit simpler for
 future operators.  For bridge descriptors and exit lists there would have
 to be two new options to activate the current sources, that is, sanitize
 bridge descriptors found in a local directory or download exit lists from
 the exit list server.
 >

 Sync-Options (this description should be added to package-info, when we
 agree):
 There are currently three modules that can be synced: relaydescs,
 bridgedescs, and exitlists.

 A module can be turned on or off via its `*Activated` option, which is
 only configurable at start-up and determines if anything is run from this
 module.

 The runtime configurable tri-state `Sync*` option values are

 * `NoSync`:  for simply running the module w/o fetching additional data.
 Useful when just the directly (from the Tor network) accessible data is of
 interest, or when having access to bridgedescs etc.
 * `Sync` performs the module run and then fetches data from other
 instances.
 * `SyncOnly` just fetches data from other instances.  Useful for mirrors
 that don't have access to bridgedescs, or that fetch from a main instance
 they trust and don't have net access otherwise, etc.

 `Sync*` options can be adapted during runtime.  It is possible to switch
 to syncing and then turn it off during runtime.

 So, reducing the tri-state would complicate the combination of 'activated'
 and sync-settings, which is separated from sync, i.e. `Scheduler` doesn't
 and shouldn't now about syncing.

 >  - I found at least one long line that checkstyle should complain about,
 though I didn't run it myself.

 Oh, I usually run this at the last commit.  Will check again.

 >
 > In case you want to start working on any of these comments, can you
 please write `--fixup` commits that resolve those issues in this
 particular commit?  In any case, please don't modify commits 2 to 7 in
 that branch at this point, because I already started reviewing those.

 As said above, I'll add another branch with commits we agree on and in a
 way that the commits make sense in the final master version.

 >
 > More tomorrow.  Thanks!

 Thanks, for reading your way through all that un-commented code!

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

Re: [tor-bugs] #20342 [Core Tor/Tor]: Add tor-gencert.exe to tor expert bundle and tor nightlies

2016-10-12 Thread Tor Bug Tracker & Wiki

#20342: Add tor-gencert.exe to tor expert bundle and tor nightlies
---+--
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  029-proposed, testing  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * cc: gk (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

73 matches

Mail list logo