Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pospeselr):

 Ok uploaded new patch without white-space issues and with adjusted if
 spacing and mcs's suggested code changes.

 Rest of the night goes to seeing if I can build OSX flavor using rbm.

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

Re: [tor-bugs] #22988 [Internal Services/Service - trac]: Make all trac child tickets have the same headers and inherit fields

[Tor Bug Tracker & Wiki]

#22988: Make all trac child tickets have the same headers and inherit fields
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 Replying to [comment:3 qbi]:
 > Changes to trac.ini have to be made via command line and not via web
 interface. @teor, should I change the settings as you initially proposed?

 Yes, please.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 * Most comments addressed. Note client IP address is now added to
 `opt.relayURL` before dialing websocket.


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

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

Re: [tor-bugs] #22988 [Internal Services/Service - trac]: Make all trac child tickets have the same headers and inherit fields

[Tor Bug Tracker & Wiki]

#22988: Make all trac child tickets have the same headers and inherit fields
--+-
 Reporter:  teor  |  Owner:  qbi
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by qbi):

 Changes to trac.ini have to be made via command line and not via web
 interface. @teor, should I change the settings as you initially proposed?

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

Re: [tor-bugs] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Hmm, no, as of today I'm not convinced that this is a good idea. It might
 be and I'm not seeing it yet, or how it would work for other sanitized
 descriptors. But I'd rather merge something simple in the next couple of
 days and not rush this somewhat major design change. I agree that there's
 no actual sanitizing code in metrics-lib. But except for this new
 interface, there's also no other interface in metrics-lib where one can
 plug in sanitizing code. Avoiding duplicate code is good, but keeping
 interfaces small and intuitive is good, too. Let's open a ticket for that
 and do it in a separate step when we have more time to think about it.

 Here's some more feedback on the `LogDescriptor` interface:
  - The documentation of `TYPE` says that the name should include a string.
 But who should make sure that this is the case? The application developer?
 Can you rephrase that to say what is expected here?
  - Some of the method descriptions are written in 3rd person ("Returns
 ..."), some in 2nd person ("Return ..."). I believe that 3rd person is
 preferred, though we're not doing that consistently in the rest of
 metrics-lib. But we should at least try to do it consistently in one
 interface.
  - "yyymmdd" -> "mmdd" in `getLogDate()`
  - I'm unclear what to expect as return value from `getLogType()`. What
 types exist? Do I get a class name, or what?
  - Maybe rename `getLogMillis()` to `getLogDateMillis()` to indicate that
 we're just returning the milliseconds of the date at 00:00:00 UTC, not the
 milliseconds of whatever time of the day the log was produced.
  - Please avoid abbreviations like "msec" and instead write "milliseconds
 since the epoch", for consistency.
  - The JavaDoc for `getRawDescriptorBytes()` should not copy the known
 compression types, but refer to `getCompressionType()` for the list. Right
 now, there's already an inconsistency between the list regarding `bz2`.
  - Are uncompressed logs supported? The documentation for
 `getRawDescriptorBytes()` doesn't indicate that, nor does
 `getCompressionType()` say what it would return in that case.
  - Shouldn't `getRawDescriptorBytes()` return the uncompressed bytes and a
 separate method `getCompressedBytes()` return the compressed bytes?
 Thinking of being consistent with other descriptors where
 `getRawDescriptorBytes()` returns uncompressed bytes, too. Not sure about
 this one.
  - "added in future" -> "added in the future"
  - We briefly discussed above to include the first, say, 100 unrecognized
 lines in `getUnrecognizedLines()`, but the documentation says it doesn't
 reply any. Why? Because it's not implemented yet?
  - As explained above, let's take out the `Sanitizer` subinterface and
 related methods.

 I'd like to wait for your response and a revised branch before doing
 another review of the remaining code. I'm not around most of Saturday but
 can take a look after that. Or on Monday, if you'd rather enjoy your
 weekend. :) 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] #23010 [Core Tor/Tor]: prop224: make sure the protocol handshakes are extensible

[Tor Bug Tracker & Wiki]

#23010: prop224: make sure the protocol handshakes are extensible
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by isis):

 * cc: isis (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] #22885 [Core Tor/Tor]: When uploading the first descriptor of a session, call it dirty because "Tor just started"

[Tor Bug Tracker & Wiki]

#22885: When uploading the first descriptor of a session, call it dirty because
"Tor just started"
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-21  |  Actual Points:
Parent ID:   | Points:  0
 Reviewer:  isis |Sponsor:
-+
Changes (by isis):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

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

Re: [tor-bugs] #23058 [Applications/Tor Browser Sandbox]: Sandbox Tor Browser no longer starting (100% CPU load)

[Tor Bug Tracker & Wiki]

#23058: Sandbox Tor Browser no longer starting (100% CPU load)
--+-
 Reporter:  pege  |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by yawning):

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


Comment:

 https://gitweb.torproject.org/tor-browser/sandboxed-tor-
 browser.git/commit/?id=2262bf1843129feddb7a913b15ef6298be71f4c1

 Surely the next alpha build will have a SelfRando that doesn't do
 something totally idiotic.

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

Re: [tor-bugs] #23058 [Applications/Tor Browser Sandbox]: Sandbox Tor Browser no longer starting (100% CPU load)

[Tor Bug Tracker & Wiki]

#23058: Sandbox Tor Browser no longer starting (100% CPU load)
--+--
 Reporter:  pege  |  Owner:  yawning
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by yawning):

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


Comment:

 Oh.  The browser developers didn't pull in the version of selfrando where
 they figured out how calling conventions worked, even though they told me
 they will, so I only applied the workaround for 7.5a2 and lower.

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

Re: [tor-bugs] #23058 [Applications/Tor Browser Sandbox]: Sandbox Tor Browser no longer starting (100% CPU load)

[Tor Bug Tracker & Wiki]

#23058: Sandbox Tor Browser no longer starting (100% CPU load)
--+---
 Reporter:  pege  |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by yawning):

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


Comment:

 Duplicate of #22853

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23058 [Applications/Tor Browser Sandbox]: Sandbox Tor Browser no longer starting (100% CPU load)

[Tor Bug Tracker & Wiki]

#23058: Sandbox Tor Browser no longer starting (100% CPU load)
--+-
 Reporter:  pege  |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Sandbox Tor Browser no longer working after update to Tor Browser 7.5a3.
 (Also happens with a fresh install.)

 tor-browser-sandboxed shows that everything is ok:

 {{{
 ...
 2017/07/28 19:33:11 sandbox: bwrap pid is: 298684
 2017/07/28 19:33:11 sandbox: bwrap init pid is: 298685
 2017/07/28 19:33:11 launch: Complete.
 2017/07/28 19:33:11 update: Previous scheduled update check: 2017-07-28
 21:15:25 +0200 CEST
 2017/07/28 19:33:11 update: Initial scheduled update check:
 1h42m13.489734672s
 }}}

 But the firefox process uses 100% CPU and appears to be stuck in an
 endless loop:

 {{{
 $ strace -p 298688
 read(-2, 0x7ffcbab09010, 32)= -1 EBADF (Bad file descriptor)
 read(-2, 0x7ffcbab09010, 32)= -1 EBADF (Bad file descriptor)
 ...
 read(-2, 0x7ffcbab09010, 32)= -1 EBADF (Bad file descriptor)
 read(-2, 0x7ffcbab09010, 32)= -1 EBADF (Bad file descriptor)
 }}}

 {{{
 $ sandboxed-tor-browser -version
 sandboxed-tor-browser 0.0.12-dev (26c9478)
 }}}

 {{{
 $ lsb_release -a
 No LSB modules are available.
 Distributor ID: Debian
 Description:Debian GNU/Linux 9.1 (stretch)
 Release:9.1
 Codename:   stretch
 }}}

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

Re: [tor-bugs] #22369 [Metrics/Censorship analysis]: Increase of users in Ukraine due to block of Russia-based services

[Tor Bug Tracker & Wiki]

#22369: Increase of users in Ukraine due to block of Russia-based services
-+--
 Reporter:  dcf  |  Owner:  metrics-team
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ua  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:12 arma]:
 > I posted to tor-talk a speculation about whether this growth in .ua
 users is influencing Google's internal geoip guesses:
 > https://lists.torproject.org/pipermail/tor-talk/2017-June/043269.html

 #23052 has a cypherpunks confused about seeing "YouTube UA" frequently.

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

Re: [tor-bugs] #23052 [Applications/Tor Browser]: I get Ukrainian IPs most of the time

[Tor Bug Tracker & Wiki]

#23052: I get Ukrainian IPs most of the time
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 This phenomenon is possibly Google's geolocation being confused by the
 many Ukrainians that started using Tor recently. The IP addresses are not
 actually in Ukraine. Please see:

 [https://lists.torproject.org/pipermail/tor-talk/2017-June/043269.html Is
 the recent growth in Ukrainian users confusing google's geoip?]
 > Motivated by a blog post comment:
 > https://blog.torproject.org/comment/269237#comment-269237
 >
 > It looks like a growing number of connections from Tor exits are being
 > treated by Google as being Ukrainian.
 >
 > Anecdotally, I've experienced it too -- Google news keeps wanting to
 > give me Ukrainian news.
 >
 > For those who haven't been paying attention, we got a jump in some
 > hundreds of thousands of .ua users recently:
 > https://metrics.torproject.org/userstats-relay-
 country.html?start=2017-05-01=2017-06-18=ua=off
 > and it looks like they're really users:
 > https://bugs.torproject.org/22369
 >
 > Here's my speculation:
 >
 > You know how Google's proprietary geoip system is typically better
 > than Maxmind's, because they data mine the heck out of their traffic,
 > for example by deciding that the google maps address you ask about most
 > is probably your home address?
 >
 > I wonder if a lot of ordinary people doing ordinary things via Tor,
 > and acting like people in the Ukraine, has tipped Google's sekrit-sauce
 > machine learning decision trees into labeling those IP addresses as
 > being in .ua.

 There are some other ideas later in the thread.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  TorBrowserTeam201707R =>


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

Re: [tor-bugs] #22067 [Applications/Tor Browser]: NoScript Click-to-Play bypass with embedded videos and audios

[Tor Bug Tracker & Wiki]

#22067: NoScript Click-to-Play bypass with embedded videos and audios
-+-
 Reporter:  samantharis  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-security, noscript,  |  Actual Points:
  TorBrowserTeam201707R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:9 ma1]:
 > Please check 5.0.7rc2 from https://noscript.net/getit#devel, thank you.
 If no major regression is found, I plan to release 5.0.7 stable by Sunday.

 Looks good to me, fwiw. I bumped the NoScript versions we ship on `master`
 and `maint-7.0` (commit 0437834017c1c7ff168da868d9dcb2f2519fd122 and
 12565f000a09b27b7dbd9ea864c5004b6d8324a9)

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

Re: [tor-bugs] #23051 [Applications/Orbot]: Orfox is dead. Insecure. Switch to Mozilla Firefox Android.

[Tor Bug Tracker & Wiki]

#23051: Orfox is dead. Insecure. Switch to Mozilla Firefox Android.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by cypherpunks):

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


Comment:

 Duplicate https://trac.torproject.org/projects/tor/ticket/5709

 gk said in the comments that this is planned for this year

 In the meantime https://lists.torproject.org/pipermail/tor-
 talk/2017-July/043356.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

[tor-bugs] #23057 [Core Tor/Stem]: Sockstat connection resolution unreliable

[Tor Bug Tracker & Wiki]

#23057: Sockstat connection resolution unreliable
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Minor  |   Keywords:  utils
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Recently our Jenkins, which run Stem's tests, hosts upgraded their Debian
 distribution. Doing so caused our test_connections_by_sockstat to start
 failing...

 {{{
 ==
 FAIL: test_connections_by_sockstat
 --
 Traceback (most recent call last):
   File "/srv/jenkins-workspace/workspace/stem-tor-
 ci/test/integ/util/connection.py", line 55, in
 test_connections_by_sockstat
 self.check_resolver(Resolver.SOCKSTAT)
   File "/srv/jenkins-workspace/workspace/stem-tor-ci/test/require.py",
 line 58, in wrapped
 return func(self, *args, **kwargs)
   File "/srv/jenkins-workspace/workspace/stem-tor-
 ci/test/integ/util/connection.py", line 37, in check_resolver
 self.fail('Unable to find our controller connection with %s (%s).
 Connections found were...\n\n%s\n\nCommand output was...\n\n%s' %
 (resolver, resolver_command, '\n'.join(map(str, connections)),
 resolver_output))
 AssertionError: Unable to find our controller connection with sockstat
 (sockstat). Connections found were...

 Connection(local_address=u'127.0.0.1', local_port=1024,
 remote_address=u'127.0.0.1', remote_port=38974, protocol=u'tcp',
 is_ipv6=False)
 Connection(local_address=u'127.0.0.1', local_port=1024,
 remote_address=u'127.0.0.1', remote_port=38966, protocol=u'tcp',
 is_ipv6=False)

 Command output was...

 [u'USER PROCESS  PID  PROTO  SOURCE ADDRESS
 FOREIGN ADDRESS   STATE', u'jenkins  tor  4759
 tcp4   127.0.0.1:1024*:*   LISTEN',
 u'jenkins  tor  4759 tcp4   127.0.0.1:1024
 *:*   LISTEN', u'jenkins  tor  4759
 tcp4   127.0.0.1:1024127.0.0.1:38974   ESTABLISHED',
 u'jenkins  tor  4759 tcp4   127.0.0.1:1024
 127.0.0.1:38966   ESTABLISHED', u'jenkins  sockstat
 4930 tcp4   127.0.0.1:38912   127.0.0.1:
 ESTABLISHED', u'jenkins  sockstat 4930 tcp4
 127.0.0.1:38912   127.0.0.1:ESTABLISHED',
 u'jenkins  python   18063tcp4   127.0.0.1:38912
 127.0.0.1:ESTABLISHED', u'jenkins  python
 18063tcp4   127.0.0.1:38912   127.0.0.1:
 ESTABLISHED']
 }}}

 Here's the sockstat output...

 {{{
 USER PROCESS  PID  PROTO  SOURCE ADDRESS
 FOREIGN ADDRESS   STATE
 jenkins  python   18337tcp4   127.0.0.1:41728
 127.0.0.1:ESTABLISHED
 jenkins  python   18337tcp4   127.0.0.1:41728
 127.0.0.1:ESTABLISHED
 jenkins  tor  20588tcp4   127.0.0.1:1024
 *:*   LISTEN
 jenkins  tor  20588tcp4   127.0.0.1:1024
 *:*   LISTEN
 jenkins  tor  20588tcp4   127.0.0.1:1024
 127.0.0.1:41814   ESTABLISHED
 jenkins  tor  20588tcp4   127.0.0.1:1024
 127.0.0.1:41806   ESTABLISHED
 jenkins  sockstat 20594tcp4   127.0.0.1:41728
 127.0.0.1:ESTABLISHED
 jenkins  sockstat 20594tcp4   127.0.0.1:41728
 127.0.0.1:ESTABLISHED
 }}}

 Note that our socksport (1024) is listed twice, but our controlport ()
 isn't among the tor process entries at all. However, we're showing
 connections *to* the controlport.

 Did some searching around but stumped. If we can fix sockstat to once
 again work on the jenkins hosts I'm all ears - otherwise we'll drop this
 connection resolution method in Stem 2.0.0.

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

Re: [tor-bugs] #23056 [Core Tor/Tor]: prop224: Intro point aren't transfered between services on HUP

[Tor Bug Tracker & Wiki]

#23056: prop224: Intro point aren't transfered between services on HUP
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 Fix is not very complicated.

 See branch: `ticket23056_032_01`

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

[tor-bugs] #23056 [Core Tor/Tor]: prop224: Intro point aren't transfered between services on HUP

[Tor Bug Tracker & Wiki]

#23056: prop224: Intro point aren't transfered between services on HUP
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop224, tor-hs
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 For the current prop224 upstream code, the `move_intro_points()` function
 doesn't work as expected, actually it's very broken.

 First of all, it is impossible to move intro points with the current
 condition because the newly created service (`dst`) doesn't have any
 descriptor. Thus, this if() is basically dead code and we never move intro
 points.

 {{{
 if (src->desc_current && dst->desc_current) {
   move_descriptor_intro_points(src->desc_current, dst->desc_current);
 ...
 }}}

 The fix is to move the *descriptor(s)* and not only the intro points
 because the service needs the descriptor signing key that cross certify
 every IP authentication key. So, we really need to move the full thing
 from one service to the other else we would have to re-sign everything.

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

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

[Tor Bug Tracker & Wiki]

#23041: Add new press clips to website
--+-
 Reporter:  steph |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by steph):

 Replying to [comment:2 hiro]:
 > I do not understand the date format. Could you please clarify it?
 Fixed.

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

Re: [tor-bugs] #23055 [Core Tor/Tor]: Y2106 bug in certificate expiration parsing.

[Tor Bug Tracker & Wiki]

#23055: Y2106 bug in certificate expiration parsing.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => closed
 * resolution:   => fixed
 * severity:  Normal => Trivial


Comment:

 Fixed as 769a94d9ce570b9418ab8705dc95c99f9b8c2251.

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

Re: [tor-bugs] #23055 [Core Tor/Tor]: Y2106 bug in certificate expiration parsing. (was: Y2038 bug in certificate expiration parsing.)

[Tor Bug Tracker & Wiki]

#23055: Y2106 bug in certificate expiration parsing.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #23055 [Core Tor/Tor]: Y2038 bug in certificate expiration parsing.

[Tor Bug Tracker & Wiki]

#23055: Y2038 bug in certificate expiration parsing.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23055 [Core Tor/Tor]: Y2038 bug in certificate expiration parsing.

[Tor Bug Tracker & Wiki]

#23055: Y2038 bug in certificate expiration parsing.
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In this code:
 {{{
   const uint32_t expiration_date = rsa_ed_crosscert_get_expiration(cc);
   const uint64_t expiration_time = expiration_date * 3600;
 }}}

 Coverity caught this as CID 1415728.

 No backport, since all current Tor releases will be obsolete by the time
 anyone hits this bug.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23054 [Core Tor/Tor]: BUG() macros shouldn't be warned as dead-code under coverity.

[Tor Bug Tracker & Wiki]

#23054: BUG() macros shouldn't be warned as dead-code under coverity.
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It's fine for our BUG() checks to be dead code: they're functionally
 equivalent to nonfatal assertions.  Leaving them in is good defensive
 programming, since they prevent us from introducing bugs 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] #23054 [Core Tor/Tor]: BUG() macros shouldn't be warned as dead-code under coverity.

[Tor Bug Tracker & Wiki]

#23054: BUG() macros shouldn't be warned as dead-code under coverity.
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Fixed in 602c52cad486516defc9d5ed375effd74cfe4529

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

Re: [tor-bugs] #23053 [Core Tor/Tor]: Memory leak of unix_socket_path when validating multiple unix sockets

[Tor Bug Tracker & Wiki]

#23053: Memory leak of unix_socket_path when validating multiple unix sockets
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


Comment:

 Made a branch `bug23053_029`; applied it to 0.3.1 and forward. Possible
 backport as far as 0.2.9, but it's not a very bad leak.

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

Re: [tor-bugs] #23053 [Core Tor/Tor]: Memory leak of unix_socket_path when validating multiple unix sockets

[Tor Bug Tracker & Wiki]

#23053: Memory leak of unix_socket_path when validating multiple unix sockets
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  029-backport coverity 030-backport   |  Actual Points:
  memory-leak|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => 029-backport coverity 030-backport memory-leak


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

Re: [tor-bugs] #23053 [Core Tor/Tor]: Memory leak of unix_socket_path when validating multiple unix sockets

[Tor Bug Tracker & Wiki]

#23053: Memory leak of unix_socket_path when validating multiple unix sockets
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23053 [Core Tor/Tor]: Memory leak of unix_socket_path when validating multiple unix sockets

[Tor Bug Tracker & Wiki]

#23053: Memory leak of unix_socket_path when validating multiple unix sockets
--+
 Reporter:  nickm |  Owner:
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This is CID 1415725

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

Re: [tor-bugs] #23049 [Applications/Tor Browser]: Tor Fails to open

[Tor Bug Tracker & Wiki]

#23049: Tor Fails to open
--+---
 Reporter:  jmaldonado12  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Could you follow comment:3:ticket:20890 (the place for the latest expert
 bundle is https://dist.torproject.org/torbrowser/7.0.2/tor-
 win32-0.3.0.9.zip with https://dist.torproject.org/torbrowser/7.0.2/tor-
 win32-0.3.0.9.zip.asc) and give us the debug log you get when starting Tor
 Browser with the expert bundle `tor.exe`?

 If you have questions just ask, I know it's not the most simple kind of
 debugging (we are working on making it easier).

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

Re: [tor-bugs] #23052 [Applications/Tor Browser]: I get Ukrainian IPs most of the time

[Tor Bug Tracker & Wiki]

#23052: I get Ukrainian IPs most of the time
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I meant

 *I try "New Tor Circuit for this Site" dozens of times

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23052 [Applications/Tor Browser]: I get Ukrainian IPs most of the time

[Tor Bug Tracker & Wiki]

#23052: I get Ukrainian IPs most of the time
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 For at least a few weeks I realized there is the text "UA" next to the
 Youtube logo most of the times. I would really like to know why it would
 happen

 I can't speak for other websites since the circuit viewer never showed up
 on my PC for years, I don't know why

 I could say at least half of the times I get the Ukrainian IP(s) on
 Youtube, it's crazy. Like I try dozens of times to see which countries
 would show up and yes, still UA most of the times

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

Re: [tor-bugs] #21657 [Applications/Tor Browser]: Test to make sure we isolate or disable all speculative connects

[Tor Bug Tracker & Wiki]

#21657: Test to make sure we isolate or disable all speculative connects
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  TorBrowserTeam201707   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:7 arthuredelstein]:
 > Turns out:
 > * Firefox doesn't yet support `link rel=prerender` (according to
 https://bugzilla.mozilla.org/show_bug.cgi?id=730101)

 And they won't. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1383876.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23051 [Applications/Orbot]: Orfox is dead. Insecure. Switch to Mozilla Firefox Android.

[Tor Bug Tracker & Wiki]

#23051: Orfox is dead. Insecure. Switch to Mozilla Firefox Android.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+---
 Mozilla/5.0 (Android; Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

 1. Too old.
 2. Can identifiable via screen width and height.
 3. 5 vulns.

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

Re: [tor-bugs] #23050 [Applications/Tor Browser]: Tab keeps crashing on Win 8.1 with Tor Browser 7 (in e10s mode)

[Tor Bug Tracker & Wiki]

#23050: Tab keeps crashing on Win 8.1 with Tor Browser 7 (in e10s mode)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-7.0-issues, tbb-e10s  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I should have asked whether the problem shows up in a vanilla Firefox 52
 ESR.

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

Re: [tor-bugs] #13410 [Applications/Tor Browser]: Disable self-signed certificate warnings when visiting .onion sites

[Tor Bug Tracker & Wiki]

#13410: Disable self-signed certificate warnings when visiting .onion sites
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  #ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Tor Browser
 Orfox

 Come on people. Just ignore HTTPS warning already.

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

Re: [tor-bugs] #22935 [Applications/Orbot]: Disable SSL alert when visiting .onion HTTPS.

[Tor Bug Tracker & Wiki]

#22935: Disable SSL alert when visiting .onion HTTPS.
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  needs_information
 Priority:  Immediate   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by cypherpunks):

 Nor Orbot but "Orfox".

 Orbot and Orfox didn't update for too long. Are they dead or what?

 And also, why #13410 is not implemented yet? HTTPS warning on .onion is so
 annoying!

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

Re: [tor-bugs] #23050 [Applications/Tor Browser]: Tab keeps crashing on Win 8.1 with Tor Browser 7

[Tor Bug Tracker & Wiki]

#23050: Tab keeps crashing on Win 8.1 with Tor Browser 7
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-7.0-issues, tbb-e10s  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-7.0-issue, tbb-e10s => tbb-7.0-issues, tbb-e10s


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

Re: [tor-bugs] #23050 [Applications/Tor Browser]: Tab keeps crashing on Win 8.1 with Tor Browser 7 (in e10s mode) (was: Tab keeps crashing on Win 8.1 with Tor Browser 7)

[Tor Bug Tracker & Wiki]

#23050: Tab keeps crashing on Win 8.1 with Tor Browser 7 (in e10s mode)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-7.0-issues, tbb-e10s  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

[tor-bugs] #23050 [Applications/Tor Browser]: Tab keeps crashing on Win 8.1 with Tor Browser 7

[Tor Bug Tracker & Wiki]

#23050: Tab keeps crashing on Win 8.1 with Tor Browser 7
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:  tbb-7.0-issue,
  |  tbb-e10s
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Today on #tor we had a user reporting tabs crashing repeatedly after
 start-up up to the point that Tor Browser is basically unusable. After
 trying different things we ended up disabling e10s mode (by setting
 `browser.tabs.remote.autostart.2` to `false`). That solved the problem.

 Not sure how we can debug this further. :( The error console did not show
 a hint about what is going 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] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:10 karsten]:
 > I need more time for this review. But here's a first question:
 >
 > Should we really put the sanitizing code into metrics-lib rather than
 CollecTor? That's an important design decision and a change to what we
 have been doing in the past. Where would this code be used other than in
 CollecTor? So far, metrics-lib has primarily been the client-side library
 for applications using CollecTor data. But this change would turn it into
 a library that both the CollecTor server and its clients depend on. I'm
 yet undecided whether this is a good idea or not. In any case, we should
 discuss this first.

 The sanitizing code **is not** part of metrics-lib.  Thus, we agree here.
 In the proposed patch metrics-lib enables adding sanitizing code from the
 'outside' using method
 {{{
 public void setSanitizer(LogDescriptor.Sanitizer sani);
 }}}
 and `Sanitizer` is just a functional interface (i.e., having one method)
 that can be fulfilled by a lambda expression once we go to Java8, but
 that's an aside.

 The given `Sanitizer` is applied when `sanitize()` is called.  The
 resulting lines are sorted by metrics-lib.

 A choice I made is to have a default identity sanitizer in case none was
 set instead of raising an exception.

 With this approach metrics-lib is sanitizer-code-agnostic, but provides
 all else (compression, de-compression, etc.), which avoids duplicating
 code and enables us to implement performance and space saving code 'under
 the hood' once it is needed.  Hope this explains my reasoning.

 CollecTor depends on metrics-lib already as it uses `Descriptor`s of all
 kinds as well as parser and reader from metrics-lib.

 (I noticed that I missed adding a comment to
 `LogDescriptor.setSantizer()`.  I'll add a fixup commit, but that
 shouldn't hinder 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] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 I need more time for this review. But here's a first question:

 Should we really put the sanitizing code into metrics-lib rather than
 CollecTor? That's an important design decision and a change to what we
 have been doing in the past. Where would this code be used other than in
 CollecTor? So far, metrics-lib has primarily been the client-side library
 for applications using CollecTor data. But this change would turn it into
 a library that both the CollecTor server and its clients depend on. I'm
 yet undecided whether this is a good idea or not. In any case, we should
 discuss this first.

 I'll continue my review later today and post my findings 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] #22912 [Metrics/metrics-lib]: tpf parsing drops trailing newline

[Tor Bug Tracker & Wiki]

#22912: tpf parsing drops trailing newline
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Merged with a tiny one-line tweak to the test data. 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