Re: [tor-bugs] #20261 [Core Tor]: tor_fragile_assert() when Unix domain socket is used

[Tor Bug Tracker & Wiki]

#20261: tor_fragile_assert() when Unix domain socket is used
---+
 Reporter:  mcs|  Owner:  yawning
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor   |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  tbb-needs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mcs):

 Adding `NoIsolateClientAddr` did not fix the problem for me on OSX. I will
 attach a stack trace.

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

[Tor Bug Tracker & Wiki]

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, review-group-9   |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by pastly):

 I've figured out the bare basics of chutney. I ran two simulations: one
 'basic-min' with the new code and one 'basic-min-mixed' with new code and
 0.2.7.6.

 I will attach the data directories from each.

 The mixed network uses consensus method 20 and the homogeneous network
 uses 24, the new one.

 I'll need a little hand holding or pointing in the right direction if you
 still want me to write unit tests. I haven't written any tests for
 anything ever (gasp!)

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

[Tor Bug Tracker & Wiki]

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

Comment (by twim):

 Replying to [comment:19 teor]:
 > OK, can you test meek?
 Sure.

 > Also, let's say we do set the delay to 3s:
 > * how are you testing whether the descriptor has stabilised?
 I look at the `is_dirty` dynamics. If it gets dirty after 3s then it is
 too low. For now it isn't.

 > * can you warn the user when the descriptor changes after this delay?
 (perhaps between delay and 2*delay?) That way, we'll get feedback if we've
 set the delay too low, and users will understand why their onion service
 is hard to reach. (This might not be possible or easy - if not, that's ok.
 I am also happy to help you write the patch if I know how you're testing
 it.)

 The user can be warned by a log message (easy) or by introducing a control
 event which is emitted when descriptor gets dirty after it was published
 (more code, bit complicated).
 Do we have some statistics on intropoint circuit half-life? I think that
 this delay should be based on it. And learning this half-life is what
 we're effectively doing here.

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

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

[Tor Bug Tracker & Wiki]

#20262: Onion services startup time always gets revealed
--+--
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by twim):

 * status:  new => needs_review
 * component:  - Select a component => Core Tor/Tor
 * severity:  Normal => Major


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20262 [- Select a component]: Onion services startup time always gets revealed

[Tor Bug Tracker & Wiki]

#20262: Onion services startup time always gets revealed
--+-
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Due to dead code in `rend_consider_services_upload()` startup time of
 onion services always gets revealed.

 If service descriptor is not uploaded yet we add random delay from
 [rendinitialpostdelay;rendinitialpostdelay+rand(2*rendpostperiod)] (
 [30s;30s+2h] ):
 {{{
 if (!service->next_upload_time) {
   service->next_upload_time =
 now + rendinitialpostdelay + crypto_rand_int(2*rendpostperiod);

 }}}

 But this delay is useless when we're checking whether we should upload:

 {{{
 if (intro_points_ready &&
 (service->next_upload_time < now ||
 (service->desc_is_dirty &&
  service->desc_is_dirty < now-rendinitialpostdelay))) {
   /* Upload */
 }}}

 Because descriptor is dirty for never-yet-uploaded services it always gets
 uploaded after being stable for `rendinitialpostdelay` seconds.
 `next_upload_time` is further in future than `rendinitialpostdelay`
 stabilization stuff.
 So it goes.

 I made a patch to unbork this function to work properly.
 But it raised a problem. We got used to expect that descriptors are going
 to be uploaded pretty soon. But 'now' they will be uploaded with delay up
 to 2h. That's not okay. Should we make a `torrc` option like
 `RevealOnionServiceStartupTime` that defaults to 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] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #20261 [Core Tor]: tor_fragile_assert() when Unix domain socket is used

[Tor Bug Tracker & Wiki]

#20261: tor_fragile_assert() when Unix domain socket is used
---+
 Reporter:  mcs|  Owner:  yawning
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor   |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  tbb-needs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mcs):

 Yawning says we can work around this by adding the `NoIsolateClientAddr`
 to the SocksPort isolation flags.

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

Re: [tor-bugs] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

[Tor Bug Tracker & Wiki]

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:15 gk]:
 > Yes, and tor's a885271c08d2337b35c203c0b27509d0aa32dbf6 made it just
 visible... Want to file a bug against tor with the `tbb-needs` keyword
 once you debugged the issue?

 I created #20261. I also talked to Yawning and teor about this issue.

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

[tor-bugs] #20261 [Core Tor]: tor_fragile_assert() when Unix domain socket is used

[Tor Bug Tracker & Wiki]

#20261: tor_fragile_assert() when Unix domain socket is used
--+
 Reporter:  mcs   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal|   Keywords:  tbb-needs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 When a Unix domain socket is used for the SocksPort, a soft assertion is
 triggered inside tor_addr_compare_masked(). Log message:
  Sep 28 11:34:45.000 [warn] tor_bug_occurred_(): Bug:
 src/common/address.c:1119: tor_addr_compare_masked: This line should not
 have been reached. (Future instances of this warning will be silenced.)
 (on Tor 0.2.9.2-alpha 00ec701f8343f552)

 The config used is:
  SocksPort unix:/Users/.../TorBrowser-Data/Tor/socks.socket IPv6Traffic
 PreferIPv6 KeepAliveIsolateSOCKSAuth

 For more details, see: ticket:20111#comment:13

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tordevSZ0):

 See the attachment above for a snapshot of a network monitor showing the
 connection to the meek server failing abruptly.
 
https://trac.torproject.org/projects/tor/attachment/ticket/20250/tbb6.5a3conn.png

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tordevSZ0):

 Replying to [comment:16 dcf]:
 > Replying to [comment:12 tordevSZ0]:
 > > This may be an error on my part, but when using a fresh install of
 6.5a3 on 10.12, the initial Tor Network Settings window opens, but fails
 to connect to the tor control port, even with
 extensions.torlauncher.control_port_use_socket pref set to false in
 prefs.js.
 >
 > I think I know why setting this pref appeared to have no effect. You
 have to edit the prefs.js file found under `~/Library/Application Support
 /TorBrowser-Data`, not the one in the installation directory under
 `/Applications`. The one under `/Applications` doesn't have an effect once
 it is copied to `~/Library/Application Support/TorBrowser-Data`.

 Placing TorBrowser.app (v6.5a3) on the Desktop solved the control port
 issue, but connecting with meek had the same issue as 6.0.5. The first
 time, the connection UI completed, traffic went through to the meek server
 for around a minute and a half (longer than normal, yes, but I think this
 may have been a coincidence (seen this long on 6.0.5 also). I tested a few
 more times and it behaved as with 6.0.5, lasting very short period and
 stopping abruptly. Logs were also essentially the same as I have already
 posted.

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

Re: [tor-bugs] #20234 [Metrics/CollecTor]: Define CollecTor's file-structure protocol (was: Define CollecTor's file-structure protocol 1.0)

[Tor Bug Tracker & Wiki]

#20234: Define CollecTor's file-structure protocol
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Removed the version number from ticket title, as this task is about
 writing this protocol for the first time, not about a particular version
 of it.

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

Re: [tor-bugs] #20234 [Metrics/CollecTor]: Define CollecTor's file-structure protocol 1.0

[Tor Bug Tracker & Wiki]

#20234: Define CollecTor's file-structure protocol 1.0
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 As talked about in irc and described above, please find the new version
 0.9 in
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-20234&id=b2aa5a6090953ca7e4b30c4eb2801c098f05a9c5
 my new branch] for 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] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tordevSZ0):

 I edited ~/Library/Application Support/TorBrowser-
 Data/Browser//prefs.js. Will try to test it again with the .app
 outside /Applications and extensions.torlauncher.control_port_use_socket
 pref set to false in prefs.js (Application Support).

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

Re: [tor-bugs] #20259 [Applications]: Entry guard node always United States

[Tor Bug Tracker & Wiki]

#20259: Entry guard node always United States
--+--
 Reporter:  tchaffee  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 This is normal. Tor chooses an entry guard at random, and keeps that
 guard. This protects you from choosing a new guard every time you start
 up, until you choose a bad 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] #20082 [Core Tor/Tor]: Lower initial descriptor upload delay for ephemeral services

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:18 twim]:
 > Replying to [comment:17 teor]:
 > > > By the way, when I was testing this patch I found out that 3s in
 enough for an onion service to stabilize and is much better for UX
 compared to 5s.
 > >
 > > 3s from a desktop or VPS on a fast network in North America or Europe?
 > > I'd be keen on some testing on mobile and in other countries, if we
 want to push the delay as low as it can go.
 >
 > From an old desktop over obfs4 bridge and shitty WiFi connection. Don't
 think that it would be totally different on mobile (Orbot).
 > Also meek should be tested since there are some inherent HTTP delays up
 to 1s (AFAIK).

 OK, can you test meek?
 Also, let's say we do set the delay to 3s:
 * how are you testing whether the descriptor has stabilised?
 * can you warn the user when the descriptor changes after this delay?
 (perhaps between delay and 2*delay?) That way, we'll get feedback if we've
 set the delay too low, and users will understand why their onion service
 is hard to reach. (This might not be possible or easy - if not, that's ok.
 I am also happy to help you write the patch if I know how you're testing
 it.)

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:12 tordevSZ0]:
 > This may be an error on my part, but when using a fresh install of 6.5a3
 on 10.12, the initial Tor Network Settings window opens, but fails to
 connect to the tor control port, even with
 extensions.torlauncher.control_port_use_socket pref set to false in
 prefs.js.

 I think I know why setting this pref appeared to have no effect. You have
 to edit the prefs.js file found under `~/Library/Application Support
 /TorBrowser-Data`, not the one in the installation directory under
 `/Applications`. The one under `/Applications` doesn't have an effect once
 it is copied to `~/Library/Application Support/TorBrowser-Data`.

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:12 tordevSZ0]:
 > Replying to [comment:11 dcf]:
 > > Replying to [ticket:20250 tordevSZ0]:
 > > > Having issues using the meek pluggable transports on macOS 10.12
 installation with a fresh install of TorBrowser.
 > >
 > > Please try the alpha release 6.5a3. If it works for you, that means we
 have to use a newer version of Go to compile the next stable release.
 >
 > This may be an error on my part, but when using a fresh install of 6.5a3
 on 10.12, the initial Tor Network Settings window opens, but fails to
 connect to the tor control port, even with
 extensions.torlauncher.control_port_use_socket pref set to false in
 prefs.js. I monitor file accesses by applications and noticed that the
 TorBrowser.app, after creating and writing to the '~/Library/Application
 Support/TorBrowser-Data' directory as it should, then tries to write to
 the non-existent '~/Library/Application', and then times out trying to
 connect to tor.real with the message 'failed to connect to control port'.
 It might be something else, but this makes me wonder whether a hard-coded
 path with spaces in it isn't written properly - e.g. ~/Library/Application
 Support which would yield ~/Library/Application with an error instead of
 '~/Library/Application Support'.

 What you describe really sounds like #20210 (also #20215, #18753), but
 that should have been fixed by setting
 `extensions.torlauncher.control_port_use_socket=false`.

 Please try installing the alpha bundle into a directory other than
 /Applications, for example in your home directory or on your desktop. That
 should work around the space issue either way.

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Yes, dragging 6.5a3 just to your desktop for testing purposes should help
 here.

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tordevSZ0):

 Replying to [comment:11 dcf]:
 > Replying to [ticket:20250 tordevSZ0]:
 > > Having issues using the meek pluggable transports on macOS 10.12
 installation with a fresh install of TorBrowser.
 >
 > Are you using the stable release 6.0.5, or the alpha release 6.5a3?
 >
 > In the stable 6.0.5, meek is compiled with Go 1.4.3. In the alpha 6.5a3,
 meek is compiled with Go 1.6.3. Go 1.6.3 has
 [https://github.com/golang/go/issues/16354 a fix] for Sierra; Go 1.4.3
 does not have the fix. If this Go bug is the cause, then the alpha release
 may work for you where the stable release does not.
 >
 > Note that there is an unrelated bug in the alpha release, #20030, which
 means that you will have to manually kill the firefox and meek-client
 processes after you close the browser.
 >
 > Please try the alpha release 6.5a3. If it works for you, that means we
 have to use a newer version of Go to compile the next stable release.

 I added an attachment to the main ticket showing TorBrowser.app trying to
 write to the non-existent directory '~/Library/Application'
 https://trac.torproject.org/projects/tor/attachment/ticket/20250/tbb6.5a3.png

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

Re: [tor-bugs] #20250 [Obfuscation/meek]: macOS 10.12 TorBrowser meek pluggable transport issues

[Tor Bug Tracker & Wiki]

#20250: macOS 10.12 TorBrowser meek pluggable transport issues
-+-
 Reporter:  tordevSZ0|  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Obfuscation/meek |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  meek, macOS, TorBrowser, 10.12,  |  Actual Points:
  sierra, macOS  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tordevSZ0):

 Replying to [comment:11 dcf]:
 > Replying to [ticket:20250 tordevSZ0]:
 > > Having issues using the meek pluggable transports on macOS 10.12
 installation with a fresh install of TorBrowser.
 >
 > Are you using the stable release 6.0.5, or the alpha release 6.5a3?
 >
 > In the stable 6.0.5, meek is compiled with Go 1.4.3. In the alpha 6.5a3,
 meek is compiled with Go 1.6.3. Go 1.6.3 has
 [https://github.com/golang/go/issues/16354 a fix] for Sierra; Go 1.4.3
 does not have the fix. If this Go bug is the cause, then the alpha release
 may work for you where the stable release does not.
 >
 > Note that there is an unrelated bug in the alpha release, #20030, which
 means that you will have to manually kill the firefox and meek-client
 processes after you close the browser.
 >
 > Please try the alpha release 6.5a3. If it works for you, that means we
 have to use a newer version of Go to compile the next stable release.


 This may be an error on my part, but when using a fresh install of 6.5a3
 on 10.12, the initial Tor Network Settings window opens, but fails to
 connect to the tor control port, even with
 extensions.torlauncher.control_port_use_socket pref set to false in
 prefs.js. I monitor file accesses by applications and noticed that the
 TorBrowser.app, after creating and writing to the '~/Library/Application
 Support/TorBrowser-Data' directory as it should, then tries to write to
 the non-existent '~/Library/Application', and then times out trying to
 connect to tor.real with the message 'failed to connect to control port'.
 It might be something else, but this makes me wonder whether a hard-coded
 path with spaces in it isn't written properly - e.g. ~/Library/Application
 Support which would yield ~/Library/Application with an error instead of
 '~/Library/Application Support'.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20260 [Applications/Tor Browser]: Add mitigating action to window size warning

[Tor Bug Tracker & Wiki]

#20260: Add mitigating action to window size warning
--+--
 Reporter:  lunar |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor Browser will now warn users when they change the window size. That's
 great. But the associated button just says “Ok”. I believe it would be
 better to provide more active buttons that just one that will dismiss the
 warning.

 How about:

  * Unmaximize (when maximized) (or is it too jargony?)
  * Restore common window size (change to the next rounded dimension)
  * I don’t mind sites learning the size of my screen

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

Re: [tor-bugs] #20227 [Metrics/Metrics website]: Remove .csv file with statistics about agreement or disagreement among the directory authorities

[Tor Bug Tracker & Wiki]

#20227: Remove .csv file with statistics about agreement or disagreement among 
the
directory authorities
-+
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 All done.  Closing.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by twim):

 Replying to [comment:17 teor]:
 > > By the way, when I was testing this patch I found out that 3s in
 enough for an onion service to stabilize and is much better for UX
 compared to 5s.
 >
 > 3s from a desktop or VPS on a fast network in North America or Europe?
 > I'd be keen on some testing on mobile and in other countries, if we want
 to push the delay as low as it can go.

 From an old desktop over obfs4 bridge and shitty WiFi connection. Don't
 think that it would be totally different on mobile (Orbot).
 Also meek should be tested since there are some inherent HTTP delays up to
 1s (AFAIK).

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:16 twim]:
 > Replying to [comment:15 teor]:
 > > My impression of the tor-dev discussion is that we wanted to lower the
 initial post delay for all hidden services, not just ephemeral hidden
 services.
 > > Please revise the patch to make this happen, or let me know that's not
 what we agreed on tor-dev.
 >
 > Sure, done. Just not sure that we have really agreed upon it.
 >
 > By the way, when I was testing this patch I found out that 3s in enough
 for an onion service to stabilize and is much better for UX compared to
 5s.

 3s from a desktop or VPS on a fast network in North America or Europe?
 I'd be keen on some testing on mobile and in other countries, if we want
 to push the delay as low as it can go.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by twim):

 Replying to [comment:15 teor]:
 > My impression of the tor-dev discussion is that we wanted to lower the
 initial post delay for all hidden services, not just ephemeral hidden
 services.
 > Please revise the patch to make this happen, or let me know that's not
 what we agreed on tor-dev.

 Sure, done. Just not sure that we have really agreed upon it.

 By the way, when I was testing this patch I found out that 3s in enough
 for an onion service to stabilize and is much better for UX compared to
 5s.

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision
 * keywords:  tor-hs, research, proposal-needed? => tor-hs, research,
 proposal-needed?, TorCoreTeam201609


Comment:

 My impression of the tor-dev discussion is that we wanted to lower the
 initial post delay for all hidden services, not just ephemeral hidden
 services.

 Please revise the patch to make this happen, or let me know that's not
 what we agreed on tor-dev.

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

Re: [tor-bugs] #20227 [Metrics/Metrics website]: Remove .csv file with statistics about agreement or disagreement among the directory authorities

[Tor Bug Tracker & Wiki]

#20227: Remove .csv file with statistics about agreement or disagreement among 
the
directory authorities
-+---
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 As briefly discussed on IRC today, the main idea behind this visualization
 was to try out a new graphing engine.  I don't think that we'd assign this
 task to a new volunteer.  So it's probably okay to just take it out and
 make a local note or something.  Will do.

 However, I just realized that we should maybe take it out in two steps:
 first, stop updating the .csv file which includes taking out all code that
 produces it, and second, removing the .csv file.  That's how we replaced
 [https://metrics.torproject.org/connbidirect-data.html connbidirect.csv]
 with [https://metrics.torproject.org/connbidirect2-data.html
 connbidirect2.csv] in January 2016, and now that I look at that, I'd say
 it's time to take out the data page.  Will do.

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

Re: [tor-bugs] #19317 [Metrics/CollecTor]: Sanitize TCP ports in bridge descriptors

[Tor Bug Tracker & Wiki]

#19317: Sanitize TCP ports in bridge descriptors
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Okay, I think everything's merged, and the
 [https://trac.torproject.org/projects/tor/ticket/19755#comment:18
 remaining suggestions are referenced from another ticket].  Closing.
 Thanks!

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

Re: [tor-bugs] #20257 [Applications/Tor Messenger]: Can't move window around after upgrading to macOS Sierra

[Tor Bug Tracker & Wiki]

#20257: Can't move window around after upgrading to macOS Sierra
+---
 Reporter:  valberg |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  mac sierra macos|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by arlolra):

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


Comment:

 Thanks for reporting!

 This is duplicate of #20204 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

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

[Tor Bug Tracker & Wiki]

#20082: Lower initial descriptor upload delay for ephemeral services
+--
 Reporter:  twim|  Owner:
 Type:  enhancement | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, research, proposal-needed?  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  SponsorR-can
+--
Changes (by twim):

 * 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] #20234 [Metrics/CollecTor]: Define CollecTor's file-structure protocol 1.0

[Tor Bug Tracker & Wiki]

#20234: Define CollecTor's file-structure protocol 1.0
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 Yes, the audience sort of grew while writing and it's good to take a step
 back and answer this question first.
 Suggestions for next steps:

 * We agree that we should write this for client and not internal audience.
  - Keep the first four sections? Maybe adapt 5 to one about tar-ball
 contents (below month), as most of it is written already?
  - Remove 6. and 7. these should later be part of the operator
 documentation.

 * Then there is a mixture of change proposal and documentation for the
 'index*' part to be resolved.
  - Have version 0.9 with the "index.json*" as the main CollecTor serves it
 and reserve the change for 1.0 (together with the vote-issue #20228)?

 Thoughts?

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

Re: [tor-bugs] #20227 [Metrics/Metrics website]: Remove .csv file with statistics about agreement or disagreement among the directory authorities

[Tor Bug Tracker & Wiki]

#20227: Remove .csv file with statistics about agreement or disagreement among 
the
directory authorities
-+---
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  new => needs_information


Comment:

 That's what version control is for.  Only that one hardly looks back into
 that history.
 Where to keep a reference and is there information that would be helpful
 taking the task up again in future?
 Would completing it be a possible task to add to our volunteering page?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20259 [Applications]: Entry guard node always United States

[Tor Bug Tracker & Wiki]

#20259: Entry guard node always United States
--+--
 Reporter:  tchaffee  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Suspect that US gov't has found a new way to link traffic to Tor users...

 Noticed that every time I started v6.0.5 on Windows, entry guard node was
 consistently United States.  Even after doing multiple new circuit
 requests, entry guard was always United States.  Middle and exit nodes
 changed when new circuit was requested, entry always US.

 Deleted the Tor browser folder, reinstalled v6.0, updated it, now working
 normally.

 I can provide the deleted Tor browser folder if that helps.

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

Re: [tor-bugs] #20258 [Applications/Quality Assurance and Testing]: Make the Tor archive on OS X reproducible as well

[Tor Bug Tracker & Wiki]

#20258: Make the Tor archive on OS X reproducible as well
-+-
 Reporter:  gk   |  Owner:
 |  cypherpunks
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian, GeorgKoppen201609,   |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-gitian => tbb-gitian, GeorgKoppen201609,
 TorBrowserTeam201609R


Comment:

 bug_20258 (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20258&id=bfecaab2a6585e958bfbad9cd70fc9dfb5d2aad7)
 in my public tor-browser-bundle repo has a proposed fix for 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

[tor-bugs] #20258 [Applications/Quality Assurance and Testing]: Make the Tor archive on OS X reproducible as well

[Tor Bug Tracker & Wiki]

#20258: Make the Tor archive on OS X reproducible as well
-+-
 Reporter:  gk   |  Owner:  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|
 Severity:  Normal   |   Keywords:  tbb-gitian
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While doing #18845 and #18291 it seems we have forgotten the Tor archive
 on OS X.

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

Re: [tor-bugs] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

[Tor Bug Tracker & Wiki]

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Yes, and tor's a885271c08d2337b35c203c0b27509d0aa32dbf6 made it just
 visible... Want to file a bug against tor with the `tbb-needs` keyword
 once you debugged the issue?

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

Re: [tor-bugs] #20234 [Metrics/CollecTor]: Define CollecTor's file-structure protocol 1.0

[Tor Bug Tracker & Wiki]

#20234: Define CollecTor's file-structure protocol 1.0
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Wait.  Let me go back one step and ask: why are we writing this document
 now?  Is this for ourselves, for future contributors, for operators, or
 even for users?  And can't we update or extend the existing documentation
 on `/index.html` with the most relevant missing parts?

 When I created this ticket I was thinking of coming up with a common
 structure for the ''web-facing'' parts of CollecTor, so that we can move
 forward with synchronization between CollecTor instances.  I was not
 thinking of an implementation-level documentation of how we're using the
 file system, and I don't really see the urgent need for that.  (When I
 mentioned the `stats/` directory and others, I basically wanted to give an
 example of something that, IMHO, does not fit into the protocol rather
 than suggest to include it.  I should have phrased that more clearly.)

 Can we, for now, focus on any open questions you have about CollecTor's
 file structure and postpone the decision what documentation of the local
 file system structure we need?

 And can we make a decision how we're changing existing web-facing
 directories like moving `/index.json*` to `/index/index.json*` on the main
 CollecTor instance?

 Don't get me wrong, I do see the value of documentation, but I also see
 the cost of writing, reviewing, revising, and maintaining documentation,
 and in this case I don't yet see how the value is greater than the costs.

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

Re: [tor-bugs] #20257 [Applications/Tor Messenger]: Can't move window around after upgrading to macOS Sierra

[Tor Bug Tracker & Wiki]

#20257: Can't move window around after upgrading to macOS Sierra
+-
 Reporter:  valberg |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  mac sierra macos|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by valberg):

 Replying to [ticket:20257 valberg]:
 > I have recently upgraded to macOS Sierra, and this resulted in that I
 can not move "Contacts" and chat window around. Oddly enough I'm able to
 move the "Accounts" window around.
 >
 > This happens in both in the latest 1.x (can't remember the exact
 version) and in 0.2.0b2.

 I forgot to mention that resizing windows works as expected.

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

[tor-bugs] #20257 [Applications/Tor Messenger]: Can't move window around after upgrading to macOS Sierra

[Tor Bug Tracker & Wiki]

#20257: Can't move window around after upgrading to macOS Sierra
+--
 Reporter:  valberg |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:  mac sierra macos
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 I have recently upgraded to macOS Sierra, and this resulted in that I can
 not move "Contacts" and chat window around. Oddly enough I'm able to move
 the "Accounts" window around.

 This happens in both in the latest 1.x (can't remember the exact version)
 and in 0.2.0b2.

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

Re: [tor-bugs] #19999 [Core Tor/Tor]: Maybe test-cases should complete without BUG warnings?

[Tor Bug Tracker & Wiki]

#1: Maybe test-cases should complete without BUG warnings?
---+---
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  testing TorCoreTeam201609  |  Actual Points:  3
Parent ID: | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by rubiate):

 rend_cache/store_v2_desc_as_client will occasionally cough up a warning:

 [warn] rend_cache_store_v2_desc_as_client(): Bug: Couldn't decode
 base32 [scrubbed] for descriptor id. (on Tor 0.2.9.3-alpha-dev
 153ff4f559d9b7ee)

 The problem is on test_rendcache.c:158, it tries to test an incorrect ID
 by incrementing the first character of the base32 ID, which can make it
 invalid base32 depending on what the first character is. The test still
 passes because rend_cache_store_v2_desc_as_client() still fails, just for
 a different reason.

 Possible fix, go down if it can't go up:

 {{{
 diff --git a/src/test/test_rendcache.c b/src/test/test_rendcache.c
 index a5d3f35..baadf44 100644
 --- a/src/test/test_rendcache.c
 +++ b/src/test/test_rendcache.c
 @@ -87,7 +87,7 @@ test_rend_cache_lookup_entry(void *data)
  static void
  test_rend_cache_store_v2_desc_as_client(void *data)
  {
 -  int ret;
 +  int ret, mod;
rend_data_t *mock_rend_query;
char desc_id_base32[REND_DESC_ID_V2_LEN_BASE32 + 1];
rend_cache_entry_t *entry = NULL;
 @@ -155,12 +155,19 @@ test_rend_cache_store_v2_desc_as_client(void *data)
// Test incorrect descriptor ID
rend_cache_init();
mock_rend_query = mock_rend_data(service_id);
 -  desc_id_base32[0]++;
 +
 +  /* avoid incrementing beyond valid base32 characters */
 +  mod = (desc_id_base32[0] == 'z' ||
 + desc_id_base32[0] == 'Z' ||
 + desc_id_base32[0] == '7') ? -1 : 1;
 +
 +  desc_id_base32[0] += mod;
 +
ret = rend_cache_store_v2_desc_as_client(desc_holder->desc_str,
 desc_id_base32,
 mock_rend_query,
 NULL);
tt_int_op(ret, OP_EQ, -1);
 -  desc_id_base32[0]--;
 +  desc_id_base32[0] -= mod;
rend_cache_free_all();

// Test too old descriptor
 }}}

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

Re: [tor-bugs] #9145 [Applications/Tor Browser]: TBB 3.0a1 crashes on startup on Win7

[Tor Bug Tracker & Wiki]

#9145: TBB 3.0a1 crashes on startup on Win7
-+-
 Reporter:  dope457  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, Windows, Hardware-|  Actual Points:
  acceleration, fuck-mingw   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Looking at this f*ck-mingw bug, the GCC ticket (this is actually a GCC bug
 it seems) is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384.

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

Re: [tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201609R   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by gk):

 * keywords:
 tbb-security, tbb-crash, tbb-usability-stoppoint-app, fuck-mingw-gcc,
 GeorgKoppen201609, TorBrowserTeam201609
 =>
 tbb-security, tbb-crash, tbb-usability-stoppoint-app, fuck-mingw-gcc,
 GeorgKoppen201609, TorBrowserTeam201609R
 * status:  needs_revision => needs_review


Comment:

 Alright, the tor-browser patches have not changed. They can still be found
 at

 https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_13893_v3

 The tor-browser-bundle commit up for review is now

 https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_13893_v5&id=70ea13b3e3dc09c317be02d8d07eb175547f2d2b

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

Re: [tor-bugs] #20228 [Metrics/CollecTor]: Append all votes with same valid-after time to a single file in `recent/`

[Tor Bug Tracker & Wiki]

#20228: Append all votes with same valid-after time to a single file in 
`recent/`
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:3 iwakeh]:
 > * Regarding grouping by download vs. published time which came up in
 #20234, too.
 >  Let's have the discussion for all descriptors here, if this is ok?
 >  1. Grouping by published time brings more data consistency between
 CollecTor instances, as their download times for the same descriptors
 surely differ often.

 Agreed, I guess we can assume that files in the `recent/` directories
 might differ between CollecTor instances.  But is that important, as long
 as the set of contained descriptors with publication time in the past,
 say, 60 hours is 99.9% the same?  I mean, it's still possible and very
 likely that files by publication hour would contain descriptors in
 different orders.  Do we care?

 >  2. Grouping by download time means keeping track of a data item, i.e.
 download time, that so far is not part of the Tor protocol.  Why introduce
 it for descriptors that provide a published time?  Which is the download
 time after syncing descriptors: the initial download by the supplying
 CollecTor or the sync-download-time by the receiving one?

 Right now, a CollecTor instance records the timestamp when starting to
 download and uses that as file name for the descriptors file where it
 appends all descriptors it learns about in that run.  That would include
 descriptors found via initial download or via synchronization from other
 instances.  And 72 hours later, when the file gets deleted, the download
 time will not be relevant anymore.

 >  3. Regarding #20234:comment:5: Clients might not be interested in past
 or future (according published time) descriptors and just download the
 file they consider current, if it changed since their last visit.

 Right, this is an important argument for storing descriptors by published
 hour, so that clients can retrieve them easily.  However, the presumption
 there is that the client knows the publication time of a descriptor before
 downloading something, and that's not always the case.  It might be that
 the client would have to download several files and search for the
 descriptor it's looking for.

 And the most important argument against storing descriptors by published
 hour is that clients that just want the new descriptors will have to
 download about 8 files per hour (due to #20234) rather than 1, where 6 or
 7 of these files contain mostly the same descriptors as before.

 > * Regarding the notice:  I think the two week time frame is fine.

 Sounds good.  Let's first conclude on something here and then tell the
 world.

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

Re: [tor-bugs] #20160 [Applications/Tor Browser]: Backport - MP3 playback is broken

[Tor Bug Tracker & Wiki]

#20160: Backport - MP3 playback is broken
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-crash, tbb-easy, |  Actual Points:
  TorBrowserTeam201609R, GeorgKoppen201609   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Okay, let's test that in the next alpha. I applied all three Mozilla
 patches to tor-browser-45.4.0esr-6.5-1 (commit
 57bdfc8fded25c4d6952208e7e2561509d57f7c5,
 2b459feaa5713f0b2c3d6595e677290cdcc8f9ca, and
 6715852d4487a4b3176c70f34358f5894954bbe2).

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