Re: [tor-bugs] #29523 [Metrics/Website]: advertised bandwidth graph is broken

[Tor Bug Tracker & Wiki]

#29523: advertised bandwidth graph is broken
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 I didn't fully understand the suggestions above yet, but also see #29330
 for a somewhat related 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] #29299 [Core Tor/sbws]: Include scanner country and Web server country in the bandwidth file header

[Tor Bug Tracker & Wiki]

#29299: Include scanner country and Web server country in the bandwidth file 
header
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  catalyst   |Sponsor:
---+---

Comment (by juga):

 I added two fixups just to replace `destinations_country` to
 `destinations_countries`, since i think the later makes it clearer that
 there can be several.
 I also replaced in the test `00, DE` (with space) to `00,DE` (without
 space), since they list of countries is generated without space.

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

Re: [tor-bugs] #29518 [Applications/Tor Browser]: general.useragent.override

[Tor Bug Tracker & Wiki]

#29518: general.useragent.override
--+---
 Reporter:  sj2001010 |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

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


Comment:

 Replying to [comment:2 sysrqb]:
 > You are running Tor Browser on Windows, and the Javascript code
 (navigator.userAgent) is showing an "X11; Linux x86_64" user agent string?

 Maybe running on Linux, but setting a Windows useragent with
 `general.useragent.override`? The pref `general.useragent.override` is
 ignored when `privacy.resistFingerprinting` is set, since #26146. And we
 have #28290 for the headers not matching the javascript useragent, so I'm
 closing this ticket as a duplicate. Please reopen if that is a different
 issue.

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

Re: [tor-bugs] #28290 [Applications/Tor Browser]: Don't allow fingerprinting via navigator.userAgent

[Tor Bug Tracker & Wiki]

#28290: Don't allow fingerprinting via navigator.userAgent
--+--
 Reporter:  indigotime|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-os |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: sj2001010 (added)


Comment:

 #29518 is a duplicate.

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

[tor-bugs] #29556 [Applications/Quality Assurance and Testing]: Fix nightly builds and testsuite emails

[Tor Bug Tracker & Wiki]

#29556: Fix nightly builds and testsuite emails
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We were receiving emails everyday about the status of nightly build and
 testsuite runs, however this stopped working.

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

Re: [tor-bugs] #29391 [Core Tor/Tor]: Put git branch-maintenance scripts into scripts directory

[Tor Bug Tracker & Wiki]

#29391: Put git branch-maintenance scripts into scripts directory
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Low   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  040-can   |  Actual Points:  0
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 LGTM now.  Either right before or after merge, we should add 0.4.0.
 Shortly after that, we should remove 0.3.3.

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

Re: [tor-bugs] #29018 [Core Tor/Tor]: Make all statistics depend on ExtraInfoStatistics

[Tor Bug Tracker & Wiki]

#29018: Make all statistics depend on ExtraInfoStatistics
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, security-low,  |  Actual Points:  2
  040-deferred-20190220, privcount   |
Parent ID:   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This seems okay for 0.4.0. I'm not 100% sure on backporting any farther,
 but I wouldn't object much.

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

Re: [tor-bugs] #29018 [Core Tor/Tor]: Make all statistics depend on ExtraInfoStatistics

[Tor Bug Tracker & Wiki]

#29018: Make all statistics depend on ExtraInfoStatistics
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, security-low,  |  Actual Points:  2
  040-deferred-20190220, privcount   |
Parent ID:   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * status:  merge_ready => needs_review


Comment:

 Replying to [comment:12 nickm]:
 > This seems okay for 0.4.0. I'm not 100% sure on backporting any farther,
 but I wouldn't object much.

 Oops, I meant to say that on another 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] #29017 [Core Tor/Tor]: PaddingStatistics should be disabled when ExtraInfoStatistics is 0

[Tor Bug Tracker & Wiki]

#29017: PaddingStatistics should be disabled when ExtraInfoStatistics is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 035-backport,  |  Actual Points:  1.3
  034-backport, 033-backport, postfreeze-ok, |
  040-can|
Parent ID:   | Points:  0.2
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This seems okay for 0.4.0. I'm not 100% sure on backporting any farther,
 but I wouldn't object much.

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
-+-
 Reporter:  tom  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, easy, intro,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24403   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Hi!  I'd suggest that instead of overriding the last_reachable6 flag in
 node, we should override the place where we assign the ipv6_addr in the
 routerstatus:
 {{{
   if (options->AuthDirHasIPv6Connectivity == 1 &&
   !tor_addr_is_null(&ri->ipv6_addr) &&
   node->last_reachable6 >= now - REACHABLE_TIMEOUT) {
 /* We're configured as having IPv6 connectivity. There's an IPv6
OR port and it's reachable so copy it to the routerstatus.  */
 tor_addr_copy(&rs->ipv6_addr, &ri->ipv6_addr);
 rs->ipv6_orport = ri->ipv6_orport;
 }}}

 (in set_routerstatus_from_routerinfo())

 Instead of checking whether last_reachable6 is recent, we could check
 whether it is recent OR the router is ourself.

 Note that I think this change will make the test expression above way too
 complicated, and we should extract it into its own function, maybe called
 something like should_publish_node_ipv6().

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

Re: [tor-bugs] #29556 [Applications/Quality Assurance and Testing]: Fix nightly builds and testsuite emails

[Tor Bug Tracker & Wiki]

#29556: Fix nightly builds and testsuite emails
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This is fixed by commit abcc56a2ebf32a4ceeea2554b5dea3ab1f6d2fd0.

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

Re: [tor-bugs] #29476 [Webpages/Website]: Add RecommendedTBBVersions to the new website

[Tor Bug Tracker & Wiki]

#29476: Add RecommendedTBBVersions to the new website
--+
 Reporter:  boklm |  Owner:  hiro
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

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


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

Re: [tor-bugs] #27210 [Applications/Tor Browser]: TBA - Support i386 target

[Tor Bug Tracker & Wiki]

#27210: TBA - Support i386 target
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, TBA-a3, |  Actual Points:
  TorBrowserTeam201902, GeorgKoppen201902|
Parent ID:  #5709| Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by boklm):

 * keywords:  tbb-mobile, tbb-rbm, TBA-a3, TorBrowserTeam201902R,
 GeorgKoppen201902 => tbb-mobile, tbb-rbm, TBA-a3,
 TorBrowserTeam201902, GeorgKoppen201902
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:11 gk]:
 > Alright. `bug_27210_v2` (https://gitweb.torproject.org/user/gk/tor-
 browser-
 build.git/commit/?h=bug_27210_v2&id=de71da3ce100983cbd20f4a7ce2c0d37492e2669)
 has the patch for review.

 * in projects/android-toolchain/build, I am wondering if instead of
 installing just the architecture we need, we could install all
 architectures we support, and share the toolchain between all the
 architectures. This would save some space on the disk, but maybe also slow
 down a little the build as we would be extracting archs we don't need. The
 extracted android-toolchain archive is currently 4.8G, of which 985M is
 the arm directory.
 * in projects/rust/build, the patch 0001-Make-sure-dl_iterate_phdr-is-
 undefined-on-Android.patch is applied twice for the android-armv7 build.

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

Re: [tor-bugs] #29432 [Core Tor/Tor]: QuotedString and CString in control-spec.txt technically require escaping ascii 32 (space)

[Tor Bug Tracker & Wiki]

#29432: QuotedString and CString in control-spec.txt technically require 
escaping
ascii 32 (space)
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec 041-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * keywords:  tor-spec => tor-spec 041-proposed


Comment:

 I'd be happy to take a patch here; would anybody like to write one?

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

Re: [tor-bugs] #29432 [Core Tor/Tor]: QuotedString and CString in control-spec.txt technically require escaping ascii 32 (space)

[Tor Bug Tracker & Wiki]

#29432: QuotedString and CString in control-spec.txt technically require 
escaping
ascii 32 (space)
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec 041-proposed  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 (I agree that a spec patch is the correct fix 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] #29549 [Core Tor/Tor]: How can we close obsolete GitHub pull requests?

[Tor Bug Tracker & Wiki]

#29549: How can we close obsolete GitHub pull requests?
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Current practice: I try to remember to close pull requests when I merge
 some different variant of them (e.g. cherry-picked or rebased).  But
 sometimes I forget.  Once in a while, I have been going through the pull
 requests and closing the merged ones manually -- but I haven't done that
 in a couple of months, I think.

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

Re: [tor-bugs] #29536 [Core Tor/Tor]: prng: Add a global fast PRNG object

[Tor Bug Tracker & Wiki]

#29536: prng: Add a global fast PRNG object
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-relay, prng, prop289  |  Actual Points:  .1
Parent ID:  #26288| Points:  0.1
 Reviewer:  dgoulet   |Sponsor:  SponsorV
--+
Changes (by asn):

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


Comment:

 Merged to master!

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

Re: [tor-bugs] #27854 [Core Tor/Tor]: Integration test(s) for tor-resolve

[Tor Bug Tracker & Wiki]

#27854: Integration test(s) for tor-resolve
---+---
 Reporter:  rl1987 |  Owner:  rl1987
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  CollecTor 1.7.0
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  socks tor-resolve testing  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---

Comment (by rl1987):

 Also, do you happen to be compiling with clang on Linux?

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

Re: [tor-bugs] #27854 [Core Tor/Tor]: Integration test(s) for tor-resolve

[Tor Bug Tracker & Wiki]

#27854: Integration test(s) for tor-resolve
---+---
 Reporter:  rl1987 |  Owner:  rl1987
 Type:  enhancement| Status:  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.1.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  socks tor-resolve testing  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by nickm):

 * milestone:  CollecTor 1.7.0 => Tor: 0.4.1.x-final


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

Re: [tor-bugs] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29259 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by ahf):

 * parent:   => #29259


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

Re: [tor-bugs] #29532 [Core Tor/Tor]: Update pre-push hook so that only maint-* and release-* can get pushed to origin.

[Tor Bug Tracker & Wiki]

#29532: Update pre-push hook so that only maint-* and release-* can get pushed 
to
origin.
--+
 Reporter:  nickm |  Owner:  rl1987
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by rl1987):

 * 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] #29149 [Core Tor/sbws]: Update/improve documentation on how the scanner/generator work

[Tor Bug Tracker & Wiki]

#29149: Update/improve documentation on how the scanner/generator work
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:
---+---
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM! That's great documentation.

 Perhaps you can also squash some of the commits together so that the
 history is simpler.

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

Re: [tor-bugs] #29166 [Metrics/Statistics]: Run modules from Java only

[Tor Bug Tracker & Wiki]

#29166: Run modules from Java only
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Ok, checks and tests pass, I've not actually run the code but I did look
 over it before Brussels in more detail and it looked good then. I don't
 see any reason to delay this deployment (except don't do it 5pm Friday
 because weekend).

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

Re: [tor-bugs] #29330 [Metrics/Website]: Do something with advertised bandwidth distribution graphs

[Tor Bug Tracker & Wiki]

#29330: Do something with advertised bandwidth distribution graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by irl):

 * status:  needs_review => new


Comment:

 Switching to consensus weight is a good compromise where the alternative
 is removing the graphs. I don't think we need both percentiles and n-th
 fastest. Drop the n-th fastest and just have percentiles. Can we do 100,
 99, 98, 95, 75, 50, 25, 3, 2, 1, 0? These don't need to be configurable,
 just fixed is OK.

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

Re: [tor-bugs] #28465 [Core Tor/Tor]: Use or remove "package" lines from votes

[Tor Bug Tracker & Wiki]

#28465: Use or remove "package" lines from votes
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 wouldn't it make more sense to start using this feature instead of
 removing it?

 the proposal says:

 >I propose modifying the Tor consensus document to remove
 >digests of the latest versions of one or more package files, to
 >prevent software using Tor from determining its up-to-dateness, and
 >to hinder users wanting to verify that they are getting the correct
 >software.

 why would you want to hinder users wanting to verify that they are getting
 the correct software?!

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

Re: [tor-bugs] #29425 [Metrics/Statistics]: Write integration tests for data-processing modules

[Tor Bug Tracker & Wiki]

#29425: Write integration tests for data-processing modules
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Statistics   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:  irl  |Sponsor:
-+
Changes (by irl):

 * status:  needs_review => needs_revision


Comment:

 git-annex is what I have used in the past for storing large test data in
 git repositories. Our git server does not currently support this but we
 could look at adding support. If it requires us to upgrade the gitolite
 then that is not an easy project, if we are running a new enough version
 then it could just be some lines in the config.

 I looked at running the script:

 {{{
 Cloning metrics-web Git repository into metrics-web/ subdirectory...
 Cloning into 'metrics-web'...
 remote: Counting objects: 14553, done.
 remote: Compressing objects: 100% (1213/1213), done.
 remote: Total 14553 (delta 977), reused 503 (delta 233)
 Receiving objects: 100% (14553/14553), 16.55 MiB | 2.64 MiB/s, done.
 Resolving deltas: 100% (8303/8303), done.
 Bootstrapping development environment...
 Submodule 'src/build' (https://git.torproject.org/metrics-base.git)
 registered for path 'src/build'
 Submodule 'src/submods/metrics-lib' (https://git.torproject.org/metrics-
 lib.git) registered for path 'src/submods/metrics-lib'
 Cloning into '/tmp/metrics-web-integ-tests/metrics-web/src/build'...
 Cloning into '/tmp/metrics-web-integ-tests/metrics-web/src/submods
 /metrics-lib'...
 Submodule path 'src/build': checked out
 'e639c697e9e94c6dbb26e946e5247c20a62c0661'
 Submodule path 'src/submods/metrics-lib': checked out
 '23927c2777f273c42ad3e75fc0a2940ed8eb4bf6'
 Submodule 'src/build' (https://git.torproject.org/metrics-base) registered
 for path 'src/build'
 Cloning into '/tmp/metrics-web-integ-tests/metrics-web/src/submods
 /metrics-lib/src/build'...
 Submodule path 'src/build': checked out
 'e639c697e9e94c6dbb26e946e5247c20a62c0661'
 Replacing absolute paths in build.xml with relative paths...
 sed: can't read s/.srv.metrics.torproject.org.metrics/./: No such file or
 directory
 }}}

 I like the concept though. This is the sort of thing we can run in CI or
 Vagrant to be able to run it in disposable environments.

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

Re: [tor-bugs] #25574 [Core Tor/Tor]: Eliminate "silent-drop" side channels in Tor protocol

[Tor Bug Tracker & Wiki]

#25574: Eliminate "silent-drop" side channels in Tor protocol
---+--
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  10-30
 Reviewer: |Sponsor:  SponsorV-can
---+--

Comment (by cypherpunks):

 there are lots of ways to do it, but the dropmark paper says:

 > We used relay drop cells because they do not raise any log message.


 why is that?

 i found some history:

 Once-upon-a-time DROP cells **were** getting logged. Roger `//`'ed it out
 in '06 cause it was "loud":
 
https://gitweb.torproject.org/tor.git/commit/?id=9bc8d69dfc4ddda5a9c8478b1f1e04490845ded0

 (:thinkingface: how was that "loud"? was anything besides attackers
 sending DROP cells in 2006?)

 mikeperry replaced the `//`'ed log line with `return 0` in 2018:
 
https://gitweb.torproject.org/tor.git/commit/?id=7be71903daff042e606e7a8445a6359100c9f8f5

 But even if tor had no silent drops relays could still embed timing
 signals like Jann Horn demonstrates here:
 https://var.thejh.net/git/?p=detour.git;a=blob;f=README (what ticket
 number is that?)

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

Re: [tor-bugs] #29555 [- Select a component]: Tor unexpectedly exited. this may be do to a Tor Bug, etc

[Tor Bug Tracker & Wiki]

#29555: Tor unexpectedly exited. this may be do to a Tor Bug, etc
--+--
 Reporter:  FMCfmc|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  exited|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by FMCfmc):

 * Attachment "Capture.PNG" added.

 screen shot

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #28692, #28866, #28897, #29294, ...

[Tor Bug Tracker & Wiki]

Batch modification to #28692, #28866, #28897, #29294, #29299 by juga:


Comment:
Merged in a branch with current master and current `needs_review` tickets and 
tested a whole loop with the public Tor network

--
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] #28465 [Core Tor/Tor]: Use or remove "package" lines from votes

[Tor Bug Tracker & Wiki]

#28465: Use or remove "package" lines from votes
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Replying to [comment:6 cypherpunks]:
 > wouldn't it make more sense to start using this feature instead of
 removing it?
 >
 > why would you want to hinder users wanting to verify that they are
 getting the correct software?!

 These are excellent questions!

 I have rewritten the abstract in my latest update to make the reasoning
 clearer, but both abstracts are true and correct.

 There have been many years now to start using this feature and it's just
 not happened. Perhaps writing this proposal threatening its removal will
 bring someone out that has had a plan all along and not yet implemented
 it. Perhaps the problems it was intended to solve are already solved in
 other ways and this is some housekeeping that got forgotten.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29557 [Internal Services/Tor Sysadmin Team]: Please create alias resea...@torproject.org

[Tor Bug Tracker & Wiki]

#29557: Please create alias resea...@torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This should go to {mikeperry,irl,chelsea,asn}@torproject.org for now. It
 will be used for incoming requests to those looking after the researchers
 mailing list and portal.

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

Re: [tor-bugs] #29555 [- Select a component]: Tor unexpectedly exited. this may be do to a Tor Bug, etc

[Tor Bug Tracker & Wiki]

#29555: Tor unexpectedly exited. this may be do to a Tor Bug, etc
--+--
 Reporter:  FMCfmc|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  exited|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 See #28943

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
-+-
 Reporter:  tom  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, easy, intro,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24403   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by neel):

 * status:  needs_revision => needs_review


Comment:

 I made the changes and pushed them.

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

Re: [tor-bugs] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  Actual Points:  2
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  8
 Reviewer:  cohosh, arma |Sponsor:
 |  Sponsor19
-+-

Comment (by cohosh):

 Looking good! Here's some comments:

 === Dependencies
 - Let's keep track in the documentation of the current required version of
 Go needed to build the broker. This could be put in the Go Dependencies
 section.


 === Source code documentation
 - I think one of the goals of this documentation should also be for
 someone to be able to look at it and then implement their own client and
 proxies that can interface with the broker without having to look at the
 existing client and proxy code. As such, we can be more precise about how
 to use each of these handlers. More specifically, does the client/proxy
 make a GET or a POST request when interacting with the handlers, and are
 there any request headers that are necessary? For example: the
 '''/proxy''' handler expects the {{{X-Session-ID}}} header, and is
 implemented in proxy-go as a {{{POST}}} request with no body.

 - Maybe we should mention that the timeout is currently 10s?

 - We could have another section for command line arguments:
 {{{
 Usage of ./broker:
   -acme-email string
 optional contact email for Let's Encrypt notifications
   -acme-hostnames string
 comma-separated hostnames for TLS certificate
   -addr string
 address to listen on (default ":443")
   -disable-tls
 don't use HTTPS
 }}}

 - In the '''/answer handler''' section, it says {{{If the client was too
 slow to send its offer}}} but it should be if the *snowflake proxy* is too
 slow.

 - Also in '''/answer handler''': We might want to expand on what "bogus
 answer" means here. I think it's simply if ioutil.ReadAll failed. I don't
 think there's any sort of mediation or sanitization of the actual Session
 Descriptor Answer.

 - Was the question about crawling ever answered? I can't think of a very
 good reason not to allow it. Even if censors were crawling the web for
 Snowflake brokers, they could get this information much more easily just
 from the source code. I think because of domain fronting we do not need to
 keep broker locations a secret. Perhaps if we are later doing something
 more sneaky with partitioning snowflakes and distributing them with
 something like Salmon or Hyphae we need to be careful about a crawler
 possibly gaining access to that information. In any case, my understanding
 of robots.txt is that is suggests to web crawlers not to crawl but doesn't
 have any actual security guarantees. So maybe we do not care one way or
 the other.

 === Metrics
 - Let's give the units for the round trip estimate. We might even want to
 add this to the debug output.

 === Other notes

 I fixed some minor typos here: https://github.com/ahf/snowflake-
 notes/commit/fb4304a7df08c6ddeeb103f38fc9103721a20cd9

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

Re: [tor-bugs] #29065 [Core Tor/Tor]: shellcheck: test_switch_id.sh issues

[Tor Bug Tracker & Wiki]

#29065: shellcheck: test_switch_id.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  mikeperry   |Sponsor:
+
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks good now.

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

Re: [tor-bugs] #29555 [Applications/Tor Browser]: Tor unexpectedly exited. this may be do to a Tor Bug, etc

[Tor Bug Tracker & Wiki]

#29555: Tor unexpectedly exited. this may be do to a Tor Bug, etc
--+---
 Reporter:  FMCfmc|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  exited|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * owner:  (none) => tbb-team
 * status:  new => needs_information
 * component:  - Select a component => Applications/Tor Browser


Comment:

 Setting component. Please let us know if #28943 is related.
 If not, please provide information about the version of Tor Browser you
 are using, what OS you are using it on, and so on.

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

[tor-bugs] #29558 [Internal Services/Tor Sysadmin Team]: Please chown /srv/research.torproject.org/htdocs on staticiforme to torresearch group

[Tor Bug Tracker & Wiki]

#29558: Please chown /srv/research.torproject.org/htdocs on staticiforme to
torresearch group
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 It is currently owned by torwww, but we have a more specific group to use.

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

Re: [tor-bugs] #29298 [Core Tor/Tor]: Explicitly specify histogram bin endpoints/widths

[Tor Bug Tracker & Wiki]

#29298: Explicitly specify histogram bin endpoints/widths
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad 041-proposed network-team-   |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #28631   | Points:  5
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  needs_review => needs_revision


Comment:

 asn: this looks great! I have some minor comment change requests in the
 review on the PR. Code looks really good though. Such improved much
 simplified!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29559 [Obfuscation/meek]: meek-client-torbrowser should exit on stdin close, even while waiting on browser output

[Tor Bug Tracker & Wiki]

#29559: meek-client-torbrowser should exit on stdin close, even while waiting on
browser output
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Edit the browser extension not to output the `meek-http-helper: listen`
 line, or hack meek-client-torbrowser to break `grepHelperAddress`. Start
 Tor Launcher, select meek, and Connect. Now Cancel and exit Tor Browser.
 The bug is that meek-client-torbrowser and its child process firefox will
 continue running.

 It happens because meek-client-torbrowser's `TOR_PT_EXIT_ON_STDIN_CLOSE`
 and SIGTERM logic happen only after `grepHelperAddr`. meek-client-
 torbrowser should pay attention to its stdin the whole time so that it can
 exit correctly in this 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] #26838 [Webpages/Website]: Port the research portal content to Hugo (was: Port the research portal content to Lektor)

[Tor Bug Tracker & Wiki]

#26838: Port the research portal content to Hugo
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  research,ux-team  |  Actual Points:
Parent ID:  #26836| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * cc: chelseakomlo (added)


Old description:

> This will allow easy update to conform to the styleguide and make it
> easier to edit the content, and provide translations if desired.

New description:

 This will allow easy update to conform to the styleguide and make it
 easier to edit the content.

--

Comment:

 This is not a large site, and it also does not require translation (as
 discussed with other research team members in Brussels, much of the
 world's academic community is presenting at conferences/in journals in
 English).

 I found I was fighting with Lektor more than I was working on the content
 so I have instead ported the styleguide to Hugo (in an evening) and now
 have something that should be ready to deploy next week.

 I have made this live at https://research-staging.torproject.org/ for now.

 Deployment will require a single static binary to be available on the
 continuous deployment machine (for hugo) and no other dependencies.

 Once this is done, we can move forward with curating these research ideas
 and adding the other content we discussed for the research portal.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #29557, #29558

[Tor Bug Tracker & Wiki]

Batch modification to #29557, #29558 by irl:


--
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] #29558 [Internal Services/Tor Sysadmin Team]: Please chown /srv/research.torproject.org/htdocs on staticiforme to torresearch group

[Tor Bug Tracker & Wiki]

#29558: Please chown /srv/research.torproject.org/htdocs on staticiforme to
torresearch group
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #26838   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * parent:   => #26838


Comment:

 This is blocking deployment for #26838.

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

Re: [tor-bugs] #29557 [Internal Services/Tor Sysadmin Team]: Please create alias resea...@torproject.org

[Tor Bug Tracker & Wiki]

#29557: Please create alias resea...@torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #26838   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * parent:   => #26838


Comment:

 This is blocking deployment for #26838.

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

Re: [tor-bugs] #27207 [Core Tor/Tor]: Examples in CodingStandardsRust.md are wrong

[Tor Bug Tracker & Wiki]

#27207: Examples in CodingStandardsRust.md are wrong
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, doc, 035-deferred-20190115,|  Actual Points:
  041-proposed, easy |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

 * keywords:  rust, doc, 035-deferred-20190115, 041-proposed => rust, doc,
 035-deferred-20190115, 041-proposed, 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] #23886 [Core Tor/Tor]: Write FFI bindings and function pointers for ed25519-dalek

[Tor Bug Tracker & Wiki]

#23886: Write FFI bindings and function pointers for ed25519-dalek
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, ed25519, tor-  |  Actual Points:
  crypto, crypto, 034-triage-20180328,   |
  034-removed-20180328, 035-removed-20180711,|
  035-roadmap-removed-proposed-20181029, easy|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor3-can
-+-
Changes (by chelseakomlo):

 * keywords:
 rust, rust-pilot, ed25519, tor-crypto, crypto, 034-triage-20180328,
 034-removed-20180328, 035-removed-20180711, 035-roadmap-removed-
 proposed-20181029
 =>
 rust, rust-pilot, ed25519, tor-crypto, crypto, 034-triage-20180328,
 034-removed-20180328, 035-removed-20180711, 035-roadmap-removed-
 proposed-20181029, 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] #27052 [Core Tor/Tor]: document rust/crypto (was: document rust/protover and rust/crypto)

[Tor Bug Tracker & Wiki]

#27052: document rust/crypto
-+-
 Reporter:  cypherpunks3 |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, doc, 035-deferred-20190115,|  Actual Points:
  041-proposed, easy |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

 * keywords:  rust, doc, 035-deferred-20190115, 041-proposed => rust, doc,
 035-deferred-20190115, 041-proposed, 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] #27052 [Core Tor/Tor]: document rust/protover and rust/crypto

[Tor Bug Tracker & Wiki]

#27052: document rust/protover and rust/crypto
-+-
 Reporter:  cypherpunks3 |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, doc, 035-deferred-20190115,|  Actual Points:
  041-proposed   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 Modifying this to just focus on rust/crypto

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

Re: [tor-bugs] #28309 [Core Tor/Tor]: Log the rust version when printing other library versions

[Tor Bug Tracker & Wiki]

#28309: Log the rust version when printing other library versions
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, 040-roadmap-proposed, easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by chelseakomlo):

 * keywords:  rust, 040-roadmap-proposed => rust, 040-roadmap-proposed, 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] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:  1
 Reviewer:  mikeperry  |Sponsor:
---+---
Changes (by mikeperry):

 * status:  needs_review => needs_revision


Comment:

 Ok I now understand a bit more of what's going on here. I am still not in
 favor of this solution, for the following reasons:

 1. The only way that the closure callback could block in the old code was
 if the result getter thread died/stalled/deadlocked and did not manage to
 actually pull a result to make the queue non-full.
 2. The new code has a while loop which will still run forever if the queue
 is full and nothing pulls from it. It will just log in that case.

 It seems like #1 and #2 both block and fail to return in the exact same
 way. What about:

 {{{
 try:
   result_dump.queue.put(measurement_result, timeout=3)
 except Full as e:
   log.warn("The results queue is staying full. Is the getter thread
 dead?")
 }}}

 This way, the closure will only block for at most 3 seconds, which should
 only happen if the getter is dead/hung, since the getter should have
 pulled in just 1 second. Hence the warn in that 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

[tor-bugs] #29560 [Webpages/Research]: Create a Research Tools page

[Tor Bug Tracker & Wiki]

#29560: Create a Research Tools page
---+-
 Reporter:  irl|  Owner:  irl
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  0.2|   Reviewer:
  Sponsor: |
---+-
 TorPS and Shadow should be on here, there may be other tools we want to
 include too. This would be the last thing that we have on the Metrics
 research page that we don't have on the Research Portal so would allow us
 to remove the research section from Metrics Portal.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29561 [Webpages/Research]: List Research Groups using data framework instead of manually

[Tor Bug Tracker & Wiki]

#29561: List Research Groups using data framework instead of manually
---+-
 Reporter:  irl|  Owner:  irl
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Research  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  0.2|   Reviewer:
  Sponsor: |
---+-
 The groups should be JSON/YAML data in the data dir instead of being
 manually crafted HTML and then we just reuse the template.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 * [https://www.torproject.org/dist/torbrowser/8.5a8/torbrowser-install-
 win64-8.5a8_en-US.exe Tor Browser 8.5a8 64-bit]
  * tor 0.4.0.1-alpha 81f2b89efc94723f
  * Windows 7

 Start Tor Browser, click Configure, then select a pluggable transport (I
 tried both obfs4 and meek-azure). While bootstrapping is in progress,
 click Cancel. tor.exe crashes with the log:
 {{{
 [ERR] tor_assertion_failed_(): Bug: process.c:522:
 process_get_win32_process: Assertion process->win32_process failed;
 aborting. (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
 [ERR] Bug: Assertion process->win32_process failed in
 process_get_win32_process at process.c:522. (Stack trace not available)
 (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
 }}}

 These dialogs appear in succession. Sometimes, the "application has
 requested the Runtime to terminate it in an unusual way" would not appear,
 and instead the "tor.exe has stopped working" would appear twice.

 [[Image(terminate.png)]]

 [[Image(stoppedworking.png)]]

 [[Image(exited.png)]]

 The "View problem details" expander shows:
 {{{
 Problem signature:
   Problem Event Name:   APPCRASH
   Application Name: tor.exe
   Application Version:  0.0.0.0
   Application Timestamp:a640a628
   Fault Module Name:tor.exe
   Fault Module Version: 0.0.0.0
   Fault Module Timestamp:   a640a628
   Exception Code:   4015
   Exception Offset: 002c6a44
   OS Version:   6.1.7601.2.1.0.256.48
   Locale ID:1033
   Additional Information 1: 869c
   Additional Information 2: 869c6822c6babdacb5663a19facccafb
   Additional Information 3: 607b
   Additional Information 4: 607bd60f513aeecf36fa5e247b547f57
 }}}

 Here are tor logs from different runs. One of them mentions a clock skew,
 but that seems to be a problem with the remote system. I checked and the
 time on the local Windows host was correct.

 {{{
 2/23/19, 08:42:06.326 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 2/23/19, 08:42:09.765 [NOTICE] Switching to guard context "default" (was
 using "bridges")
 2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 2/23/19, 08:42:09.765 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 2/23/19, 08:42:09.765 [NOTICE] Opened Socks listener on 127.0.0.1:9150
 2/23/19, 08:42:10.224 [WARN] Managed proxy at
 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported:
 2019/02/23 08:42:09 running firefox command
 ["C:\\Users\\david\\Desktop\\Tor Browser\\Browser\\firefox.exe" "--
 invisible" "-no-remote" "-profile" "C:\\Users\\david\\Desktop\\Tor
 Browser\\Browser\\TorBrowser\\Data\\Browser\\profile.meek-http-helper"]
 2/23/19, 08:42:10.224 [WARN] Managed proxy at
 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported:
 2019/02/23 08:42:09 firefox started with pid 3552
 2/23/19, 08:42:10.224 [NOTICE] Bootstrapped 5% (conn): Connecting to a
 relay
 2/23/19, 08:42:10.564 [WARN] Managed proxy at
 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported:
 2019/02/23 08:42:10 running meek-client command
 ["TorBrowser\\Tor\\PluggableTransports\\meek-client.exe" "--helper"
 "127.0.0.1:1468"]
 2/23/19, 08:42:10.565 [WARN] Managed proxy at
 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported:
 2019/02/23 08:42:10 meek-client started with pid 4004
 2/23/19, 08:42:10.565 [WARN] Managed proxy at
 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported:
 2019/02/23 08:42:10 using helper on 127.0.0.1:1468
 2/23/19, 08:42:10.565 [WARN] Managed proxy at
 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe' reported:
 2019/02/23 08:42:10 listening on 127.0.0.1:1469
 2/23/19, 08:42:10.566 [NOTICE] Bootstrapped 10% (conn_done): Connected to
 a relay
 2/23/19, 08:42:10.892 [NOTICE] Bootstrapped 14% (handshake): Handshaking
 with a relay
 2/23/19, 08:42:11.490 [NOTICE] Bootstrapped 15% (handshake_done):
 Handshake with a 

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * Attachment "stoppedworking.png" added.


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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * Attachment "terminate.png" added.


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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * Attachment "exited.png" added.


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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled (was: APPCRASH of tor.exe on Windows 7 when PT bootstrap is cancelled)

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dcf):

 I got it to happen on Windows 8 too.

 [[Image(win8-terminate.png)]]

 [[Image(win8-stoppedworking.png)]]

 [[Image(win8-exited.png)]]

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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * Attachment "win8-terminate.png" added.


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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * Attachment "win8-stoppedworking.png" added.


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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
--+
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

 * Attachment "win8-exited.png" added.


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

Re: [tor-bugs] #29527 [Core Tor/Tor]: Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution test

[Tor Bug Tracker & Wiki]

#29527: Division by zero: undefined behaviour in
circuitpadding/circuitpadding_sample_distribution test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-ci, tor-test,|  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by riastradh):

 Floating-point division by zero isn't undefined behaviour -- it is
 precisely defined in IEEE 754 and has been consistently implemented in
 essentially all software and hardware for decades.  This looks like
 mostly, if not entirely, false positives from a buggy UB sanitizer that's
 confused about floating-point arithmetic.

 All of the cases in test_prob_distr.c appear to be working as intended.
 For example, test_prob_distr.c line 496 invokes `CHECK_RELERR(np,
 cdf_log_logistic(1/x, 1, 1))`.  The log-logistic distribution has the
 property that CDF(1/x) = 1 - CDF(x).  When x is arbitrarily close to 0, 1
 - CDF(x) should be extremely close to 1; when we round x to zero, CDF(x)
 should be 0, 1/x is rounded to infinity, and CDF(1/x) = 1 - CDF(x) should
 be 1, exactly as the test confirms.

 In prob_distr.c:

 - line 344, column 17 is inside logit.  logit(1) should be +inf (lim_{x
 --> 1^-^} logit(x) = +inf), and the +inf yielded by division by zero is
 correctly propagated by the expression log(p/(1 - p)).  The test suite
 specifically checks that logit(1) = +inf (test_prob_distr.c lines 323 and
 395).
 - line 427, column 26 is inside logithalf.  logithalf(1/2) = logit(1)
 should be +inf, and the +inf yielded by division by zero is correctly
 propagated by the expression log((0.5 + p0)/(0.5 - p0)).  The test suite
 specifically checks that logithalf(+/-1/2) = +/-inf (test_prob_distr.c
 lines 294, 323, and 397).
 - line 685, column 27 is inside isf_log_logistic.  The log logistic
 distribution has the property that CDF(1/x) = 1 - CDF(x), which means
 CDF^-1^(1 - p) = SF^-1^(p) = 1/x.  In test_prob_distr.c, line 450
 specifies a test where p = 0, np = 1 - p = 1, and line 553 confirms
 isf_log_logistic(p, 1, 1), which entails dividing by p, correctly gives
 1/x.
 - line 814, column 23 is in cdf_genpareto.  Here we are checking whether
 the approximation 1 - e^-x_0^ is safe for the specified value of xi, which
 we consider it to be if |xi| < 1e-17/x_0.  If x_0 is infinite, we consider
 it safe.  For any xi, as x_0 goes to zero, the CDF goes to zero too, which
 is exactly what the approximation computes, so this is correct.  The test
 case on line 718 of test_prob_distr.c specifies x_0 = 0.  (Side note: It
 appears I wrote no tests with a nonzero mean.  Should maybe add some.)
 - line 837, column 23 is in sf_genpareto, which has the same case analysis
 and test cases as the above instance.
 - line 1170, column 20 is in sample_log_logistic, evaluating the quotient
 in `(1 - p0)/p0`.  This is division by zero only if p0 = 0.  In that case,
 we return the correct answer is +inf, since as p0 -> 0, this function
 grows without bound.  In test_prob_distr.c, lines 565, 567, and 569
 specify tests with p0 = 0.  (However, in actual runs of the code with p0
 drawn using `random_uniform_01`, p0 = 0 should happen only with
 probability 2^-1075^, i.e. never.)
 - line 1311, column 17 is inside sample_geometric, evaluating the quotient
 in `-x/log1p(-p)`.  The divisor can be zero only if p = 0, which means
 we're trying to sample from a geometric distribution with zero success
 probability.  Of course, the only reasonable result is +inf.  **Is there
 anything _upstream_ of this logic that tries to construct a
 `CIRCPAD_DIST_GEOMETRIC` with zero success probability?**
 - line 1219, column 49 is inside sample_weibull, computing `1/k`.  This
 can happen only if k = 0, which is an edge case that's probably not very
 useful, but the expression does return +inf which is the correct limit as
 k --> 0.  **Is there anything upstream of this logic that tries to
 construct a `CIRCPAD_DIST_WEIBULL` with zero shape?**

 By the way, pretty much all non-arm hardware supports a kind of
 ‘sanitizer’ for floating-point invalid operations (which are not undefined
 behaviour, but are usually undesirable) with zero overhead if they don't
 happen, namely trapping the invalid-operation exception, which Unix will
 translate to SIGFPE.  (Most arm hardware supports the exception, but only
 via sticky bits you can ex

Re: [tor-bugs] #29347 [Obfuscation/meek]: Rewrite meek-http-helper as a WebExtension

[Tor Bug Tracker & Wiki]

#29347: Rewrite meek-http-helper as a WebExtension
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  webextension  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  assigned => needs_review


Comment:

 I worked on integrating the WebExtension into Tor Browser. It's working
 now and ready to be looked at.
  * [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/log/?h=webextension&id=de03366fbe1f23cbb21d41aec8f4913f189ecb8b
 meek]
  * [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/commit/?h
 =meek-webextension&id=45192a1adcb29e6200f2b9e46d97bbdbbfb0a509 tor-
 browser-build]
 I tested it on linux-x86_64 and windows-x86_64, but I'm not set up to test
 on osx.

 Recall that the native messaging API requires us to install a JSON "host
 manifest" for the native executable--this both authorizes the extension to
 run a native executable, and tells the browser the (absolute) path to the
 native executable. The absolute path inside the manifest means we cannot
 just use a static file; we need to know where the browser is installed. So
 now, meek-client-torbrowser [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/commit/?h=webextension&id=5b539a2c5f2a8474cee3dc2c2312ad365bdb1cca
 writes a host manifest] (taking into account platform-specific paths)
 before starting the browser.

 Two things I'd specifically like feedback on:
  * I'm not able to test the osx version, which is slightly tricky because
 the data directory can be in different places depending on
 `TOR_BROWSER_TOR_DATA_DIR` (#18904). [https://gitweb.torproject.org
 /pluggable-transports/meek.git/diff/meek-client-
 torbrowser/mac.go?h=webextension&id=5b539a2c5f2a8474cee3dc2c2312ad365bdb1cca
 This is what I'm doing], but I'm not sure if it works:
  if `TOR_BROWSER_TOR_DATA_DIR` is set:
install in `$TOR_BROWSER_TOR_DATA_DIR/../Browser`
  else:
install in `$PWD/../../../../TorBrowser-Data/Browser`
The documentation [https://developer.mozilla.org/en-US/docs/Mozilla
 /Add-ons/WebExtensions/Native_manifests#Mac_OS_X says] that the host
 manifest should be installed in `$HOME/Library/Application
 Support/Mozilla/NativeMessagingHosts/`, but the code actually does a
 [https://dxr.mozilla.org/mozilla-
 
central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/toolkit/components/extensions/NativeManifests.jsm#44
 Services.dirsvc.get] for [https://dxr.mozilla.org/mozilla-
 central/source/toolkit/xre/nsXREDirProvider.cpp#420
 XRE_USER_NATIVE_MANIFESTS], which calls `GetUserDataDirectoryHome` and
 then into some Tor Browser–overriden code that replaces the home
 directory.
  * As noted in comment:9, on windows we cannot simply write the host
 manifest to a well-known path. You have to set a well-known registry key
 whose value is the path to the manifest. So [https://gitweb.torproject.org
 /pluggable-transports/meek.git/diff/meek-client-
 
torbrowser/windows.go?h=webextension&id=5b539a2c5f2a8474cee3dc2c2312ad365bdb1cca
 what the code does now] is write a registry key at
 `HKEY_CURRENT_USER\SOFTWARE\Mozilla\NativeMessagingHosts\meek.http.helper`.
 That works, but I don't like the fact that it leaves a permanent trace
 outside the installation directory. I'd like to know if there are any
 ideas for removing this step.

 The tor-browser-build changes are minimal: just packaging the webextension
 directory instead of the firefox directory, building the native
 executable, and adding a dependency on golang.org/x/sys/windows/registry
 to write the registry key on windows.

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

Re: [tor-bugs] #29528 [Core Tor/Tor]: UndefinedBehaviorSanitizer errors should fail the unit tests

[Tor Bug Tracker & Wiki]

#29528: UndefinedBehaviorSanitizer errors should fail the unit tests
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci, tor-test, 041-proposed  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--

Comment (by riastradh):

 FYI, exactly zero of the cases this sanitizer flagged as undefined
 behaviour in #29527 are actually undefined behaviour.  Of the ~50 reports,
 only two of them are ''potentially'' evidence of problems, but since the
 tests pass with no floating-point invalid-operation exceptions I suspect
 they might not be problems either.

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

Re: [tor-bugs] #29527 [Core Tor/Tor]: Division by zero: undefined behaviour in circuitpadding/circuitpadding_sample_distribution test

[Tor Bug Tracker & Wiki]

#29527: Division by zero: undefined behaviour in
circuitpadding/circuitpadding_sample_distribution test
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, tor-ci, tor-test,|  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by riastradh):

 test_circuitpadding.c, helper_circpad_circ_distribution_machine_setup has
 the following comment:

 {{{
 /** Helper function: Initializes a padding machine where every state uses
 the
  *  uniform probability distribution.  */
 }}}

 However, it proceeds to set up several other distributions with
 nonsensical and/or ignored parameters:

 {{{
   zero_st->iat_dist.type = CIRCPAD_DIST_UNIFORM;
   zero_st->iat_dist.param1 = min;
   zero_st->iat_dist.param2 = max;
 ...
   first_st->iat_dist.type = CIRCPAD_DIST_LOGISTIC;
   first_st->iat_dist.param1 = min;
   first_st->iat_dist.param2 = max;
 ...
   second_st->iat_dist.type = CIRCPAD_DIST_LOG_LOGISTIC;
   second_st->iat_dist.param1 = min;
   second_st->iat_dist.param2 = max;
 ...
   third_st->iat_dist.type = CIRCPAD_DIST_GEOMETRIC;
   third_st->iat_dist.param1 = min;
   third_st->iat_dist.param2 = max;
 ...
   fourth_st->iat_dist.type = CIRCPAD_DIST_WEIBULL;
   fourth_st->iat_dist.param1 = min;
   fourth_st->iat_dist.param2 = max;
 ...
   fifth_st->iat_dist.type = CIRCPAD_DIST_PARETO;
   fifth_st->iat_dist.param1 = min;
   fifth_st->iat_dist.param2 = max;
 }}}

 Is this intended?  (Here min=0 and max=10 in the solitary call site, which
 might explain the geometric and Weibull distributions with zero
 parameters.)

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

Re: [tor-bugs] #29528 [Core Tor/Tor]: UndefinedBehaviorSanitizer errors should fail the unit tests

[Tor Bug Tracker & Wiki]

#29528: UndefinedBehaviorSanitizer errors should fail the unit tests
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-ci, tor-test, 041-proposed  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--

Comment (by riastradh):

 There is an open Clang bug for this:
 https://bugs.llvm.org/show_bug.cgi?id=19535

 Possible workaround: use `-fno-sanitize=float-divide-by-zero` in addition
 to `-fsanitize=undefined`.

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

Re: [tor-bugs] #14256 [Obfuscation/meek]: Clarify whether Cloudflare's Universal SSL thing works with meek

[Tor Bug Tracker & Wiki]

#14256: Clarify whether Cloudflare's Universal SSL thing works with meek
--+---
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dcf):

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


Comment:

 I think the summary of the situation is that Cloudflare doesn't support
 domain fronting, but these days supports draft ESNI, and that's probably
 the promising path to pursue. There's some discussion of ESNI in #28168.

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

Re: [tor-bugs] #25614 [Core Tor/Tor]: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not client transports

[Tor Bug Tracker & Wiki]

#25614: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not
client transports
--+--
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "bug25614.patch" added.


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

Re: [tor-bugs] #25614 [Core Tor/Tor]: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not client transports

[Tor Bug Tracker & Wiki]

#25614: tor sets `TOR_PT_EXIT_ON_STDIN_CLOSE=1` only for server transports, not
client transports
--+--
 Reporter:  dcf   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 How's this?

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

Re: [tor-bugs] #21258 [Obfuscation/meek]: meek PT stops functioning after long uptime

[Tor Bug Tracker & Wiki]

#21258: meek PT stops functioning after long uptime
--+---
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by dcf):

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


Comment:

 Replying to [ticket:21258 cypherpunks]:
 > Interestingly, and for unknown reasons, adding the log options to meek-
 client and meek-client-torbrowser in torrc avoids this bug. Any thoughts?

 It sounds like this was another manifestation of #26360/#28179.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29563 [Applications]: css line-height revisted [at least zoom and linux]

[Tor Bug Tracker & Wiki]

#29563: css line-height revisted [at least zoom and linux]
---+--
 Reporter:  Thorin |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Applications
  Version: |   Severity:  Normal
 Keywords:  tbb-fingerprinting-os  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 The mozilla upstream ticket is
 https://bugzilla.mozilla.org/show_bug.cgi?id=1397994

 Following on from #23104, it seems that when applied on various (preset)
 zoom levels, that there are differences between Windows and Linux (I do
 not have any macOS or macOS X machines to test on)

 Tor Browser (and RFP in Firefox) actively ignores site specific zoom
 levels, and new tabs/windows will open at 100% zoom. But that does not
 stop someone from using zoom, and indeed the setting stays for the current
 tab when re-used (even when the domain changes - i.e it is a per tab
 setting in this context). Examples are poorly designed websites, small
 devices, users with poor eyesight - where the user is effectively forced
 to zoom (in or out)

 Looking at some test results: I used
 https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#useragent
 - see the `css line-height` field (and feel free to zoom and refresh) -
 also see the attachment for some spreadsheet results (png), which is not
 definitive, but enough to draw some conclusions.

 Clearly the mitigation in Windows covered all zoom settings, so was this a
 design decision? In Linux, it seems as if zoom was only factored in for
 `50`, `100`, `150`, `200`, and `300` (of the preset zoom levels). Is this
 because of some limitation in Linux?

 As a result, so far, at least 8 zoom levels in TBB on Linux are unique and
 leak the OS as Linux. The 9th zoom level not covered (`30%`) is not unique
 in Firefox overall, but is unique on Tor Browser (it is trivial to detect
 if Tor Browser is being used, so this is in effect a unique value as well)

 Note: for Tor Browser, you're not concerned with the Firefox values, I'm
 just showing them so you can see that outside of 100% zoom, without FP'ing
 protection, some results are not necessarily OS specific: e.g. FF62+
 Windows and Linux are identical at `50`, `67`, `80`, `90`, `150`, and
 `240%`.

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

Re: [tor-bugs] #29563 [Applications]: css line-height revisted [at least zoom and linux]

[Tor Bug Tracker & Wiki]

#29563: css line-height revisted [at least zoom and linux]
---+
 Reporter:  Thorin |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-fingerprinting-os  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by Thorin):

 * Attachment "TBB-cssLH-Linux.png" added.

 spreadsheet results as png

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

Re: [tor-bugs] #29559 [Obfuscation/meek]: meek-client-torbrowser should exit on stdin close, even while waiting on browser output

[Tor Bug Tracker & Wiki]

#29559: meek-client-torbrowser should exit on stdin close, even while waiting on
browser output
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * Attachment "0001-Look-for-EOF-on-stdin-while-grepping-for-the-
 helper-.patch" added.


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

Re: [tor-bugs] #23104 [Applications/Tor Browser]: CSS line-height reveals the platform Tor Browser is running on

[Tor Bug Tracker & Wiki]

#23104: CSS line-height reveals the platform Tor Browser is running on
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:  gk   |Sponsor:
-+-

Comment (by Thorin):

 also see #29563

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

Re: [tor-bugs] #29559 [Obfuscation/meek]: meek-client-torbrowser should exit on stdin close, even while waiting on browser output

[Tor Bug Tracker & Wiki]

#29559: meek-client-torbrowser should exit on stdin close, even while waiting on
browser output
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Here is a patch. It looks for the helper address in a background goroutine
 in order to simultaneously wait on `sigChan`.

 This is the patch I used to test, breaking the grep pattern so that
 `grepHelperAddress` would not return.
 {{{#!diff
 diff --git a/meek-client-torbrowser/meek-client-torbrowser.go b/meek-
 client-torbrowser/meek-client-torbrowser.go
 index 16f0ebc..2341cbc 100644
 --- a/meek-client-torbrowser/meek-client-torbrowser.go
 +++ b/meek-client-torbrowser/meek-client-torbrowser.go
 @@ -38,7 +38,7 @@ import (
  )

  // This magic string is emitted by meek-http-helper.
 -var helperAddrPattern = regexp.MustCompile(`^meek-http-helper: listen
 (127\.0\.0\.1:\d+)$`)
 +var helperAddrPattern = regexp.MustCompile(`^meek-http-helper: listenXXX
 (127\.0\.0\.1:\d+)$`)

  func usage() {
 fmt.Fprintf(os.Stderr, "Usage: %s [meek-client-torbrowser args] --
 meek-client [meek-client args]\n", os.Args[0])
 }}}

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

Re: [tor-bugs] #29563 [Applications/Tor Browser]: css line-height revisted [at least zoom and linux]

[Tor Bug Tracker & Wiki]

#29563: css line-height revisted [at least zoom and linux]
--+--
 Reporter:  Thorin|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting-os |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Thorin):

 * owner:  (none) => tbb-team
 * component:  Applications => Applications/Tor Browser


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

Re: [tor-bugs] #24306 [Obfuscation/meek]: Add some volunteer's public meek URLs to TBB, and also write a blog for meek.

[Tor Bug Tracker & Wiki]

#24306: Add some volunteer's public meek URLs to TBB, and also write a blog for
meek.
--+-
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

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


Comment:

 I don't think we're set up to distribute volunteers' meek instances right
 now. The anti-censorship team is working on a new design for a more
 general BridgeDB/broker that might make it possible to distribute non-
 centrally-managed meek hosts.

 There was a blog post at https://blog.torproject.org/how-use-meek-
 pluggable-transport.

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