Re: [tor-bugs] #20207 [Applications/Tor Messenger]: IB and Tor Messenger seem to still be sharing a notification key on macOS

[Tor Bug Tracker & Wiki]

#20207: IB and Tor Messenger seem to still be sharing a notification key on 
macOS
+
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Fixed in https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=7a2c858e080c1862641c42d3a0df4f7eea6bddf9

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

Re: [tor-bugs] #20338 [Applications/Tor Messenger]: Prevent notification sharing in macOS between IB and TM

[Tor Bug Tracker & Wiki]

#20338: Prevent notification sharing in macOS between IB and TM
+
 Reporter:  huyvq   |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  #20207  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 Thanks!

 Landed as https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=7a2c858e080c1862641c42d3a0df4f7eea6bddf9

 ps. huyvq, you could have just added an attachment on #20207, rather than
 opening a new ticket.  (But note that adding attachments doesn't send out
 notifications, so follow it up with an "I added a patch for this ...", or
 something.

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

Re: [tor-bugs] #20071 [Core Tor/Tor]: Tor clients need 4 routers when connecting via IPv6, but only 3 using IPv4

[Tor Bug Tracker & Wiki]

#20071: Tor clients need 4 routers when connecting via IPv6, but only 3 using 
IPv4
---+-
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  testing, ipv6  |  Actual Points:
Parent ID:  #19989 | Points:  2
 Reviewer: |Sponsor:
---+-

Comment (by arma):

 (If you can get me a stack trace for when this log complaint happens, I
 can try to guess whether it's being called in a reasonable 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] #20071 [Core Tor/Tor]: Tor clients need 4 routers when connecting via IPv6, but only 3 using IPv4

[Tor Bug Tracker & Wiki]

#20071: Tor clients need 4 routers when connecting via IPv6, but only 3 using 
IPv4
---+-
 Reporter:  teor   |  Owner:
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  testing, ipv6  |  Actual Points:
Parent ID:  #19989 | Points:  2
 Reviewer: |Sponsor:
---+-

Comment (by arma):

 That log message comes from
 {{{
   if (num_acceptable_routers < routelen) {
 log_info(LD_CIRC,
  "Not enough acceptable routers (%d/%d). Discarding this
 circuit.",
  num_acceptable_routers, routelen);
 return -1;
   }
 }}}
 so it would seem that routelen is 4 for this case (rather than "one of the
 routers is unacceptable").

 routelen gets set here:
 {{{
   routelen = DEFAULT_ROUTE_LEN;
   if (exit_ei &&
   purpose != CIRCUIT_PURPOSE_TESTING &&
   purpose != CIRCUIT_PURPOSE_S_ESTABLISH_INTRO)
 routelen++;
 }}}

 So: are you causing this ipv6 circuit to be called in such a way that
 you're specifying which exit it should use, and it's not a testing or
 server-side-establish-intro circuit?

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

Re: [tor-bugs] #20338 [Applications/Tor Messenger]: Prevent notification sharing in macOS between IB and TM

[Tor Bug Tracker & Wiki]

#20338: Prevent notification sharing in macOS between IB and TM
+--
 Reporter:  huyvq   |  Owner:
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #20207  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arma):

 * 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] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

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

 * keywords:  refactor => refactor, 030-proposed, TorCoreTeam201610
 * reviewer:   => teor
 * status:  new => needs_revision


Comment:

 Hi, thanks for this patch!

 In general, it looks great, and I would really like to get rid of
 is_sensitive_dir_purpose. But I think we need to keep router_purpose in
 purpose_needs_anonymity.
 Otherwise, we change the logic from:
 * if you're a bridge, do everything anonymously,
 * otherwise, do some things non-anonymously,
 * otherwise, do everything else anonymously,
 to:
 * regardless of whether you're a bridge or not,
   * do some things non-anonymously,
   * otherwise, do everything else anonymously,

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20338 [Applications/Tor Messenger]: Prevent notification sharing in macOS between IB and TM

[Tor Bug Tracker & Wiki]

#20338: Prevent notification sharing in macOS between IB and TM
+
 Reporter:  huyvq   |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:  #20207
   Points:  |   Reviewer:
  Sponsor:  |
+
 Change the value of `CFBundleIdentifier` to `org.mozilla.tor messenger`.

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

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

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  refactor  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by chelseakomlo):

 See changes here:
 
https://github.com/chelseakomlo/tor_patches/commit/c6d0255eebdafe7b635c6c762c8c16a5a45b5a2f

 In doing this ticket, I found that:
 1. The parameter router_purpose for purpose_needs_anonymity did not change
 the logic flow. In every case, unless the dir_purpose matched specific
 cases, the function would return true.

 2. The cases in is_sensitive_dir_purpose are compatible with
 purpose_needs_anonymity, so these two functions could easily be merged.The
 logic is in purpose_needs_anonymity is inverted- purpose_needs_anonymity
 returns true by default, unless in the specified cases, whereas
 is_sensitive_dir_purpose returned false unless certain cases were met.

 3. I struggled to write a clean/simple comment for purpose_needs_anonymity
 is accurate, please review!

 4. I wrote the unit tests to have names which describe their intended
 behavior. In each test, it states the expected behavior, under the given
 condition. However, because of column length, the wording for the test
 names is abbreviated, please let me know if the naming is confusing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20337 [Core Tor]: Support abstract namespace AF_UNIX sockets.

[Tor Bug Tracker & Wiki]

#20337: Support abstract namespace AF_UNIX sockets.
-+--
 Reporter:  yawning  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor |Version:  Tor: unspecified
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Linux has a notion of `abstract` AF_UNIX sockets.  This should be
 supported both for the control and socks port, as they are convenient and
 useful, as long as they are used correctly.

 Benefits:
  * Easier to bundle.  `sun_path` length limitations are dumb, being able
 to use an abstract identifier is simpler.
  * No need to mess around with creating a directory, arguing over what
 permissions the directory and the socket file has.
  * The socket goes away when the last reference to the socekt is closed,
 removing the need to unlink it.

 Downsides:
  * There is no access control, at all.  Primarily relevant for the
 ControlPort, but that has separate mechanisms for restricting access.
  * Not wildly useful for sandboxes, since most sandboxing approaches will
 unshare/create a new IPC namespace.
  * Non-portable.

 (0.2.0.3-alpha was the first time we supported AF_UNIX at all)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_review
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor   |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  tbb-needs  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by yawning):

 * status:  assigned => needs_review


Comment:

 This is ugly because we never bothered to treat AF_UNIX as a full class
 citizen.  In particular `tor_addr_t` doesn't contain the path at all, so
 when we go to compare them, there isn't any information regarding the
 address beyond the family.

 The correct solution is probably to extend tor_addr_t to Do The Right
 Thing, but this branch should cover Tor Browser's use cases.  The first
 commit is probably safe to take since it's the `IsolateClientAddr` change,
 the second may be more controversial.

 https://git.schwanenlied.me/yawning/tor/src/bug20261

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arlolra):

 Tor Messenger is reverting this patch (#3875) in
 https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=cd2bb57632ac4278da6d70fe3339bb64b38d29eb since it
 seems to be breaking STARTTLS in XMPP.

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

Re: [tor-bugs] #16536 [Applications/Tor Messenger]: Investigate Tor Browser patches relevant to Tor Messenger

[Tor Bug Tracker & Wiki]

#16536: Investigate Tor Browser patches relevant to Tor Messenger
+
 Reporter:  sukhbir |  Owner:
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by arlolra):

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


Comment:

 https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=8189975133f23ce8772117182641cb599ae8

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

Re: [tor-bugs] #20210 [Applications/Tor Browser]: Update from 6.5a2 to 6.5a3 on OSX breaks Tor Browser

[Tor Bug Tracker & Wiki]

#20210: Update from 6.5a2 to 6.5a3 on OSX breaks Tor Browser
--+--
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (added)


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

[tor-bugs] #20336 [Applications/Tor Browser]: dmg background not showing on macOS Sierra

[Tor Bug Tracker & Wiki]

#20336: dmg background not showing on macOS Sierra
--+--
 Reporter:  arlolra   |  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:|
--+--
 Affects Tor Messenger as well.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Somewhat related to the `sha1Hex()` example, depending on the descriptor
 we might need more than just one method for returning a descriptor digest:
 sha-1, sha-256, etc.  Of course, we could pick one name per digest
 algorithm.  But maybe we'll also need different encodings, hex vs. base64.
 This can get messy.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [ticket:20333 iwakeh]:
 > There is currently not vote descriptor digest (so CollecTor calculates
 it on its own).  Most other descriptor types provide a digest.

 Oh, that sounds like an oversight then.  Nobody needed that yet, so it has
 not been implemented.  Let's implement it!

 > In addition, it might be nice to provide a `getDigest` method for the
 different descriptor digests instead of `XyzDescriptor.getXyzDigest`.

 What do you suggest?  Just rename the method and deprecate the old one?
 Is that worth the possible trouble for developers who need to adapt method
 names?  (I just remember how I had to change `shaHex()` to `sha1Hex()` the
 other day and found that change rather annoying.)  And having two methods
 that do the exact same thing seems rather confusing, too.

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

Re: [tor-bugs] #20334 [Metrics/metrics-lib]: explicitly log, which implementation is served by DescriptorSourceFactory

[Tor Bug Tracker & Wiki]

#20334: explicitly log, which implementation is served by 
DescriptorSourceFactory
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Sure, why not.  Want to write a patch?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [comment:1 iwakeh]:
 > In addition, the reported statistics are somewhat doubtful, but I didn't
 explicitly verify.

 Can you elaborate?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [ticket:20335 iwakeh]:
 > In general, statistics and analysis should be separated from normal
 functioning.

 Separated how?  We need to run these checks every hour to learn early if
 we're missing more descriptors than usual.

 > After a sync-run ReferenceChecker hogs CPU and memory.  It might need to
 be disabled for the first sync-release.

 Do you have an idea why it would do that after a sync run and not after a
 usual download run?  I'd rather not want to disable the checker in a
 release and instead fix it.  I can try to take a look if you give me
 something to reproduce the issue.

 > The implementation should be redesigned.

 How?  Maybe we can get away by fixing it for the moment.

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
+--
 Reporter:  special |  Owner:  nickm
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs  |  Actual Points:  1
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

[Tor Bug Tracker & Wiki]

#18753: Unix socket paths cannot contain spaces
-+-
 Reporter:  special  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs,  |  Actual Points:  1
  review-group-10|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  nickm-deferred-20160905, tbb-needs => nickm-deferred-20160905,
 tbb-needs, review-group-10


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

Re: [tor-bugs] #20217 [Applications/Tor Browser]: Make sure that all .mar files required for generating incremental ones on OS X contain code-signed bits

[Tor Bug Tracker & Wiki]

#20217: Make sure that all .mar files required for generating incremental ones 
on
OS X contain code-signed bits
---+---
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201610R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by boklm):

 * keywords:  tbb-gitian, TorBrowserTeam201610 => tbb-gitian,
 TorBrowserTeam201610R
 * status:  new => needs_revision


Comment:

 The branch `bug_20217` in my git repo has a patch for this:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 bundle.git/commit/?h=bug_20217

 When generating the OSX incremental MARs from `make dmg2mars` or `make
 dmg2mars-alpha`, we are now checking that both the new and the old MAR
 files contain a file in
 `TorBrowser.app/Contents/_CodeSignature/CodeResources`.

 I checked that it fails with an error when the mar file from the old
 version is not code signed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.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,  |
  nickm-deferred-20161005, review-group-10   |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-
Changes (by pastly):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #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.3.0.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,  |
  nickm-deferred-20161005, review-group-10   |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by pastly):

 Updated branch (https://github.com/pastly/public-tor/tree/ticket14881-v2)
 with tests involving real data. Thanks arma.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by weasel):

 I have also created 3 databases, torcrm_{prod,staging,test}.  I'm unsure
 if the user really needs to be www-data or whether it could and should be
 something dedicated to this crm purpose.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arthuredelstein):

 Replying to [comment:7 gk]:
 > bug_20184_v2 (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20184_v2&id=8cb911a5516dd89e99a429d2c2f5912e3a6a326c)
 in my public tor-browser-bundle has a patch up for review. I tested it on
 different machines with several builds and I got always the same .zip
 file. Looking at the artifacts the differences mentioned in comment:1 2)
 are gone. However, we got a new one only in `libcurve25519_donna.a` which
 is probably a bug in the `ar` tool used. There are always two bytes
 different, e.g.:
 > {{{
 > @@ -5,7 +5,7 @@
 >  0040: 2020 600a 5f5f 2e53 594d 4445 4620 534f`.__.SYMDEF SO
 >  0050: 5254 4544   0800     RTED
 >  0060: 8000  1800  5f63 7572 7665 3235  _curve25
 > -0070: 3531 395f 646f 6e6e 6100 d900    519_donna...
 > +0070: 3531 395f 646f 6e6e 6100 6c01    519_donna.l.
 >  0080: 2331 2f36 3020 2020 2020 2020 2020 2020  #1/60
 >  0090: 3934 3636 3834 3830 3020 2020 3130 3030  946684800   1000
 >  00a0: 2020 3130 3030 2020 3130 3036 3434 20201000  100644
 > }}}
 > It does not affect us at the moment, though.
 >
 > For some reason `libfaketime` is needed again which is a bit surprising
 and might merit further investigation as we don't seem to need it in the
 gitian-firefox.yml descriptor.
 >
 > I've uploaded a test bundle as I only have an old OSX 10.6 machine
 available (where it worked):
 >
 > https://people.torproject.org/~gk/testbuilds/TorBrowser-6.5a3
 -osx64_20184_en-US.dmg
 > https://people.torproject.org/~gk/testbuilds/TorBrowser-6.5a3
 -osx64_20184_en-US.dmg.asc

 I ran this on a 10.11.5 OS X machine and it everything seems to be working
 as expected.

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

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

Re: [tor-bugs] #20210 [Applications/Tor Browser]: Update from 6.5a2 to 6.5a3 on OSX breaks Tor Browser

[Tor Bug Tracker & Wiki]

#20210: Update from 6.5a2 to 6.5a3 on OSX breaks Tor Browser
--+--
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 I have looked at why 7z doesn't set the correct permissions. It seems that
 it is because it doesn't read the RockRidge extensions on the iso image,
 containing the permissions (and the symlink infos). It looks like some
 support for this has been added to 7zip 16.04, but the latest p7zip
 version (the port of 7zip to Unix which we are using) is still based on
 7zip 16.02. I patched p7zip with the changes from 7zip adding support for
 the RockRidge extensions, but it still does not set the permissions
 correctly. I started debugging this but did not find yet what is
 happening.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, tbb-|  Actual Points:
  sandboxing, TorBrowserTeam201610R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 A few very minor comments:

 * "extensions.torlauncher.socks_port_use_socket" is a confusing name to
 me, because we are using a TCP socket when it is false. Maybe call it
 "socks_port_use_ipc", as this would also cover the named pipe scenario if
 we later get it working in Windows? Similar for the env var
 TOR_SOCKS_SOCKET.

 * `_strUnescape`: It would be nicer if this function simply returned the
 unescaped string, and threw an exception if it failed. (Although maybe you
 want to keep it this way to be consistent with the other copy in Tor
 launcher.)

 * `unescapeTorString`: I would suggest defining this after `_strUnescape`
 is defined in utils.js, because it refers to it.

 Otherwise looks good to me.

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

Re: [tor-bugs] #20315 [Applications/Tor Launcher]: Tor launcher doesn't respect ReachableAddresses

[Tor Bug Tracker & Wiki]

#20315: Tor launcher doesn't respect ReachableAddresses
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 It's difficult to go around this in Tails. Tails calls the Tor Launcher
 wizard code when the network card connects to the internet, or when the
 tor process restarts. For now I included explicit iptables (ferm) firewall
 rules to REJECT debian-tor process outgoing connections to those ports.

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

Re: [tor-bugs] #20207 [Applications/Tor Messenger]: IB and Tor Messenger seem to still be sharing a notification key on macOS

[Tor Bug Tracker & Wiki]

#20207: IB and Tor Messenger seem to still be sharing a notification key on 
macOS
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Tor Browser sets,

 {{{
 CFBundleIdentifier
 org.mozilla.tor browser
 }}}

 Let's do, `org.mozilla.tor messenger`

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

Re: [tor-bugs] #20330 [Applications/Tor Browser]: Tor browser no longer starts in OSX

[Tor Bug Tracker & Wiki]

#20330: Tor browser no longer starts in OSX
--+
 Reporter:  redacted  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mcs):

 Kathy and I looked at the 6.0.5 dmg files, incremental MAR files, and
 complete MAR files for two locales (en-US and es-ES). None of the files
 include the wrong Tor Launcher; that is, none of them include a Tor
 Launcher that has control port socket support.

 It seems like the alpha TB must have been opened at some point, although
 our users say otherwise. Strange.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by iwakeh):

 In addition, the reported statistics are somewhat doubtful, but I didn't
 explicitly verify.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20335 [Metrics/CollecTor]: ReferenceChecker causes OOM

[Tor Bug Tracker & Wiki]

#20335: ReferenceChecker causes OOM
---+-
 Reporter:  iwakeh |  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 In general, statistics and analysis should be separated from normal
 functioning.

 After a sync-run ReferenceChecker hogs CPU and memory.  It might need to
 be disabled for the first sync-release.

 The implementation should be redesigned.

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

Re: [tor-bugs] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201609, review-group-10 |
Parent ID:  #17241   | Points:  3
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * status:  assigned => 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] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201609, review-group-10 |
Parent ID:  #17241   | Points:  3
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by asn):

 * status:  needs_review => assigned
 * owner:   => asn


Comment:

 (Claiming ownership)

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

Re: [tor-bugs] #19223 [Core Tor/Tor]: Potential heap corruption in do_getpass in routerkeys.c

[Tor Bug Tracker & Wiki]

#19223: Potential heap corruption in do_getpass in routerkeys.c
-+-
 Reporter:  asn  |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, 028-backport,|  Actual Points:
  isaremoved, nickwants029, review-group-10  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Hello,

 I reviewed nherring's patch and it seems alright. I also tested it against
 Guido's PoC and ASAN does not crash anymore.

 BTW, since no branch was provided, I pushed nherring's patch on my repo as
 `bug19223` and also added a changes file. Please check it out.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20334 [Metrics/metrics-lib]: explicitly log, which implementation is served by DescriptorSourceFactory

[Tor Bug Tracker & Wiki]

#20334: explicitly log, which implementation is served by 
DescriptorSourceFactory
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 The implementation that is served should be logged upon creation on info
 level.

 This will facilitate troubleshooting in future.

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

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

[Tor Bug Tracker & Wiki]

#20333: add descriptor digest to vote and streamline method name
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+---
 There is currently not vote descriptor digest (so CollecTor calculates it
 on its own).  Most other descriptor types provide a digest.

 In addition, it might be nice to provide a `getDigest` method for the
 different descriptor digests instead of `XyzDescriptor.getXyzDigest`.

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

Re: [tor-bugs] #20328 [Applications/Tor Browser]: No cookies are visible, except...

[Tor Bug Tracker & Wiki]

#20328: No cookies are visible, except...
--+--
 Reporter:  bugzilla  |  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 mcs):

 Can you provide steps to reproduce this?

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

Re: [tor-bugs] #20309 [Applications/Tor Browser]: Make TorBrowser-Data directory name build configurable

[Tor Bug Tracker & Wiki]

#20309: Make TorBrowser-Data directory name build configurable
--+--
 Reporter:  arlolra   |  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 mcs):

 We would be happy to accept a patch for this, but I do not think Kathy and
 I will have time to work on this during October.

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

Re: [tor-bugs] #20315 [Applications/Tor Launcher]: Tor launcher doesn't respect ReachableAddresses

[Tor Bug Tracker & Wiki]

#20315: Tor launcher doesn't respect ReachableAddresses
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by mcs):

 Unfortunately, Tor Launcher does not support `reject` policies for
 ReachableAddresses. Also, the initial configuration wizard tries to set
 ReachableAddresses automatically, which means (as you discovered) values
 set in torrc will be lost.

 The only workaround for now is to avoid using Tor Launcher (both the
 wizard and the Network Settings window) when you need this kind of policy.

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

Re: [tor-bugs] #19200 [Applications/Tor Browser]: HTML5 video not blocked with placeholder, plays automatically

[Tor Bug Tracker & Wiki]

#19200: HTML5 video not blocked with placeholder, plays automatically
-+-
 Reporter:  potato   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security-slider, |  Actual Points:
  tbb-6.0-issues, GeorgKoppen201610, |
  TorBrowserTeam201610, noscript |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ma1):

 Replying to [comment:27 bugzilla]:
 > Replying to [comment:16 ma1]:
 > Do you think it's not about NoScript or it shouldn't be addressed in a
 timely fashion?

 I do think it needs to be addressed ASAP, and I did implement my "trust
 MSE videos on this page + reload" solution in NoScript 2.9.5 codebase
 (under development), which is significantly different from 2.9.0.x
 (current release) because it's refactored and split across processes as an
 interim e10s-compatible XUL version before switching to WebExtensions.

 Unfortunately putting this version in a releasable state is taking
 considerably longer than expected, but I hope to publish it in a couple of
 weeks at most, but should I miss this mark I'm gonna backport this fix
 into an ad-hoc 2.9.0.15 release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_information
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 Okay, I see what you mean.  However, I'd rather want to advoid adding such
 a `@valid-after` tag, because it smells like making things more
 complicated than they should have to be.

 Here's what we could do.  We already have a list of missing
 microdescriptors in place for the downloader.  And we already parse
 incoming microdescriptor consensuses to learn about microdescriptors we'll
 want to fetch.  What we could do is: 1) always sync microdescriptor
 consensuses before microdescriptors, so that we learn about missing
 microdescriptors and their valid-after times; 2) look at the same map for
 sorting incoming microdescriptors into months; 3) discard microdescriptors
 we receive via sync that we're not missing.

 1) and 2) seem doable, but let's briefly think about the impact of 3)
 there.

 First, it seems rather unlikely that we'll run into that case very often,
 because we'd also sync microdescriptor consensuses from the other
 instance, so we should know all microdescriptors they know.

 Second, the value of microdescriptors is limited for most of our use
 cases, and the main reason for collecting them was to facilitate debugging
 Tor protocols but not to analyze the Tor network which is better done with
 consensuses and server descriptors.

 Third and last, let's keep in mind that we're improving descriptor
 completeness a lot with this sync approach, even if we might still be
 missing half a dozen microdescriptors per year.

 I'd say let's take the best-effort approach with microdescriptors and call
 it a day. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20332 [Core Tor/Tor]: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS

[Tor Bug Tracker & Wiki]

#20332: Duplicate rendezvous cookie in ESTABLISH_RENDEZVOUS
--+
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:  ? |   Reviewer:
  Sponsor:  SponsorR-can  |
--+
 Seems like people have started receiving this `Duplicate rendezvous cookie
 in ESTABLISH_RENDEZVOUS` warning message on their relays:
 https://lists.torproject.org/pipermail/tor-relays/2016-October/010535.html

 This might be a logic bug in tor, or it might be that Tor clients (or an
 alt implementation) is reusing the same rend point and same rend cookie
 multiple times, which simply does not work.

 (Meta: Unclear what `Points` should be in this ticket)

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

Re: [tor-bugs] #18663 [Metrics/Onionoo]: Onionoo doesn't send certain headers on even-numbered responses

[Tor Bug Tracker & Wiki]

#18663: Onionoo doesn't send certain headers on even-numbered responses
-+-
 Reporter:  dcf  |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 I believe this issue was resolved a few months ago by switching from
 Apache to Varnish.  At least I cannot reproduce it anymore.
 Optimistically closing, please re-open if the issue still persists,
 ideally with instructions for reproducing it.  Thanks everyone!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_information
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iwakeh):

 Well, actually the "validAfter" from the referring microconsensus is
 passed on.  Thus, the new functionality would change something.

 In general, there should be a better solution for the micro-desc handling.
 Couldn't a @valid-after tag be prepended to the microdescs?

 Otherwise, the sync-mechanism will have to parse microcons in order to
 determine the appropriate date.

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

Re: [tor-bugs] #20301 [Applications/Tor Browser]: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds

[Tor Bug Tracker & Wiki]

#20301: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 The Wheezy compiler is too old for it (generally 4.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] #19481 [Applications/Tor Browser]: Change app.update.url to point to aus1.tpo

[Tor Bug Tracker & Wiki]

#19481: Change app.update.url to point to aus1.tpo
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201610R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:11 bugzilla]:
 > FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1151485
 > ESR52: https://bugzilla.mozilla.org/show_bug.cgi?id=1182352

 We already removed the updater-specific cert pinning. See #17442 and
 #18912.

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

Re: [tor-bugs] #20301 [Applications/Tor Browser]: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds

[Tor Bug Tracker & Wiki]

#20301: Bumping the compiler version to 6.2.0 breaks 64bit Tor Browser builds
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201610  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 This works fine with `hardening-wrapper` settings as we have them in
 Gitian on a Debian testing machine. Additionally, setting
 `DEB_BUILD_HARDENING_PIE=0` for the GCC step in our Gitian build would
 help as well.

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

Re: [tor-bugs] #20207 [Applications/Tor Messenger]: IB and Tor Messenger seem to still be sharing a notification key on macOS

[Tor Bug Tracker & Wiki]

#20207: IB and Tor Messenger seem to still be sharing a notification key on 
macOS
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by huyvq):

 > Probably just need to change the CFBundleIdentifier

 Yes, that's right. But what's the ID you want for the replacement?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20331 [Metrics/Metrics website]: Speed up Metrics graphs by up to 4 seconds

[Tor Bug Tracker & Wiki]

#20331: Speed up Metrics graphs by up to 4 seconds
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Some of the .csv files on Metrics have grown over time, with `clients.csv`
 being the largest with a current size of 25M.  Still, we're reading these
 files every time we're drawing a graph, which may be a graph with slightly
 different parameters like start or end date.  This idea was okay when
 files were small, but it's making updates to graphs slower that they have
 to be.  On my laptop with an SSD drive it takes 4 seconds to read that
 file to memory.  I'd guess that it takes a few seconds on the server, too,
 and that's waiting time for the user between hitting the "Update graph"
 button and receiving a new graph image back.  In other words, graphs could
 be even more interactive if we resolved this issue.

 I'm aware of this issue for a while now, but I somehow only thought of
 fixing this by putting .csv files into a database, which would require a
 bit of code.  Today I came up with a simpler idea: we could simply cache
 .csv file contents in memory.  All .csv files require 89M on disk, and
 even if they grow to double the current size that still seems plausible to
 keep in memory.

 I briefly looked into the `memoise` package that's also available in
 Debian stable (`r-cran-memoise`), but the version in Debian doesn't
 support the `timeout` parameter, and I'm also not sure whether that
 mechanism would clutter memory over time by not invalidating older copies.
 But assuming we can get that running, here's a minimal example with a
 recent version of that package which does support the timeout parameter
 (with `***` where `read.csv()` returns file contents from memory):

 {{{
 > require(memoise)
 Loading required package: memoise
 > read.csv <- memoise(utils::read.csv, ~timeout(10))
 >
 > while (TRUE) {
 +   print(paste(Sys.time(), " Reading clients.csv"))
 +   read.csv("clients.csv")
 +   print(paste(Sys.time(), " Sleeping for a second"))
 +   Sys.sleep(1)
 + }
 [1] "2016-10-10 11:18:11  Reading clients.csv"
 [1] "2016-10-10 11:18:15  Sleeping for a second"
 [1] "2016-10-10 11:18:16  Reading clients.csv" ***
 [1] "2016-10-10 11:18:16  Sleeping for a second"
 [1] "2016-10-10 11:18:17  Reading clients.csv" ***
 [1] "2016-10-10 11:18:17  Sleeping for a second"
 [1] "2016-10-10 11:18:18  Reading clients.csv" ***
 [1] "2016-10-10 11:18:18  Sleeping for a second"
 [1] "2016-10-10 11:18:19  Reading clients.csv" ***
 [1] "2016-10-10 11:18:19  Sleeping for a second"
 [1] "2016-10-10 11:18:20  Reading clients.csv"
 [1] "2016-10-10 11:18:24  Sleeping for a second"
 [1] "2016-10-10 11:18:25  Reading clients.csv" ***
 [1] "2016-10-10 11:18:25  Sleeping for a second"
 [1] "2016-10-10 11:18:26  Reading clients.csv" ***
 [1] "2016-10-10 11:18:26  Sleeping for a second"
 [1] "2016-10-10 11:18:27  Reading clients.csv" ***
 [1] "2016-10-10 11:18:27  Sleeping for a second"
 [1] "2016-10-10 11:18:28  Reading clients.csv" ***
 [1] "2016-10-10 11:18:28  Sleeping for a second"
 }}}

 We could set the timeout to 1 hour or so, to ensure that processed .csv
 file contents are at most 1 hour old.  These files are only updated twice
 per day anyway, so that should be fine.

 A minor downside is that the first user in a given hour will experience a
 delay of a few seconds for reading the .csv file to memory.  This could be
 removed by an approach where we're periodically checking whether file
 contents have changed.

 Something else I didn't evaluate are race conditions.  What if we're
 reading a .csv file to memory and a second request comes in requiring us
 to read that .csv file?

 Final note: let's not overengineer this.  If we switch to another graphing
 engine we'll lose this effort.  Still, it seems like low-hanging fruit to
 eliminate this delay of a few seconds.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_review
 * keywords:  tbb-gitian, GeorgKoppen201610, TorBrowserTeam201610 => tbb-
 gitian, GeorgKoppen201610, TorBrowserTeam201610R


Comment:

 bug_20184_v2 (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20184_v2&id=8cb911a5516dd89e99a429d2c2f5912e3a6a326c)
 in my public tor-browser-bundle has a patch up for review. I tested it on
 different machines with several builds and I got always the same .zip
 file. Looking at the artifacts the differences mentioned in comment:1 2)
 are gone. However, we got a new one only in `libcurve25519_donna.a` which
 is probably a bug in the `ar` tool used. There are always two bytes
 different, e.g.:
 {{{
 @@ -5,7 +5,7 @@
  0040: 2020 600a 5f5f 2e53 594d 4445 4620 534f`.__.SYMDEF SO
  0050: 5254 4544   0800     RTED
  0060: 8000  1800  5f63 7572 7665 3235  _curve25
 -0070: 3531 395f 646f 6e6e 6100 d900    519_donna...
 +0070: 3531 395f 646f 6e6e 6100 6c01    519_donna.l.
  0080: 2331 2f36 3020 2020 2020 2020 2020 2020  #1/60
  0090: 3934 3636 3834 3830 3020 2020 3130 3030  946684800   1000
  00a0: 2020 3130 3030 2020 3130 3036 3434 20201000  100644
 }}}
 It does not affect us at the moment, though.

 For some reason `libfaketime` is needed again which is a bit surprising
 and might merit further investigation as we don't seem to need it in the
 gitian-firefox.yml descriptor.

 I've uploaded a test bundle as I only have an old OSX 10.6 machine
 available (where it worked):

 https://people.torproject.org/~gk/testbuilds/TorBrowser-6.5a3
 -osx64_20184_en-US.dmg
 https://people.torproject.org/~gk/testbuilds/TorBrowser-6.5a3
 -osx64_20184_en-US.dmg.asc

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

Re: [tor-bugs] #18199 [Applications/Tor Browser]: Firefox icon for browser after update

[Tor Bug Tracker & Wiki]

#18199: Firefox icon for browser after update
--+--
 Reporter:  cypherpunks   |  Owner:  mcs
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by rugk):

 BTW I've also opened an upstream issue for this "restart and --class gets
 lost" issue as it also affectes Firefox:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1308719 (You can vote this up
 :). )

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

Re: [tor-bugs] #20121 [Applications/Tor bundles/installation]: Create Seatbealt profile(s) for Tor Browser

[Tor Bug Tracker & Wiki]

#20121: Create Seatbealt profile(s) for Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201610   |  Actual Points:
Parent ID:  #19750   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 See: #8282 for an old bug (there are old sandbox profiles attached) in
 case this can be helpful.

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

Re: [tor-bugs] #20318 [Applications/Tor Browser]: Remove help-desk email address from aboutTor.dtd

[Tor Bug Tracker & Wiki]

#20318: Remove help-desk email address from aboutTor.dtd
--+--
 Reporter:  phoul |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-torbutton
 * owner:   => tbb-team
 * component:  Applications/Torbutton => Applications/Tor Browser


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

Re: [tor-bugs] #20214 [Applications/Tor Browser]: Sonic Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

[Tor Bug Tracker & Wiki]

#20214: Sonic Cross Device Tracking techniques could be used to launch
deanonymization attacks against some users
--+--
 Reporter:  VasiliosMavroudis |  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:
--+--
Changes (by gk):

 * keywords:  tbb-proxy-bypass =>


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

Re: [tor-bugs] #20322 [Applications/Tor Browser]: SafeSEH support for mingw-w64 for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#20322: SafeSEH support for mingw-w64 for Tor Browser on Windows
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:  #16010 =>


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

Re: [tor-bugs] #12425 [Applications/Tor Browser]: Investigate setjmp/longjmp-based exception handling for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#12425: Investigate setjmp/longjmp-based exception handling for Tor Browser on
Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:  #16010 =>


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

Re: [tor-bugs] #786 [Applications/Tor Browser]: file urls cannot be re-enabled after being disabled

[Tor Bug Tracker & Wiki]

#786: file urls cannot be re-enabled after being disabled
--+--
 Reporter:  anonym|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Old description:

> As promised over irc, here's the bug report:
>
> Torbutton is configured to disable plugins. With Torbutton enabled I go
> to
> www.youtube.com and click some random clip. As expected, it complains
> about
> that flash is missing. I disable Torbutton and reload the page, but the
> complaint remains. Re-entering the address in the same tab won't work
> either, and clearing the cache does nothing.
>
> However, if I open a new tab and copy-paste the same address into it,
> that
> works. This new, "good" tab can happily co-exist with the old, "bad" tab,
> which stays bad, unable to load flash. So this seems to be tab specific.
>
> Even if I choose the bad tab an go back to www.youtube.com and again
> choose
> some random clip (or the same one, even by re-entering the address) flash
> won't load. The only cure for the bad tab seems to be to visit another
> site
> and then go back to some youtube clip. Weird stuff.
>
> This is with Torbutton 1.2.0 (not available yet under "Reported
> version").
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 As promised over irc, here's the bug report:

 Torbutton is configured to disable plugins. With Torbutton enabled I go to
 www.youtube.com and click some random clip. As expected, it complains
 about
 that flash is missing. I disable Torbutton and reload the page, but the
 complaint remains. Re-entering the address in the same tab won't work
 either, and clearing the cache does nothing.

 However, if I open a new tab and copy-paste the same address into it, that
 works. This new, "good" tab can happily co-exist with the old, "bad" tab,
 which stays bad, unable to load flash. So this seems to be tab specific.

 Even if I choose the bad tab an go back to www.youtube.com and again
 choose
 some random clip (or the same one, even by re-entering the address) flash
 won't load. The only cure for the bad tab seems to be to visit another
 site
 and then go back to some youtube clip. Weird stuff.

 This is with Torbutton 1.2.0 (not available yet under "Reported version").

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 This is from the toggle area and does not apply to modern Tor Browser
 versions. If there is a similar looking bug without toggle involvement,
 please open a new ticket.

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

Re: [tor-bugs] #17637 [Applications/Tor Browser]: NoScript in Tor-Browser allows all third party domains

[Tor Bug Tracker & Wiki]

#17637: NoScript in Tor-Browser allows all third party domains
--+--
 Reporter:  ctbu  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  NoScript =>
 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 Cascading the permissions is intented, thus fixing that behavior is
 `WONTFIX`.

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

Re: [tor-bugs] #20313 [Applications/Tor Browser]: Usual and hardened browser version get confused by GNOME

[Tor Bug Tracker & Wiki]

#20313: Usual and hardened browser version get confused by GNOME
--+--
 Reporter:  rugk  |  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 gk):

 Setting it in the script has other downsides, see #18199. The approach
 mentioned there (writing a Firefox patch for it) is more promising.

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

Re: [tor-bugs] #18199 [Applications/Tor Browser]: Firefox icon for browser after update

[Tor Bug Tracker & Wiki]

#18199: Firefox icon for browser after update
--+--
 Reporter:  cypherpunks   |  Owner:  mcs
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: rugk (added)


Comment:

 Baking in the proper WM_CLASS value would help as well for users having
 e.g. the stable and the hardened version installed side-by-side. See
 #20313 for such a scenario.

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

Re: [tor-bugs] #7130 [Applications/Tor Browser]: Canvas image data is blocked from chrome (such as NoScript's ClearClick)

[Tor Bug Tracker & Wiki]

#7130: Canvas image data is blocked from chrome (such as NoScript's ClearClick)
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 This got fixed by #13439 I think. (note, though, that we had to disable
 ClearClick, see #14985 for details).

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

Re: [tor-bugs] #17123 [Applications/Tor Browser]: Request for certificate is sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#17123: Request for certificate is sent over the catch-all circuit
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: bugzilla (added)
 * severity:   => Normal


Comment:

 Resolved #20310 as duplicate.

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

Re: [tor-bugs] #20310 [Applications/Tor Browser]: Requests for certificates in Certificate Viewer are sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#20310: Requests for certificates in Certificate Viewer are sent over the 
catch-all
circuit
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #17123.

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

Re: [tor-bugs] #20321 [Applications/Tor Browser]: Mac OS X - Quit Tor Browser Finder Menu Does Not Work from Tor Network Settings

[Tor Bug Tracker & Wiki]

#20321: Mac OS X - Quit Tor Browser Finder Menu Does Not Work from Tor Network
Settings
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-usability


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

Re: [tor-bugs] #9924 [Applications/Tor Browser]: Firefox bug - TBB queries the A record of the hostname of the machine it is running on.

[Tor Bug Tracker & Wiki]

#9924: Firefox bug - TBB queries the A record of the hostname of the machine it 
is
running on.
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-firefox-patch,tbb-proxy-bypass  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  new => needs_information


Comment:

 cypherpunks: Is that still an issue? If so, do you have logs (pcaps) for
 that? A couple of days ago I checked Tor Browser start-up on a Windows
 machine and no DNS resolution outside of Tor showed up

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