Re: [tor-bugs] #19001 [Obfuscation/Snowflake]: Tor Browser with Snowflake

[Tor Bug Tracker & Wiki]

#19001: Tor Browser with Snowflake
---+-
 Reporter:  dcf|  Owner:
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by dcf):

 I built bundles with `make alpha` from
 [https://gitweb.torproject.org/user/dcf/tor-browser-
 bundle.git/log/?h=snowflake=6cd7c411e8910d75f5ef18e86bbe682f943aa229
 6cd7c411e8]. So `make alpha` works, and you should use that in preference
 to `make nightly`.
   https://people.torproject.org/~dcf/pt-
 bundle/snowflake/20160510-6.0a5-6cd7c411e891/

 I built it twice in a row, and the output files matched.

 The whole build (of linux only) took almost 8 hours.
 {{{
 real471m19.011s
 user3m50.328s
 sys 3m25.008s
 }}}

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

Re: [tor-bugs] #19031 [Applications/TorBirdy]: Audit Thunderbird's RSS support

[Tor Bug Tracker & Wiki]

#19031: Audit Thunderbird's RSS support
---+-
 Reporter:  sukhbir|  Owner:  sukhbir
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by sukhbir):

 Updates:

 - Automatic fetching was not disabled and the value was hard coded. So we
 needed an overlay which I pushed in 0968621f.
 - HTML has also been disabled. The options are similar to the mailnews
 settings. See 174cd10.
 - JavaScript disabled: already doing it.
 - Proxy settings respected: yes.

 I think the only concern I have now is that clicking the "Website" (in the
 message pane) to get the complete article shows the Launch Application
 window using which a user may choose a browser that is not Tor Browser.
 Now we can do either of the following:

 - Disable the link so that a user has to manually copy it and doesn't
 inadvertently click on it
 - Warn the user but then show the Launch Application and let them decide.
 - Be smart and open in Tor Browser. (I am not sure if this one is easy).

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

Re: [tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Normal   |Version:
 Keywords:  modularity, tor-modularity,  | Resolution:
  TorCoreTeam201605, TorCoreTeam-|  implemented
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-

Comment (by cypherpunks):

 `pubsub_subscriber_t *r = tor_malloc_zero(sizeof(r));`

 Nice.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19038 [Core Tor/Tor]: Test failure on the latest commit

[Tor Bug Tracker & Wiki]

#19038: Test failure on the latest commit
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 the latest git ( commit 9e44273a4a22803eff900f6df10f13c7548bdb0d ) is
 failing on tests; the system is linux debian unstable 32bit :


 {{{
 util/pubsub/pubsub_basic: [forking] *** Error in `./src/test/test':
 free(): invalid next size (fast): 0x823300d8 ***
 === Backtrace: =
 /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x692ab)[0xb5c1d2ab]
 /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6f4f7)[0xb5c234f7]
 /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6fca1)[0xb5c23ca1]
 ./src/test/test(pubsub_unsubscribe_+0x6e)[0x81d540fe]
 ./src/test/test(+0x185ad4)[0x81b7fad4]
 ./src/test/test(+0x20d081)[0x81c07081]
 ./src/test/test(testcase_run_one+0x162)[0x81c07242]
 ./src/test/test(tinytest_main+0x134)[0x81c07994]
 ./src/test/test(main+0x26d)[0x81a3575d]
 /lib/i386-linux-
 gnu/i686/cmov/libc.so.6(__libc_start_main+0xf7)[0xb5bcc527]
 ./src/test/test(+0x3b89d)[0x81a3589d]
 === Memory map: 
 819fa000-81fec000 r-xp  fe:00 2625171$HOME/tor-
 build/tor/build/src/test/test
 81fed000-81ff r--p 005f2000 fe:00 2625171$HOME/tor-
 build/tor/build/src/test/test
 81ff-82002000 rw-p 005f5000 fe:00 2625171$HOME/tor-
 build/tor/build/src/test/test
 82002000-82008000 rw-p  00:00 0
 82317000-82387000 rw-p  00:00 0  [heap]
 b5992000-b59a6000 r-xp  fe:00 525448 /lib/i386-linux-
 gnu/i686/cmov/libresolv-2.22.so
 b59a6000-b59a7000 r--p 00013000 fe:00 525448 /lib/i386-linux-
 gnu/i686/cmov/libresolv-2.22.so
 b59a7000-b59a8000 rw-p 00014000 fe:00 525448 /lib/i386-linux-
 gnu/i686/cmov/libresolv-2.22.so
 b59a8000-b59aa000 rw-p  00:00 0
 b59aa000-b59af000 r-xp  fe:00 525378 /lib/i386-linux-
 gnu/i686/cmov/libnss_dns-2.22.so
 b59af000-b59b r--p 4000 fe:00 525378 /lib/i386-linux-
 gnu/i686/cmov/libnss_dns-2.22.so
 b59b-b59b1000 rw-p 5000 fe:00 525378 /lib/i386-linux-
 gnu/i686/cmov/libnss_dns-2.22.so
 b59b1000-b59c1000 r-xp  fe:00 393537 /lib/i386-linux-
 gnu/libnss_myhostname.so.2
 b59c1000-b59c2000 ---p 0001 fe:00 393537 /lib/i386-linux-
 gnu/libnss_myhostname.so.2
 b59c2000-b59c3000 r--p 0001 fe:00 393537 /lib/i386-linux-
 gnu/libnss_myhostname.so.2
 b59c3000-b59c4000 rw-p 00011000 fe:00 393537 /lib/i386-linux-
 gnu/libnss_myhostname.so.2
 b59c4000-b59cf000 r-xp  fe:00 525379 /lib/i386-linux-
 gnu/i686/cmov/libnss_files-2.22.so
 b59cf000-b59d r--p a000 fe:00 525379 /lib/i386-linux-
 gnu/i686/cmov/libnss_files-2.22.so
 b59d-b59d1000 rw-p b000 fe:00 525379 /lib/i386-linux-
 gnu/i686/cmov/libnss_files-2.22.so
 b59d1000-b59d9000 rw-p  00:00 0
 b59d9000-b59ed000 r-xp  fe:00 393740 /lib/i386-linux-gnu
 /libgpg-error.so.0.18.0
 b59ed000-b59ee000 r--p 00013000 fe:00 393740 /lib/i386-linux-gnu
 /libgpg-error.so.0.18.0
 b59ee000-b59ef000 rw-p 00014000 fe:00 393740 /lib/i386-linux-gnu
 /libgpg-error.so.0.18.0
 b59ef000-b5a62000 r-xp  fe:00 393297 /lib/i386-linux-
 gnu/libpcre.so.3.13.2
 b5a62000-b5a63000 r--p 00072000 fe:00 393297 /lib/i386-linux-
 gnu/libpcre.so.3.13.2
 b5a63000-b5a64000 rw-p 00073000 fe:00 393297 /lib/i386-linux-
 gnu/libpcre.so.3.13.2
 b5a64000-b5a68000 r-xp  fe:00 393322 /lib/i386-linux-
 gnu/libattr.so.1.1.0
 b5a68000-b5a69000 r--p 3000 fe:00 393322 /lib/i386-linux-
 gnu/libattr.so.1.1.0
 b5a69000-b5a6a000 rw-p 4000 fe:00 393322 /lib/i386-linux-
 gnu/libattr.so.1.1.0
 b5a6a000-b5a6b000 rw-p  00:00 0
 b5a6b000-b5a87000 r-xp  fe:00 393557 /lib/i386-linux-
 gnu/libgcc_s.so.1
 b5a87000-b5a88000 rw-p 0001b000 fe:00 393557 /lib/i386-linux-
 gnu/libgcc_s.so.1
 b5a88000-b5b51000 r-xp  fe:00 393602 /lib/i386-linux-
 gnu/libgcrypt.so.20.1.0
 b5b51000-b5b52000 ---p 000c9000 fe:00 393602 /lib/i386-linux-
 gnu/libgcrypt.so.20.1.0
 b5b52000-b5b53000 r--p 000c9000 fe:00 393602 /lib/i386-linux-
 gnu/libgcrypt.so.20.1.0
 b5b53000-b5b56000 rw-p 000ca000 fe:00 393602 /lib/i386-linux-
 gnu/libgcrypt.so.20.1.0
 b5b56000-b5b7c000 r-xp  fe:00 393222 /lib/i386-linux-
 gnu/liblzma.so.5.0.0
 b5b7c000-b5b7e000 r--p 00026000 fe:00 393222 /lib/i386-linux-
 gnu/liblzma.so.5.0.0
 b5b7e000-b5b7f000 rw-p 00028000 fe:00 393222 /lib/i386-linux-
 gnu/liblzma.so.5.0.0
 b5b7f000-b5b86000 r-xp  fe:00 525449 /lib/i386-linux-
 gnu/i686/cmov/librt-2.22.so
 b5b86000-b5b87000 r--p 6000 fe:00 525449 

Re: [tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Normal   |Version:
 Keywords:  modularity, tor-modularity,  | Resolution:
  TorCoreTeam201605, TorCoreTeam-|  implemented
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-

Comment (by arma):

 {{{util/pubsub/pubsub_basic: [forking] *** Error in `./src/test/test':
 free(): invalid next size (fast): 0xf7890ee0 ***}}}

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

Re: [tor-bugs] #18958 [Applications/Tor Browser]: screen.orientation should lie

[Tor Bug Tracker & Wiki]

#18958: screen.orientation should lie
-+-
 Reporter:  mcs  |  Owner:
 Type:  defect   |  arthuredelstein
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R  |Version:
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:5 mcs]:
 > r=mcs, r=brade
 > These changes look good. Should we also skip dispatching of the
 orientation change events when ShouldResistFingerprinting() returns true?
 Generating the events will allow a website to detect that my device can
 change orientation.

 Thanks for the review. Here's a new version that blocks
 "orientationchange" and "mozorientationchange" events from being
 dispatched. I also blocked the use of 'screen.mozLockOrientation' and
 'screen.mozUnlockOrientation' for a similar reason.

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

Re: [tor-bugs] #18840 [Core Tor/Tor]: dir auths vote "package" lines out of order

[Tor Bug Tracker & Wiki]

#18840: dir auths vote "package" lines out of order
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * status:  new => needs_review


Comment:

 One-line patch is in my {{{bug18840} branch.

 Tested and working on moria1.

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

Re: [tor-bugs] #19037 [Applications/Tor Browser]: Suppress content access to page visibility API

[Tor Bug Tracker & Wiki]

#19037: Suppress content access to page visibility API
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 Type:  defect   |  team
 Priority:  Medium   | Status:  new
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  tbb-linkability, | Resolution:
  TorBrowserTeam201605   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by arthuredelstein:

Old description:

> The `document.visibility` property and the `visibilitychange` event let
> content know if the user has selected or deselected a tab. If the user
> switches from tab A to tab B, then tab A can observe a "hidden" event at
> the same time that tab B receives a "visibile" event. So it seems
> potentially useful to suppress this information.
>
> See https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API

New description:

 The `document.visibility` property and the `visibilitychange` event let
 content know if the user has selected or deselected a tab. If the user
 switches from tab A to tab B, then tab A can receive a "hidden" event at
 the same time that tab B receives a "visible" event. So it seems
 potentially useful to suppress this information.

 See https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19037 [Applications/Tor Browser]: Suppress content access to page visibility API

[Tor Bug Tracker & Wiki]

#19037: Suppress content access to page visibility API
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-linkability,
 Severity:  Normal   |  TorBrowserTeam201605
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The `document.visibility` property and the `visibilitychange` event let
 content know if the user has selected or deselected a tab. If the user
 switches from tab A to tab B, then tab A can observe a "hidden" event at
 the same time that tab B receives a "visibile" event. So it seems
 potentially useful to suppress this information.

 See https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API

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

Re: [tor-bugs] #16443 [Applications/Tor Browser]: Audit tiles targeting in FF45esr

[Tor Bug Tracker & Wiki]

#16443: Audit tiles targeting in FF45esr
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff45-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

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


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

Re: [tor-bugs] #18904 [Applications/Tor Browser]: Mac OS: meek-http-helper profile not updated

[Tor Bug Tracker & Wiki]

#18904: Mac OS: meek-http-helper profile not updated
+--
 Reporter:  mcs |  Owner:  mcs
 Type:  defect  | Status:
 Priority:  Medium  |  needs_information
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--

Comment (by mcs):

 Replying to [comment:5 gk]:
 > To recap: the problem exists because the updater is not reaching that
 part anymore and thus, there is no way to get a newer meek extension and
 prefs file to the user, right?

 Right. On Mac OS, the meek-client-torbrowser program now creates the meek-
 http-helper profile by copying everything in a template directory. But it
 only knows to do that if the destination profile directory does not exist
 at all.

 > While thinking about your solution it occurred to me that the profile
 would get overwritten every time the user had chosen to use meek because
 that causes the profile dir getting used and thus the checksum is not
 matching anymore. Is that intended?

 Actually, we are not planning to generate a checksum based on the files
 that are on the user's computer. Our idea is to generate a checksum once
 when we build Tor Browser and then use the checksum file as a kind of
 version to indicate that the meek-http-helper profile was created from a
 different template (that is, from a different version of Tor Browser).
 That way the profile will only be removed and recreated when the template
 files are modified.

 > Is there a way to get the Tor Browser version from meek-client-
 torbrowser code? Probably, I guess. Couldn't we force-update the profile
 dir instead in case a new Tor Browser version got installed?

 We could try to get the version number and store it in a file. But I am
 not sure how the meek-client-torbrowser code could easily get the version
 number. The checksum file we propose would serve as an automatically
 generated version number, but we could instead store the Tor Browser
 version number in a similar way, e.g., in a file named tor-browser-
 version.txt within the meek-http-helper profile. And that file could be
 created at build/bundling time. Using a hash of the meek files would be
 slightly more efficient since the meek-http-helper files (extension plus
 user.js) do not change with every Tor Browser 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] #19036 [Core Tor/Tor]: Write v3-status-votes file even when we fail to make a consensus

[Tor Bug Tracker & Wiki]

#19036: Write v3-status-votes file even when we fail to make a consensus
+--
 Reporter:  arma|  Owner:
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  029-proposed|  Actual Points:
Parent ID:  | Points:
 Reviewer:  sysrqb dgoulet  |Sponsor:
+--
Changes (by arma):

 * cc: dgoulet (added)
 * reviewer:  sysrqb => sysrqb dgoulet


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

Re: [tor-bugs] #19036 [Core Tor/Tor]: Write v3-status-votes file even when we fail to make a consensus

[Tor Bug Tracker & Wiki]

#19036: Write v3-status-votes file even when we fail to make a consensus
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:  sysrqb|Sponsor:
--+--
Changes (by arma):

 * cc: sysrqb (added)
 * status:  new => needs_review
 * type:  defect => enhancement
 * reviewer:   => sysrqb


Comment:

 See my {{{feature19036}}} branch.

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

[tor-bugs] #19036 [Core Tor/Tor]: Write v3-status-votes file even when we fail to make a consensus

[Tor Bug Tracker & Wiki]

#19036: Write v3-status-votes file even when we fail to make a consensus
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  029-proposed
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In dirvote_compute_consensuses(), we have checks for {{{if (n_votes <=
 n_voters/2)}}} and {{{if (!n_vote_running)}}}, which cause us to fail and
 abort, before we get around to the
 {{{
   votefile = get_datadir_fname("v3-status-votes");
   write_chunks_to_file(votefile, votestrings, 0, 0);
 }}}
 lines.

 We should write the votes out to the file earlier in this process, so
 operators can read them to see available votes even in the failure case.

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

Re: [tor-bugs] #18601 [Applications/Tor Browser]: User Timing API in workers might expose high resolution time to content

[Tor Bug Tracker & Wiki]

#18601: User Timing API in workers might expose high resolution time to content
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff45-esr, TorBrowserTeam201605 => ff45-esr,
 TorBrowserTeam201605R
 * 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] #18601 [Applications/Tor Browser]: User Timing API in workers might expose high resolution time to content

[Tor Bug Tracker & Wiki]

#18601: User Timing API in workers might expose high resolution time to content
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff45-esr, TorBrowserTeam201605  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 I manually confirmed that the User Timing API (performance marks and
 performance measures) are removed when the `dom.enable_user_timing` pref
 is disabled (as was already done in #16336).

 Here is what I did:

 1. Enable `dom.enable_user_timing`:

 {{{
 > new
 
Worker("data:text/javascript,postMessage(Object.getOwnPropertyNames(performance.__proto__).sort().join(',
 '));").onmessage = msg => console.log(msg.data);

 < clearMarks, clearMeasures, constructor, getEntries, getEntriesByName,
 getEntriesByType, mark, measure, now
 }}}

 2. Disable `dom.enable_user_timing`:
 {{{
 > new
 
Worker("data:text/javascript,postMessage(Object.getOwnPropertyNames(performance.__proto__).sort().join(',
 '));").onmessage = msg => console.log(msg.data);

 < constructor, now
 }}}

 We should be able to pretty easily automate such tests in #18597.

 I also checked the performance object in a non-Worker context:
 1. Enabling `dom.enable_user_timing`:
 {{{
 > Object.getOwnPropertyNames(performance.__proto__).sort().join(", ")

 < "clearMarks, clearMeasures, clearResourceTimings, constructor,
 getEntries, getEntriesByName, getEntriesByType, mark, measure, navigation,
 now, onresourcetimingbufferfull, setResourceTimingBufferSize, timing,
 toJSON"
 }}}
 2. Disabling `dom.enable_user_timing`:
 {{{
 > Object.getOwnPropertyNames(performance.__proto__).sort().join(", ")

 < "constructor, navigation, now, timing, toJSON"
 }}}

 So the only leftover things in the main-thread `performance` object are
 `performance.now()` and `performance.timing` and `performance.toJSON()`
 which all look clean 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] #18904 [Applications/Tor Browser]: Mac OS: meek-http-helper profile not updated

[Tor Bug Tracker & Wiki]

#18904: Mac OS: meek-http-helper profile not updated
+--
 Reporter:  mcs |  Owner:  mcs
 Type:  defect  | Status:
 Priority:  Medium  |  needs_information
Component:  Applications/Tor Browser|  Milestone:
 Severity:  Normal  |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605  | Resolution:
Parent ID:  |  Actual Points:
 Reviewer:  | Points:
|Sponsor:
+--

Comment (by gk):

 To recap: the problem exists because the updater is not reaching that part
 anymore and thus, there is no way to get a newer meek extension and prefs
 file to the user, right?

 While thinking about your solution it occurred to me that the profile
 would get overwritten every time the user had chosen to use meek because
 that causes the profile dir getting used and thus the checksum is not
 matching anymore. Is that intended?

 Is there a way to get the Tor Browser version from meek-client-torbrowser
 code? Probably, I guess. Couldn't we force-update the profile dir instead
 in case a new Tor Browser version got installed?

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

Re: [tor-bugs] #17621 [Core Tor/Tor]: Document the files in $datadir/keys, maybe in the man page?

[Tor Bug Tracker & Wiki]

#17621: Document the files in $datadir/keys, maybe in the man page?
---+
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0.1
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  SponsorU-can
---+

Comment (by arma):

 Looks good! I pushed a bug17621-try2 branch to my tor git repo, which has
 some minor tweaks. Ready to merge if you like.

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

Re: [tor-bugs] #14013 [Core Tor/Tor]: base16_decode() API is inconsistent and error-prone

[Tor Bug Tracker & Wiki]

#14013: base16_decode() API is inconsistent and error-prone
---+
 Reporter:  nickm  |  Owner:  nikkolasg
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  lorax, review-group-1  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorS-can
---+
Changes (by nikkolasg):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #14013 [Core Tor/Tor]: base16_decode() API is inconsistent and error-prone

[Tor Bug Tracker & Wiki]

#14013: base16_decode() API is inconsistent and error-prone
---+
 Reporter:  nickm  |  Owner:  nikkolasg
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  lorax, review-group-1  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorS-can
---+

Comment (by nikkolasg):

 Oups, I thought I could remove the first patch but no..
 Adapted the code for your first two points.
 About the third:
  - Value 17B1C409A7B0E9A9E307D38A18AF7E5F8C15C803
  - Size of output 20 (vs 32)
  - Failing tests:
 - dir/clip_unmeasured_bw_kb
 - dir/clip_unmeasured_bw_kb_alt
 - dir/v3_networkstatus

 If you'd like I can try to debug it further but to be honest, I think a
 more experienced Tor developer will be far most efficient (=fast) than me
 as I have to understand the whole codebase evolving around this line. That
 said, I'm willing to try ;)

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

Re: [tor-bugs] #18995 [Applications/Tor Browser]: Investigate CacheStorage feature for tracking usage in Tor Browser

[Tor Bug Tracker & Wiki]

#18995: Investigate CacheStorage feature for tracking usage in Tor Browser
-+-
 Reporter:  gk   |  Owner:
 Type:  task |  arthuredelstein
 Priority:  High | Status:  closed
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Major|Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:  fixed
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks! Applied to tor-browser-45.1.0esr-6.0-1 (commit
 cea5f1efcd9590885127a0763432143aca01524c)..

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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--

Comment (by atagar):

 Nothing that's been mentioned ('GET /tor/bytes.txt' or 'GETINFO dir-
 usage') is ringing any bells. Sounds fine to remove 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] #18995 [Applications/Tor Browser]: Investigate CacheStorage feature for tracking usage in Tor Browser

[Tor Bug Tracker & Wiki]

#18995: Investigate CacheStorage feature for tracking usage in Tor Browser
-+-
 Reporter:  gk   |  Owner:
 Type:  task |  arthuredelstein
 Priority:  High | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Major|  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R  |Version:
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:6 gk]:
 > Looks good to me. Could we get rid of the commented SimpleTest.js
 inclusion in the .html files? I think the "#" is not necessary before the
 bug number there either. "Bug 18995" is perfectly fine. :)

 Thanks for the review. Here's the new version:
 ​https://github.com/arthuredelstein/tor-browser/commit/18995+1
 Hash cea5f1efcd9590885127a0763432143aca01524c

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

Re: [tor-bugs] #18365 [Core Tor/Tor]: Fined-grain timer implementation to support per-connection or per-circuit timers

[Tor Bug Tracker & Wiki]

#18365: Fined-grain timer implementation to support per-connection or 
per-circuit
timers
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  Medium   |  reopened
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  performance, backend,|Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604   |  Actual Points:  medium
Parent ID:   | Points:  medium
 Reviewer:  mikeperry,athena |Sponsor:
-+-

Comment (by arma):

 I just merged commit 9e44273a4 which fixes 'make dist'.

 Somebody should sanity-check that this was a reasonable plan, and that
 there isn't anything else that wants fixing, and then re-close the ticket.

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

Re: [tor-bugs] #18365 [Core Tor/Tor]: Fined-grain timer implementation to support per-connection or per-circuit timers

[Tor Bug Tracker & Wiki]

#18365: Fined-grain timer implementation to support per-connection or 
per-circuit
timers
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  Medium   |  reopened
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  performance, backend,|Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604   |  Actual Points:  medium
Parent ID:   | Points:  medium
 Reviewer:  mikeperry,athena |Sponsor:
-+-
Changes (by arma):

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


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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--

Comment (by weasel):

 I don't mind having it removed.

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

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

[Tor Bug Tracker & Wiki]

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => assigned
 * owner:   => nikkolasg


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

Re: [tor-bugs] #18976 [Applications/Tor Browser]: Remove some FTE bridges

[Tor Bug Tracker & Wiki]

#18976: Remove some FTE bridges
--+--
 Reporter:  kpdyer|  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201605R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Applied to master (commit bd2d6d501e88599a86b7a55a23f1731c0ec6ed74) and
 hardened-builds (commit 076028da65ee8d4785b65f818e7f8c19bf9e3f0b).

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

Re: [tor-bugs] #18915 [Applications/Tor Browser]: Omnibox in a non-english Tor Browser has no Disconnect.me as search engine in 6.0a5

[Tor Bug Tracker & Wiki]

#18915: Omnibox in a non-english Tor Browser has no Disconnect.me as search 
engine
in 6.0a5
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  ff45-esr, TorBrowserTeam201605R, |  Actual Points:
  GeorgKoppen201605  | Points:
Parent ID:   |Sponsor:
 Reviewer:   |
-+-
Changes (by gk):

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


Comment:

 Good catch. I changed the patched and merged the result to master (commit
 94c6a1c73291f8f456249d9719de57ff002fe6fe) and hardened-builds (commit
 467796a7b7901fc22f26716860ed6ed8d4102416).

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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--
Changes (by arma):

 * cc: atagar, dgoulet (added)


Comment:

 Damian: will we break anything in your stem-land with this change?

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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--
Changes (by arma):

 * keywords:   => 029-proposed
 * status:  new => needs_review


Comment:

 Also see my task19035-spec branch in my torspec.

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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--

Comment (by arma):

 My task19035 branch removes these features.

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

Re: [tor-bugs] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+--

Comment (by arma):

 Turns out there's a control-spec way of requesting this data too:
 {{{
 "dir-usage"
   A newline-separated list of how many bytes we've served to answer
   each type of directory request. The format of each line is:
  Keyword 1*SP Integer 1*SP Integer
   where the first integer is the number of bytes written, and the
 second
   is the number of requests answered.
 }}}
 But that said, it simply returns "Not implemented" unless your Tor has the
 compile-time option enabled. So I think nobody is going to miss this
 option.

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

Re: [tor-bugs] #19003 [Core Tor/Tor]: Make sure small networks can bootstrap without exits

[Tor Bug Tracker & Wiki]

#19003: Make sure small networks can bootstrap without exits
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1 regression   |  0.2.8.2-alpha
Parent ID:   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:4 arma]:
 > {{{
 > + * If need_exit is false, return 0 if we can build internal paths.
 > }}}
 > Do you mean return 1 here?
 >
 > teor: I just pushed a bug19003-try2 branch to my git. It contains this
 fix plus also some refactoring of your other change. If you agree that the
 refactoring doesn't break anything, I think we're all set here.

 This looks good to me. Let's get it merged.

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

Re: [tor-bugs] #18815 [Core Tor/Tor]: Clients don't use optimistic data to fetch their first consensus, because we told them to ask the consensus whether they should

[Tor Bug Tracker & Wiki]

#18815: Clients don't use optimistic data to fetch their first consensus, 
because
we told them to ask the consensus whether they should
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:  implemented
Parent ID:|  Actual Points:  very small
 Reviewer:| Points:  very small
  |Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => closed
 * type:  defect => enhancement
 * resolution:   => implemented


Comment:

 Thanks for the review; merged!

 (I claim that this is not actually a bugfix but a feature, and so it
 doesn't need a "fix on" version.)

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

Re: [tor-bugs] #18815 [Core Tor/Tor]: Clients don't use optimistic data to fetch their first consensus, because we told them to ask the consensus whether they should

[Tor Bug Tracker & Wiki]

#18815: Clients don't use optimistic data to fetch their first consensus, 
because
we told them to ask the consensus whether they should
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:
Parent ID:|  Actual Points:  very small
 Reviewer:| Points:  very small
  |Sponsor:
--+

Comment (by sysrqb):

 Same, 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] #18815 [Core Tor/Tor]: Clients don't use optimistic data to fetch their first consensus, because we told them to ask the consensus whether they should

[Tor Bug Tracker & Wiki]

#18815: Clients don't use optimistic data to fetch their first consensus, 
because
we told them to ask the consensus whether they should
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:
Parent ID:|  Actual Points:  very small
 Reviewer:| Points:  very small
  |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Changes file doesn't mention the "fix on" tor version. Anyway, simple
 enough. Both patches look good to me!

 Tested in chutney as well with success.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19035 [Core Tor/Tor]: Rip out client directory fetch instrumentation

[Tor Bug Tracker & Wiki]

#19035: Rip out client directory fetch instrumentation
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:  dgoulet
  Sponsor:|
--+--
 In the distant past, weasel put in a feature where clients would track
 number of bytes they receive by what category of directory information,
 and then you could query the current sums via the dirport ("GET
 /tor/bytes.txt"). It went into 0.2.1.1-alpha I think (see git commits
 01c1a355 and 716558a), but it didn't get a changelog entry or a trac
 ticket, and also it only works {{{#if defined(INSTRUMENT_DOWNLOADS) ||
 defined(RUNNING_DOXYGEN)}}}.

 I don't think anybody is using it now, and nobody in the Montreal Meeting
 wanted to keep it, so it looks like we should simplify by removing it.

 I am cc'ing weasel since it was his feature originally, and now he can
 speak up in favor of its life if he wants.

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

Re: [tor-bugs] #19023 [Core Tor]: Improve prop224 quality (montreal hackfest)

[Tor Bug Tracker & Wiki]

#19023: Improve prop224 quality (montreal hackfest)
--+--
 Reporter:  asn   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by special):

 arma's comments are fixed by `bca05ca2` on my `prop224-montreal` branch.

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

Re: [tor-bugs] #17621 [Core Tor/Tor]: Document the files in $datadir/keys, maybe in the man page?

[Tor Bug Tracker & Wiki]

#17621: Document the files in $datadir/keys, maybe in the man page?
---+
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201605  |  Actual Points:  0.1
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  SponsorU-can
---+
Changes (by nickm):

 * status:  accepted => needs_review
 * points:   => 0.1
 * actualpoints:   => 0.1


Comment:

 Documentation in my branch `bug17621`.

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn  |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hello and sorry for the slow review! This seems like a great feature for
 mobile devices, and the patch seems to be almost there. The main issue is
 the unittest not passing.

 Here are some comments:

 - Your tests don't work because your descriptor string was prepared for
 the control port tests. If you remove the carriage returns "\r" characters
 from the end of each line then the parsing should proceed.

  However, that's not enough for it to go through
 `rend_cache_store_v2_desc_as_client()`. You also need to fix up the desc
 id which currently is not correct, and you also need a dynamic descriptor
 timestamp to bypass the age check. I had to uncomment the following checks
 to complete the test (which passes fine btw):
 {{{
   /* if (parsed->timestamp < now - REND_CACHE_MAX_AGE-REND_CACHE_MAX_SKEW)
 { */
   /*   printf( "Service descriptor with service ID %s is too old.", */
   /*safe_str_client(service_id)); */
   /*   goto err; */
   /* } */
 }}}
 {{{
 +  /* if (tor_memneq(desc_id, want_desc_id, DIGEST_LEN)) { */
 +  /*   printf( "Received service descriptor for %s with incorrect " */
 +  /*   "descriptor ID (%s).", service_id, want_desc_id); */
 +  /*   goto err; */
 +  /* } */
 }}}

  To debug this, I turned all the `log_warn()`s in the parsing functions to
 `printf`s, and then I could see the offending error messages when I ran
 the tests.

 - I think there is no need to add the base64 padding yourself in
 `descriptor_cookie_base64ext()`. Instead you can use
 `base64_decode_nopad()`. I think this should work, but there were no tests
 about descriptor cookies so I'm not 100% sure.

 - Also, in `rend_cache_remove_entry()` there is no need to handle v0
 descriptors. These have been deprecated, feel free to kill that code.

 - The patch does not compile with `./configure --enable-gcc-warnings`
 because you have a few unused function arguments in the tests. You can
 solve this by doing `(void) arg;`.

 - Also, it would be great if you could provide a git branch based on the
 current master, instead of a standalone patch because I had trouble
 merging it. Feel free to upload it ot any repo (github, gitlab) or even
 just post a detached git-bundle. If that's too hard, no worries.

 - Finally, I noticed that in `rend_client_note_connection_attempt_ended()`
 we do:
 {{{
   if (cache_entry != NULL) {
 SMARTLIST_FOREACH(cache_entry->parsed->intro_nodes,
   rend_intro_point_t *, ip,
   ip->timed_out = 0; );
   }
 }}}
  Do you think that would be useful for this 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] #19034 [Core Tor/Tor]: Declaring authorities with matching relay keys should fail

[Tor Bug Tracker & Wiki]

#19034: Declaring authorities with matching relay keys should fail
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  small
 Reviewer:|Sponsor:
--+--
Description changed by teor:

Old description:

> If a:
> * hard-coded entry or
> * config entry,
> tries to add:
> * an authority,
> * a bridge authority, or
> * a fallback directory,
> with the same:
> * relay key,
> * v3ident key,
> * address and port, or
> * other should-be-unique attribute
> as an existing entry, tor should warn and refuse to start.

New description:

 If a:
 * hard-coded entry or
 * config entry,
 tries to add:
 * an authority,
 * a bridge authority, or
 * a fallback directory,
 with the same:
 * relay key,
 * v3ident key,
 * IPv4 address and ORPort (matching any other IPv4 address and port), or
 * IPv4 address and DirPort (matching any other IPv4 address and port),
 * IPv6 address and ORPort (matching any other IPv6 address and port), or
 * IPv6 address and (IPv4) DirPort (matching any other IPv6 address and
 port),
 as an existing entry, tor should warn and refuse to start.

--

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

Re: [tor-bugs] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed, review-group-1   |  0.2.8.1-alpha
Parent ID:  #18816   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by teor):

 Please see my branch bug18963-remember-v2

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

Re: [tor-bugs] #18956 [Core Tor/Tor]: Trivial memory leak when reading truncated ed25519 key files

[Tor Bug Tracker & Wiki]

#18956: Trivial memory leak when reading truncated ed25519 key files
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  review-group-1  |  Actual Points:  very small
Parent ID:  #16794  | Points:  very small
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 Okay. This will get merged when #16794 is merged.

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

Re: [tor-bugs] #18956 [Core Tor/Tor]: Trivial memory leak when reading truncated ed25519 key files

[Tor Bug Tracker & Wiki]

#18956: Trivial memory leak when reading truncated ed25519 key files
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  review-group-1  |  Actual Points:  very small
Parent ID:  #16794  | Points:  very small
 Reviewer:  |Sponsor:
+
Changes (by special):

 * 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

[tor-bugs] #19034 [Core Tor/Tor]: Declaring authorities with matching relay keys should fail

[Tor Bug Tracker & Wiki]

#19034: Declaring authorities with matching relay keys should fail
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:  small |   Reviewer:
  Sponsor:|
--+--
 If a:
 * hard-coded entry or
 * config entry,
 tries to add:
 * an authority,
 * a bridge authority, or
 * a fallback directory,
 with the same:
 * relay key,
 * v3ident key,
 * address and port, or
 * other should-be-unique attribute
 as an existing entry, tor should warn and refuse to start.

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

Re: [tor-bugs] #16698 [Core Tor/Tor]: Split directory_handle_command_get into per-command functions

[Tor Bug Tracker & Wiki]

#16698: Split directory_handle_command_get into per-command functions
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Normal   |Version:
 Keywords:  028-triaged, tor-tests-coverage, | Resolution:
  tor-tests-unit, TorCoreTeam201605, review- |  implemented
  group-1|  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |  small/medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

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


Comment:

 Fixed up and merged!

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

Re: [tor-bugs] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
-+-
 Reporter:  special  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.7.x-final
 Severity:  Critical |Version:
 Keywords:  TorCoreTeam201605 regression | Resolution:  fixed
  review-group-1 |  Actual Points:  0
Parent ID:   | Points:  0
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * points:   => 0
 * actualpoints:   => 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

[tor-bugs] #19033 [Core Tor/Chutney]: Write a chutney test for #19032

[Tor Bug Tracker & Wiki]

#19033: Write a chutney test for #19032
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorS-can  |
--+--
 We want to make sure we fixed all the issues with nodelist processing in
 #19032.

 arma says this could be SponsorS or SponsorU.

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

Re: [tor-bugs] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
-+-
 Reporter:  special  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.7.x-final
 Severity:  Critical |Version:
 Keywords:  TorCoreTeam201605 regression | Resolution:  fixed
  review-group-1 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU-can
-+-
Changes (by nickm):

 * sponsor:   => SponsorU-can


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

Re: [tor-bugs] #16698 [Core Tor/Tor]: Split directory_handle_command_get into per-command functions

[Tor Bug Tracker & Wiki]

#16698: Split directory_handle_command_get into per-command functions
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  028-triaged, tor-tests-coverage, |Version:
  tor-tests-unit, TorCoreTeam201605, review- | Resolution:
  group-1|  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |  small/medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 * Comment says the follow for `directory_handle_command_get()` but we do
 return 404 at the end if unrecognized (`/* we didn't recognize the url
 */`). I'm guessing this is just a comment issue here.

 {{{
  * ... If the request is unrecognized, send a 400.
  * Always return 0. */
 }}}

 Putting this in `merge_ready` because the above is easy to fix thus falls
 under nickm.

 rest lgtm! (and I'm happp about that change :)

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

Re: [tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.9.x-final
 Severity:  Normal   |Version:
 Keywords:  modularity, tor-modularity,  | Resolution:
  TorCoreTeam201605, TorCoreTeam-|  implemented
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  High |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  modularity, tor-modularity,  |Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-

Comment (by nickm):

 Thanks David! Squashing & Merging.  Calling the other stuff "can fix later
 if needed".

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

Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 Merged bug18816_simplify! We can  close once child ticket is closed.

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

Re: [tor-bugs] #18760 [Core Tor/Tor]: I'd like to customize rejection message from dir auths to relay

[Tor Bug Tracker & Wiki]

#18760: I'd like to customize rejection message from dir auths to relay
--+
 Reporter:  arma  |  Owner:  arma
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:  implemented
Parent ID:|  Actual Points:
 Reviewer:  nickm | Points:
  |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Okay. Merged it to 0.2.9. 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] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
-+-
 Reporter:  special  |  Owner:
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.7.x-final
 Severity:  Critical |Version:
 Keywords:  TorCoreTeam201605 regression | Resolution:  fixed
  review-group-1 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to 0.2.7 and forwards. 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] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed, review-group-1   |  0.2.8.1-alpha
Parent ID:  #18816   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by teor):

 I just reverted a commit in #18816, I need to make sure this is rebased.

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

Re: [tor-bugs] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
-+-
 Reporter:  special  |  Owner:
 Type:  defect   | Status:
 Priority:  Immediate|  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Critical |  0.2.7.x-final
 Keywords:  TorCoreTeam201605 regression |Version:
  review-group-1 | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 lgtm; testing.

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

Re: [tor-bugs] #18760 [Core Tor/Tor]: I'd like to customize rejection message from dir auths to relay

[Tor Bug Tracker & Wiki]

#18760: I'd like to customize rejection message from dir auths to relay
--+
 Reporter:  arma  |  Owner:  arma
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:
Parent ID:|  Actual Points:
 Reviewer:  nickm | Points:
  |Sponsor:
--+
Changes (by arma):

 * status:  needs_revision => merge_ready


Comment:

 I used my time machine to include a changes file in the commit that you
 reviewed.

 No backport to 0.2.7 required. In fact, this has a milestone of 0.2.9, so
 I would be fine with no backport to 0.2.8 also.

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

Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Please see my branch bug18816_simplify in which I revert "Switch between
 fallback and authority when auth cert fetch fails", and change the
 comments to confirm that's what we want.

 arma says this is unnecessary complexity, because after #18963, failing to
 fetch certificates only occurs when a connection fails or tor quits after
 a downloading a consensus but before downloading enough certificates, and
 it is a transient issue that will go away with the next successful
 certificate or consensus fetch.

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

Re: [tor-bugs] #16698 [Core Tor/Tor]: Split directory_handle_command_get into per-command functions

[Tor Bug Tracker & Wiki]

#16698: Split directory_handle_command_get into per-command functions
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  028-triaged, tor-tests-coverage, |Version:
  tor-tests-unit, TorCoreTeam201605, review- | Resolution:
  group-1|  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |  small/medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by dgoulet):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
-+-
 Reporter:  special  |  Owner:
 Type:  defect   | Status:
 Priority:  Immediate|  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Critical |  0.2.7.x-final
 Keywords:  TorCoreTeam201605 regression |Version:
  review-group-1 | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:   => TorCoreTeam201605 regression review-group-1


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

Re: [tor-bugs] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
--+
 Reporter:  special   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Immediate |  Milestone:  Tor: 0.2.7.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by special):

 * status:  new => needs_review


Comment:

 See my bug19032-027 branch.

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

Re: [tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  High |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  modularity, tor-modularity,  |Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-
Changes (by dgoulet):

 * 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

[tor-bugs] #19032 [Core Tor/Tor]: Out of bounds write on directory authorities when voting on duplicate ed25519 keys

[Tor Bug Tracker & Wiki]

#19032: Out of bounds write on directory authorities when voting on duplicate
ed25519 keys
--+
 Reporter:  special   |  Owner:
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.2.7.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In dirserv_compute_performance_thresholds, we allocate arrays based on the
 length of 'routers', a list of routerinfo_t, but loop over the nodelist.
 The 'routers' list may be shorter when relays were filtered by
 routers_make_ed_keys_unique, leading to an out-of-bounds write.

 This bug was originally introduced in 26e89742, but it doesn't look
 possible to trigger until routers_make_ed_keys_unique was introduced in
 13a31e72.

 This needs a backport to 0.2.7, but wasn't in a released version. Fix on
 0.2.8.2-alpha.

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

Re: [tor-bugs] #19003 [Core Tor/Tor]: Make sure small networks can bootstrap without exits

[Tor Bug Tracker & Wiki]

#19003: Make sure small networks can bootstrap without exits
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1 regression   |  0.2.8.2-alpha
Parent ID:   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by arma):

 {{{
 + * If need_exit is false, return 0 if we can build internal paths.
 }}}
 Do you mean return 1 here?

 teor: I just pushed a bug19003-try2 branch to my git. It contains this fix
 plus also some refactoring of your other change. If you agree that the
 refactoring doesn't break anything, I think we're all set 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] #18760 [Core Tor/Tor]: I'd like to customize rejection message from dir auths to relay

[Tor Bug Tracker & Wiki]

#18760: I'd like to customize rejection message from dir auths to relay
--+
 Reporter:  arma  |  Owner:  arma
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:
Parent ID:|  Actual Points:
 Reviewer:  nickm | Points:
  |Sponsor:
--+
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #18760 [Core Tor/Tor]: I'd like to customize rejection message from dir auths to relay

[Tor Bug Tracker & Wiki]

#18760: I'd like to customize rejection message from dir auths to relay
--+
 Reporter:  arma  |  Owner:  arma
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
Component:  Core Tor/Tor  |  0.2.9.x-final
 Severity:  Normal|Version:
 Keywords:  029-accepted, review-group-1  | Resolution:
Parent ID:|  Actual Points:
 Reviewer:| Points:
  |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Looks good then. Please get me a changes file, and let me know whether you
 want a backport to 0.2.7.

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

Re: [tor-bugs] #18963 [Core Tor/Tor]: Download authority certificates even under blackholed authorities or fallbacks

[Tor Bug Tracker & Wiki]

#18963: Download authority certificates even under blackholed authorities or
fallbacks
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  029-proposed, review-group-1   |  0.2.8.1-alpha
Parent ID:  #18816   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

 * reviewer:  nickm => arma


Comment:

 I like this, but I want Roger to have a look too if he has a chance.

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

Re: [tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-+-
 Reporter:  str4d|  Owner:  str4d
 Type:  enhancement  | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-|Version:  Tor:
  group-1|  0.2.7.6
Parent ID:   | Resolution:
 Reviewer:  asn  |  Actual Points:
 | Points:  small
 |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * reviewer:  dgoulet => asn


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

Re: [tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  High |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  modularity, tor-modularity,  |Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 >DECLARE/DEFINE change hasn't been changed so I'm assuming the current
 branch needs a revision.

 just did that in 8b75263e35ec5c217525fa67a019852b6b541ffc ; thanks for the
 reminder.

 >Also, the whole need for a subscriber_data_t structure hasn't been
 addressed. I'm fine if you prefer it that way instead of making the caller
 choose whatever it want to pass.

 I think I did this already in ceadd497525120d0f77be7b5755ca5bc7015f326
 though.

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

Re: [tor-bugs] #19028 [Core Tor/Tor]: Merge the header checks in configure.ac

[Tor Bug Tracker & Wiki]

#19028: Merge the header checks in configure.ac
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * keywords:   => 029-proposed
 * milestone:   => Tor: 0.2.???


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

Re: [tor-bugs] #18616 [Core Tor/Tor]: Relay fails to self-test its DirPort with AccountingMax enabled

[Tor Bug Tracker & Wiki]

#18616: Relay fails to self-test its DirPort with AccountingMax enabled
-+-
 Reporter:  toralf   |  Owner:  andrea
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  regression, must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.1-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  20
 Reviewer:  arma |  hours
 | Points:  medium
 |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:  dgoulet, arma => 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] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 Priority:  High |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  modularity, tor-modularity,  |Version:
  TorCoreTeam201605, TorCoreTeam-| Resolution:
  postponed-201604, review-group-1   |  Actual Points:
Parent ID:   | Points:  medium
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorS-can
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 * `DECLARE/DEFINE` change hasn't been changed so I'm assuming the current
 branch needs a revision.

 * Also, the whole need for a `subscriber_data_t` structure hasn't been
 addressed. I'm fine if you prefer it that way instead of making the caller
 choose whatever it want to pass.

 I'm currently happy with the latest commits addressing some issues. I'll
 let cypherpunks here maybe continue his/her 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] #18761 [Core Tor/Tor]: Make logging of rendezvous to private address quieter

[Tor Bug Tracker & Wiki]

#18761: Make logging of rendezvous to private address quieter
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
Component:  Core Tor/Tor |  0.2.8.x-final
 Severity:  Normal   |Version:  Tor:
 Keywords:  must-fix-before-028-rc, tor-hs,  |  0.2.8.2-alpha
  TorCoreTeam201605, TorCoreTeam-| Resolution:  fixed
  postponed-201604, review-group-1   |  Actual Points:  very
Parent ID:   |  small
 Reviewer:  asn  | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Agreed.  Merged. 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

[tor-bugs] #19031 [Applications/TorBirdy]: Audit Thunderbird's RSS support

[Tor Bug Tracker & Wiki]

#19031: Audit Thunderbird's RSS support
---+-
 Reporter:  sukhbir|  Owner:  sukhbir
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Audit Thunderbird's RSS feed reader. Some tasks to start with:

 - Is automatic fetching disabled?
 - Is HTML disabled?
 - Is JavaScript disabled?
 - Are proxy settings respected?

 Are there other anonymity implications?

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

Re: [tor-bugs] #18809 [Core Tor/Tor]: Handle linked connections better during bootstrap

[Tor Bug Tracker & Wiki]

#18809: Handle linked connections better during bootstrap
-+-
 Reporter:  teor |  Owner:  arma
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  TorCoreTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  andrea   |  Actual Points:  medium
 | Points:  medium
 |Sponsor:
 |  SponsorS-can
-+-
Changes (by dgoulet):

 * reviewer:  dgoulet andrea => andrea


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

Re: [tor-bugs] #19003 [Core Tor/Tor]: Make sure small networks can bootstrap without exits

[Tor Bug Tracker & Wiki]

#19003: Make sure small networks can bootstrap without exits
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1 regression   |  0.2.8.2-alpha
Parent ID:   | Resolution:
 Reviewer:  arma |  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

 * keywords:  must-fix-before-028-rc, CoreTorTeam201605, review-group-1 =>
 must-fix-before-028-rc, CoreTorTeam201605, review-group-1 regression


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

Re: [tor-bugs] #18050 [Core Tor/Tor]: Relay submitted a descriptor with 0 DirPort due to a self-test race condition

[Tor Bug Tracker & Wiki]

#18050: Relay submitted a descriptor with 0 DirPort due to a self-test race
condition
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.7.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.10
 Severity:  Normal| Resolution:  fixed
 Keywords:  027-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arma):

 * status:  needs_review => closed
 * keywords:  026-backport, 027-backport => 027-backport
 * resolution:   => fixed
 * milestone:  Tor: 0.2.6.x-final => Tor: 0.2.7.x-final


Comment:

 I vote against backport to 0.2.6 -- mainly because there will likely never
 be another 0.2.6 release, and if there is, approximately nobody will
 update to it.

 I spoke to teor and he agreed that close is fine.

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

Re: [tor-bugs] #14013 [Core Tor/Tor]: base16_decode() API is inconsistent and error-prone

[Tor Bug Tracker & Wiki]

#14013: base16_decode() API is inconsistent and error-prone
---+
 Reporter:  nickm  |  Owner:  nikkolasg
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  lorax, review-group-1  |  Actual Points:
Parent ID: | Points:  small
 Reviewer: |Sponsor:  SponsorS-can
---+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 * `base16_decode()` comment needs to mention that we return the size now
 on success.

 * There is still this line looking for an error instead of `!=` to the
 expected size but all other fixes make that not equal change:

 {{{
 +  base16_decode(guard_id, DIGEST_LEN, inputs_tmp, HEX_DIGEST_LEN) <
 0) {
 }}}

 * About this comment, can you tell us what's the returned value? It seems
 it should be `DIGEST256_LEN` indeed.

 {{{
 +// XXX Should it not be always DIGEST256_LEN ? Running the tests with
 +// the condition ` != DIGEST256_LEN` fails.
 }}}

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

Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:  small
 |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 (I merged bug18816-squashed to maint-0.2.8. More work may be needed
 depending on what they decide.)

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

Re: [tor-bugs] #18816 [Core Tor/Tor]: We still wait 120 seconds for cert fetches from missing dir mirrors

[Tor Bug Tracker & Wiki]

#18816: We still wait 120 seconds for cert fetches from missing dir mirrors
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc,  |Version:  Tor:
  CoreTorTeam201605, review-group-1  |  0.2.8.1-alpha
Parent ID:   | Resolution:
 Reviewer:  nickm|  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by nickm):

 I just merged this under the impression that arma and teor had talked
 about my open question wrt the static variable.  But arma and teor are
 talking about it now.  This might need an additional tweak.

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

Re: [tor-bugs] #18761 [Core Tor/Tor]: Make logging of rendezvous to private address quieter

[Tor Bug Tracker & Wiki]

#18761: Make logging of rendezvous to private address quieter
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 Priority:  Medium   |  merge_ready
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  0.2.8.x-final
 Keywords:  must-fix-before-028-rc, tor-hs,  |Version:  Tor:
  TorCoreTeam201605, TorCoreTeam-|  0.2.8.2-alpha
  postponed-201604, review-group-1   | Resolution:
Parent ID:   |  Actual Points:  very
 Reviewer:  asn  |  small
 | Points:  small
 |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM.

 Might be worth pointing out that this patch will also suppress the
 following log message:
 {{{
 node = node_get_by_nickname(rp_nickname, 0);
 if (!node) {
   if (err_msg_out) {
 tor_asprintf(_msg,
  "Couldn't find router %s named in INTRODUCE2 cell",
  escaped_safe_str_client(rp_nickname));
   }

   goto err;
 }
 }}}

 Are we OK with hiding this from HS operators? I guess yes because it's not
 like they can do anything about it (and it's probably caused by consensus
 desynchronization between client and service).

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

Re: [tor-bugs] #18841 [Core Tor/Tor]: Test test_bt.sh fails

[Tor Bug Tracker & Wiki]

#18841: Test test_bt.sh fails
--+
 Reporter:  trudokal  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major | Resolution:
 Keywords:  test, patch 026-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  test, patch, review-group-1 => test, patch 026-backport
 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.6.x-final


Comment:

 I made a branch `bug18841_1_025` for this so we can backport it as far as
 we want. I'm adding it to 027 and forward, for possible backport to older
 versions.

 I am also leaving this particular ticket open in case there are more
 reasons this happens.

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

Re: [tor-bugs] #17435 [Core Tor/Tor]: Patch dir-spec with the shared randomness info

[Tor Bug Tracker & Wiki]

#17435: Patch dir-spec with the shared randomness info
--+
 Reporter:  asn   |  Owner:  asn
 Type:  defect| Status:
 Priority:  Medium|  needs_revision
Component:  Core Tor/Tor  |  Milestone:  Tor:
 Severity:  Normal|  0.2.9.x-final
 Keywords:  tor-spec, tor-hs, review-group-1  |Version:
Parent ID:  #16943| Resolution:
 Reviewer:|  Actual Points:
  | Points:  small
  |Sponsor:  SponsorR-
  |  can
--+
Changes (by asn):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #18886 [Applications/Tor Browser]: consider removing Pocket

[Tor Bug Tracker & Wiki]

#18886: consider removing Pocket
-+-
 Reporter:  mcs  |  Owner:
 Type:  defect   |  arthuredelstein
 Priority:  Medium   | Status:  reopened
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-
Changes (by arthuredelstein):

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


Comment:

 I could have sworn this was working for me before! The bookmarks menu is
 definitely supposed to disappear. I'm going to reopen it to remind myself
 to figure out what's wrong. That way we can also commit a single good
 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] #17928 [Core Tor/Tor]: Warnings in syslog for wrong permissions on hidden service dir are misleading

[Tor Bug Tracker & Wiki]

#17928: Warnings in syslog for wrong permissions on hidden service dir are
misleading
-+
 Reporter:  throwaway232344  |  Owner:
 Type:  enhancement  | Status:  needs_review
 Priority:  Very Low |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.7.5
 Severity:  Trivial  | Resolution:
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:  small/medium
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by moosehadley):

 * 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #7478, #14013, #17983, #18363, #16698, #16794, #17435, #17799, #18620, #18760, #18815, #18901, #18934, #18956

[Tor Bug Tracker & Wiki]

Batch modification to #7478, #14013, #17983, #18363, #16698, #16794, #17435, 
#17799, #18620, #18760, #18815, #18901, #18934, #18956 by nickm:
keywords to review-group-1

--
Tickets URL: 

Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #17158, #18616, #18761, #18809, #18816, #18841, #18963, #19003

[Tor Bug Tracker & Wiki]

Batch modification to #17158, #18616, #18761, #18809, #18816, #18841, #18963, 
#19003 by nickm:
keywords to review-group-1

--
Tickets URL: 

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

Re: [tor-bugs] #8908 [Core Tor/Tor]: Tor systemd socket activation support

[Tor Bug Tracker & Wiki]

#8908: Tor systemd socket activation support
-+-
 Reporter:  cypherpunks  |  Owner:  intgr
 Type:  enhancement  | Status:
 Priority:  Very Low |  needs_revision
Component:  Core Tor/Tor |  Milestone:  Tor:
 Severity:  Normal   |  unspecified
 Keywords:  tor-relay, systemd, lorax,   |Version:  Tor:
  027-triaged-1-in, 028-triaged, pre028-patch|  0.2.7
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:  small
 |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:23 nickm]:
 > So, these two main questions from above still sit in my mind:
 > > * Does it actually work to only start Tor when Tor receives a
 SocksPort or ControlPort request? When Tor first starts after significant
 downtime, it needs to download a pretty big amount of directory data, and
 build enough circuits for user traffic. Does that happen fast enough to
 answer the request that made systemd launch Tor?
 > > * A Tor is _supposed_ to actually turn itself nearly off when it sees
 no user traffic. Does your need for this feature mean that feature is not
 working?
 >
 > I'm thinking that because of the latter point, it might be a better idea
 to work on #2149 than on this, since #2149 has more general applicability.

 Note that I'm not the OP, just a passer-by.

 For me, systemd socket activation would serve the purpose of on-
 demand/lazy startup, rather than setting up the system to start Tor as
 soon as Internet access has been established. My use-case is a laptop that
 could potentially connect to the Internet from a variety of geographical
 locations and network access routes. This would solve the real or
 perceived privacy or security problem of connecting, or at least
 attempting to connect, to the Tor network at certain times and places, as
 it would only connect to the network when actually used, whether through a
 Tor-enabled web browser or torify or whatever other Tor-using application.
 It could also be a problem for metered bandwidth connections.

 Maybe I'm just misinformed about Tor's startup procedure, or maybe I
 should be using traffic obfuscation features. If these are legitimate
 concerns then they are orthogonal to #2149 (although metered bandwidth
 seems related). Right now it is a minor inconvenience to manually start
 the Tor service prior to launching a Tor-using application.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19030 [Community]: Quickbooks error ((1.(8.8.8)).5.1.3.5.9.7.8))) Quickbooks error s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r Quickbooks error s.u.p.p.o.r.t n.u.m.b.e.r

[Tor Bug Tracker & Wiki]

#19030: Quickbooks error ((1.(8.8.8)).5.1.3.5.9.7.8))) Quickbooks error
s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r Quickbooks error s.u.p.p.o.r.t
n.u.m.b.e.r
+-
 Reporter:  anjilojilo  |  Owner:
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community   |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Quickbooks error ((1.(8.8.8)).5.1.3.5.9.7.8))) Quickbooks error
 s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r Quickbooks error s.u.p.p.o.r.t
 n.u.m.b.e.r
 USA Quickbooks error ((1.(8.8.8)).5.1.3.5.9.7.8))) Quickbooks error
 s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r Quickbooks error s.u.p.p.o.r.t
 n.u.m.b.e.r

 Quickbooks error H.e.l.p.l.i.n.e((1.(8.8.8)).5.1.3.5.9.7.8))) Quickbooks
 error tech s.u.p.p.o.r.t n.u.m.b.e.r Quickbooks error s.u.p.p.o.r.t
 p.h.o.n.e n.u.m.b.e.r

 1-888-513-5978 problems sending and receiving epayroll in Intuit
 Quickbooks error 2010

 Intuit Quickbooks error epayroll technical support number

 branded.me

 USA 1-888-513-5978 Quickbooks error Technical Support Services USA
 Quickbooks error customer support toll free number USA 1-888-513-5978
 Quickbooks error customer service phone numbers USA Quickbooks error
 customer support toll free number 1-888-513-5978 Quickbooks error Customer
 Support USA Quickbooks error customer service phone numbers Quickbooks
 error Customer Service 1-888-513-5978 Quickbooks error Technical Support
 Number msn live Intuit customer support toll free number 1-888-513-5978
 Quickbooks error Customer Service USA Quickbooks error customer service
 phone numbers 1-888-513-5978 Quickbooks error Support Number USA
 Quickbooks error tech support phone msn live customer support phone number
 1-888-513-5978 Quickbooks error tech support chat USA Quickbooks error
 customer support number 1-888-513-5978 Quickbooks error tech support phone
 number contact Quickbooks error customer support USA 1-888-513-5978
 Quickbooks error customer service USA Quickbooks error tech support phone
 number

 1-888-513-5978 problems sending and receiving epayroll in Intuit
 Quickbooks error 2010

 Intuit Quickbooks error epayroll technical support number

 branded.me

 1-888-513-5978 Quickbooks error customer service phone number Quickbooks
 customer support phone number 1-888-513-5978 Quickbooks error customer
 support chat Intuit live customer support 1-888-513-5978 msn live customer
 support Quickbooks error tech support phone number 1-888-513-5978 contact
 Quickbooks error customer support USA msn live customer support phone
 number 1-888-513-5978 contact Quickbooks error live customer support phone
 number 1-888-513-5978 Quickbooks error Quickbooks error toll free number
 USA msn live customer support phone number Quickbooks error Technical
 Support Services 1-888-513-5978 Quickbooks error tech support phone number
 USA Quickbooks error Technical Support Services Quickbooks error customer
 support toll free number 1-888-513-5978 Quickbooks error Technical Support
 Services USA msn live customer support phone number1-888-513-5978
 Quickbooks error technical support phone number USA msn live customer
 support phone number 1-888-513-5978 Quickbooks error password recovery
 phone support USA Quickbooks error tech support phone number USA
 Quickbooks error Technical Support Services 1-888-513-5978 contact
 Quickbooks error technical support phone number USA msn live customer
 support phone number 1-888-513-5978 Quickbooks error technical support
 live chat Quickbooks error tech support phone number USA 1-888-513-5978
 Quickbooks error customer support toll free number USA msn live customer
 support phone number 1-888-513-5978 Quickbooks error help number contact
 USAh
 
_Quickbooks_error_s.u.p.p.o.r.t_n.u.m.b.e.r_Quickbooks_error_s.u.p.p.o.r.t_p.h.o.n.e_n.u.m.b.e.r
 live customer support phone number 1-888-513-5978 Quickbooks error
 helpline phone number USA Quickbooks error tech support phone Quickbooks
 error support 1-888-513-5978msn live customer support phone number USA
 Quickbooks error customer support toll free number 1-888-513-5978
 Quickbooks error Quickbooks error customer support number USA msn live
 customer support phone number 1-888-513-5978 create new epayroll
 Quickbooks error Live Quickbooks error account USA new Quickbooks error
 epayroll address USA 1-888-513-5978 create new epayroll Intuit Quickbooks
 error epayroll technical support number

 Intuit Quickbooks error epayroll technical support number

 Intuit office Quickbooks error payroll support phone number

 Intuit office Quickbooks error payroll support phone number

 Intuit Quickbooks error payroll 2007 support number

 Intuit Quickbooks error payroll 2007 support number

 Intuit Quickbooks error payroll 2010 support phone number

 Intuit Quickbooks error 

[tor-bugs] #19029 [Community]: Witty%*! (1*888*513*5978 )~// Quicken (pro) T.e.c.h s.u.p.p.o.r.t number, // Quicken pro s.u.p.p.o.r.t number, // Quicken C.u.s.t.o.m.e.r s.e.r..v.i.c.e number

[Tor Bug Tracker & Wiki]

#19029: Witty%*! (1*888*513*5978 )~// Quicken (pro) T.e.c.h s.u.p.p.o.r.t 
number,
// Quicken pro s.u.p.p.o.r.t number, // Quicken C.u.s.t.o.m.e.r
s.e.r..v.i.c.e number
+-
 Reporter:  anjilojilo  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community   |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Help USA@.1 (888) 513.5978: // Quicken pro s.u.p.p.o.r.t p.h.o..n.e
 number QB Witty%*! (1*888*513*5978 )~// Quicken (pro) T.e.c.h
 s.u.p.p.o.r.t number, // Quicken pro s.u.p.p.o.r.t number, // Quicken
 C.u.s.t.o.m.e.r s.e.r..v.i.c.e number USA H.e.l.p..l.i.n.e T.e.c.h
 ))1-888-513-5978((// Quicken pro T.e.c.hnical s.u.p.p.o.r.t p.h.o..n.e
 number // Quicken pro p.h.o..n.e number QB s.u.p.p.o.r.t ON ((1-888-513-
 5978)) // Quicken p.h.o..n.e NUMBER AND // Quicken s.u.p.p.o.r.t
 p.h.o..n.e NUMBER // Quicken Toll Free, Intuit@(1-888-513- 5978)@ //
 Quicken T.e.c.h s.u.p.p.o.r.t p.h.o..n.e Number provides online solution
 for all USA/CANADA clients. For any help of query call 1 888 513 5978 to
 get all // Quicken account solution. @@Call, 1-888-513-5978 for all type
 help by // Quicken T.e.c.h s.u.p.p.o.r.t p.h.o..n.e number, Intuit //
 Quicken T.e.c.h s.u.p.p.o.r.t p.h.o..n.e Number, // Quicken H.e.l..p
 D.e..s.k p.h.o..n.e Number, // Quicken T.e.c.h s.u.p.p.o.r.t number, //
 Quicken T.e.c.hnical s.u.p.p.o.r.t p.h.o..n.e number,@@@ // Quicken
 p.h.o..n.e number, // Quicken T.e.c.hnical s.u.p.p.o.r.t number, //
 Quicken s.u.p.p.o.r.t p.h.o..n.e number, // Quicken T.e.c.hnical
 s.u.p.p.o.r.t, // Quicken C.u.s.t.o.m.e.r s.e.r..v.i.c.e p.h.o..n.e
 Number, // Quicken C.u.s.t.o.m.e.r s.e.r..v.i.c.e Number, // Quicken
 C.u.s.t.o.m.e.r s.u.p.p.o.r.t p.h.o..n.e Number, // Quicken
 C.u.s.t.o.m.e.r s.u.p.p.o.r.t Number, // Quicken C.u.s.t.o.m.e.r
 s.e.r..v.i.c.e H.e.l.p..l.i.n.e Number, // Quicken C.u.s.t.o.m.e.r Care
 Number, // Quicken s.u.p.p.o.r.t team p.h.o..n.e number, @ // Quicken
 help number-// Quicken H.e.l.p..l.i.n.e Number;// Quicken help p.h.o..n.e
 number// Quicken H.e.l.p..l.i.n.e Number, // Quicken T.e.c.h s.u.p.p.o.r.t
 Toll free Number, // Quicken s.u.p.p.o.r.t Telep.h.o..n.e Number,//
 Quicken T.e.c.h s.u.p.p.o.r.t Telep.h.o..n.e number, // Quicken T.e.c.h
 s.u.p.p.o.r.t contact number, // Quicken s.u.p.p.o.r.t contact number, //
 Quicken T.e.c.hnical s.u.p.p.o.r.t contact number. Call, // Quicken
 T.e.c.h s.u.p.p.o.r.t p.h.o..n.e number, Intuit // Quicken T.e.c.h
 s.u.p.p.o.r.t p.h.o..n.e Number, // Quicken H.e.l..p D.e..s.k p.h.o..n.e
 Number,// Quicken T.e.c.h s.u.p.p.o.r.t number, // Quicken T.e.c.hnical
 s.u.p.p.o.r.t p.h.o..n.e number, // Quicken p.h.o..n.e number, // Quicken
 T.e.c.hnical s.u.p.p.o.r.t number, // Quickens.u.p.p.o.r.t p.h.o..n.e
 number. It is very popular toll free number which provide by // Quicken
 T.e.c.hnical s.u.p.p.o.r.t, // Quicken C.u.s.t.o.m.e.r s.e.r..v.i.c.e
 p.h.o..n.e Number,// Quicken C.u.s.t.o.m.e.r s.e.r..v.i.c.e Number, //
 Quicken C.u.s.t.o.m.e.r s.u.p.p.o.r.t p.h.o..n.e Number, // Quicken
 C.u.s.t.o.m.e.r s.u.p.p.o.r.t Number, // Quicken C.u.s.t.o.m.e.r
 s.e.r..v.i.c.e H.e.l.p..l.i.n.e Number, // Quicken C.u.s.t.o.m.e.r Care
 Number, // Quicken s.u.p.p.o.r.t team p.h.o..n.e number. Call, // Quicken
 T.e.c.h s.u.p.p.o.r.t p.h.o..n.e number, Intuit// Quicken T.e.c.h
 s.u.p.p.o.r.t p.h.o..n.e Number, // Quicken H.e.l..p D.e..s.k p.h.o..n.e
 Number, // Quicken T.e.c.h s.u.p.p.o.r.t number, // Quicken T.e.c.hnical
 s.u.p.p.o.r.t p.h.o..n.e number, // Quicken p.h.o..n.e number, // Quicken
 T.e.c.hnical s.u.p.p.o.r.t number, // Quicken s.u.p.p.o.r.t p.h.o..n.e
 number, // Quicken T.e.c.hnical s.u.p.p.o.r.t, // QuickenC.u.s.t.o.m.e.r
 s.e.r..v.i.c.e p.h.o..n.e Number, // Quicken C.u.s.t.o.m.e.r
 s.e.r..v.i.c.e Number, // Quicken C.u.s.t.o.m.e.r s.u.p.p.o.r.t p.h.o..n.e
 Number, // Quicken C.u.s.t.o.m.e.r s.u.p.p.o.r.t Number, // Quicken
 C.u.s.t.o.m.e.r s.e.r..v.i.c.e H.e.l.p..l.i.n.e Number, // Quicken
 C.u.s.t.o.m.e.r Care Number, // Quicken s.u.p.p.o.r.t team p.h.o..n.e
 number, // Quicken help number-// Quicken H.e.l.p..l.i.n.e Number; //
 Quicken help p.h.o..n.e number, // Quicken H.e.l.p..l.i.n.e Number, //
 Quicken T.e.c.h s.u.p.p.o.r.t Toll free Number, // Quickens.u.p.p.o.r.t
 Telep.h.o..n.e Number, // Quicken T.e.c.h s.u.p.p.o.r.t Telep.h.o..n.e
 number, // Quicken T.e.c.h s.u.p.p.o.r.t contact number, // Quicken
 s.u.p.p.o.r.t contact number,// Quicken T.e.c.hnical s.u.p.p.o.r.t contact
 number, // Quicken pro s.u.p.p.o.r.t p.h.o..n.e number, // Quicken pro
 s.u.p.p.o.r.t p.h.o..n.e number. // Quicken pro C.u.s.t.o.m.e.r
 s.u.p.p.o.r.t p.h.o..n.e number 1888-513-5978 // Quicken T.e.c.hnical help
 telep.h.o..n.e number, // Quicken T.e.c.hnical help contact 

Re: [tor-bugs] #18976 [Applications/Tor Browser]: Remove some FTE bridges

[Tor Bug Tracker & Wiki]

#18976: Remove some FTE bridges
--+--
 Reporter:  kpdyer|  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201605R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by kpdyer):

 Looks good. 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] #18922 [Metrics/CollecTor]: configure logging via properties file

[Tor Bug Tracker & Wiki]

#18922: configure logging via properties file
---+--
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip operation |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [comment:4 karsten]:
 > Few questions before merging:
 >  - Can we have separate log files for each module?  These modules may be
 executed concurrently, and using a single log file might cause problems
 and also make the log file less readable.
 Yes. The way to have different log-files is hidden in a comment in run-
 all:
 {{{
 # this would use a special log config for each module
 # java -Xmx2g
 -Djava.util.logging.config.file=./bin/logging.$TOKEN.properties -jar
 collector-0.9.0-dev.jar $TOKEN
 }}}
 This makes each module use different logging properties, i.e.
 `logging.relaydescs.properties` for relaydescs,
 `logging.bridgedescs.properties` for bridgedescs, etc.
 These logging properties can just be a copy of `logging.properties` each
 with a different entry for the log file name, but of course also other
 differences (level or excluded packages ...)

 >  - Can we merge `bin/logging-properties` with the new config file, or
 would that confuse the Java Logging API?  What about future logging
 frameworks we're going to switch to?
 Well, if I understand the question correctly: that I would have to try in
 order to give a definite answer. Usually java util logging ignores what it
 doesn't understand, but I would not rely on that.

 Logging should be separated from the runtime configuration. And, because
 of the upcoming change of logging frameworks I wouldn't want to merge the
 logging properties with other configuration.

 For a switch to slf4j and logback, for example, we would remove all java
 util logging properties and have an XML logging config like for Onionoo.
 In that case, just one file for all the different modules and logging
 purposes (i.e. monitoring, diagnostics, and statistics).

 >  - Would you want to remove the five files `bin/run-*` and only keep the
 new `bin/run-all` that accepts a module name as parameter?  Or is that a
 change we should postpone?
 Well, I intended to make things backward compatible by keeping the old
 shell scripts. So the crontab entries don't need to be touched.
 And, currently run-all expects the old shell-script name (incl. the `run-`
 part) and extracts the module name (see variable `TOKEN`).

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

Re: [tor-bugs] #18955 [Metrics/CollecTor]: javadoc coverage

[Tor Bug Tracker & Wiki]

#18955: javadoc coverage
---+
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Okay, want to split the checks file and add another Ant task?  I guess we
 can always reverse that change later and go back to a single checks file
 when our javadocs are in better shape and we're optimistic that they'll
 stay that way.  (The advantage of making as few changes as possible to the
 checks file is that it'll be easier to update to a newer version.)

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

Re: [tor-bugs] #18958 [Applications/Tor Browser]: screen.orientation should lie

[Tor Bug Tracker & Wiki]

#18958: screen.orientation should lie
-+-
 Reporter:  mcs  |  Owner:
 Type:  defect   |  arthuredelstein
 Priority:  Medium   | Status:
Component:  Applications/Tor Browser |  needs_review
 Severity:  Normal   |  Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201605R  |Version:
Parent ID:   | Resolution:
 Reviewer:   |  Actual Points:
 | Points:
 |Sponsor:
-+-

Comment (by mcs):

 r=mcs, r=brade
 These changes look good. Should we also skip dispatching of the
 orientation change events when ShouldResistFingerprinting() returns true?
 Generating the events will allow a website to detect that my device can
 change orientation.

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

Re: [tor-bugs] #19016 [Metrics/CollecTor]: add shutdown hook

[Tor Bug Tracker & Wiki]

#19016: add shutdown hook
---+---
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by karsten):

 Oh wow, that's actually a tough question.  And I think the answer depends
 on how modules are started (cron vs. internal scheduler), how that
 scheduler is started (cron vs. service script) and stopped (kill vs.
 service script), and so on.  For example, I could imagine using a shutdown
 hook to release a lock file, but it might be that we don't need a lock
 file anymore once we switch to a service script.

 One thing about reasons for shutdown: I don't think we can do anything
 useful in case of a corrupt or full disk.  We should probably focus on
 system maintenance here.  And doing that would be great, because then our
 sysadmins could simply install updates and reboot hosts whenever they need
 to.

 How about we postpone this discussion until those other changes are
 implemented?  I think we can do some good things with shutdown hooks, so I
 don't suggest closing this issue.  But I think I can contribute more to
 this discussion in a month or two.

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

Re: [tor-bugs] #18976 [Applications/Tor Browser]: Remove some FTE bridges

[Tor Bug Tracker & Wiki]

#18976: Remove some FTE bridges
--+--
 Reporter:  kpdyer|  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201605R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 r=mcs, r=brade
 Looks good.

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

Re: [tor-bugs] #18743 [Applications/Tor Browser]: "Sign in to Sync" icon not hidden in ESR45-based Tor Browser

[Tor Bug Tracker & Wiki]

#18743: "Sign in to Sync" icon not hidden in ESR45-based Tor Browser
-+-
 Reporter:  mcs  |  Owner:  tbb-team
 Type:  defect   | Status:
 Priority:  Medium   |  needs_review
Component:  Applications/Tor Browser |  Milestone:
 Severity:  Normal   |Version:
 Keywords:  ff45-esr, TorBrowserTeam201605R  | Resolution:
Parent ID:   |  Actual Points:
 Reviewer:   | Points:
 |Sponsor:
-+-

Comment (by mcs):

 Replying to [comment:4 gk]:
 > Looks good to me. One nit: could you wrap that long line in
 `torbutton_update_sync_ui()`? It would make it a bit easier to read in my
 terminal.

 Maybe also add a try/catch in that function or check that the
 getElementById() succeeds. That way a failure there due to future Firefox
 changes won't break other Torbutton features such as the circuit display.

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