Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 026-backport-maybe, review-   |
  group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by teor):

 * keywords:
 tor-relay, security-low, privcount, 031-backport, 030-backport,
 029-backport, 028-backport-maybe, 027-backport-maybe, 026-backport-
 maybe, review-group-22
 =>
 tor-relay, security-low, privcount, 031-backport, 030-backport,
 029-backport, 028-backport-maybe, 026-backport-maybe, review-group-22


Comment:

 0.2.7 is EOL.

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

Re: [tor-bugs] #23323 [Core Tor/Tor]: sample_laplace_distribution should produce a valid result on 0.0

[Tor Bug Tracker & Wiki]

#23323: sample_laplace_distribution should produce a valid result on 0.0
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, 031-backport, |  Actual Points:
  030-backport, 029-backport, 028-backport-  |
  maybe, 026-backport-maybe  |
Parent ID:  #23061   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-relay, security-low, 031-backport, 030-backport, 029-backport, 028
 -backport-maybe, 027-backport-maybe, 026-backport-maybe
 =>
 tor-relay, 031-backport, 030-backport, 029-backport, 028-backport-
 maybe, 026-backport-maybe


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23323 [Core Tor/Tor]: sample_laplace_distribution should produce a valid result on 0.0

[Tor Bug Tracker & Wiki]

#23323: sample_laplace_distribution should produce a valid result on 0.0
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core |Version:  Tor: 0.2.6.3-alpha
  Tor/Tor|   Keywords:  tor-relay, security-low,
 Severity:  Normal   |  031-backport, 030-backport, 029-backport, 028
 |  -backport-maybe, 027-backport-maybe, 026
 |  -backport-maybe
Actual Points:   |  Parent ID:  #23061
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 Destroying the signal with probability 1 in 2^-53^ isn't a great idea.
 Let's pick a sensible double value, and pass it through the function
 instead.

 I suggest 2^-54^, but it really doesn't matter exactly what value we use,
 as long as it produces valid results, because the probability is so low.

 Introduced in 45bc5a0

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by teor):

 Replying to [comment:22 catalyst]:
 > Replying to [comment:21 nickm]:
 > > I tried the ldexp() trick too, but that fails the test that
 `uint64_to_dbl_0_1(UINT64_MAX) < 1.0` if have all four ldexp() calls.  If
 I remove the lowest-magnitude one, it's fine, but of course we only get 48
 bits.
 > Oh right, it'll round off the bits past `DBL_MANT_DIG`.  Maybe mask off
 all but the high 5 bits?

 This is still susceptible to the rounding mode in use at the time.
 So yawning's bit twiddling is going to be more reliable and robust.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23322 [HTTPS Everywhere]: HTTPS Everywhere Preferences has visible File Upload

[Tor Bug Tracker & Wiki]

#23322: HTTPS Everywhere Preferences has visible File Upload
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor Browser 7.0.4 (based on Mozilla Firefox 52.3.0) (64-bit)
 HTTPS Everywhere 2017.8.19
 macOS 10.12.6

 There is a visible file upload element with a "Browse" button on the HTTPS
 Everywhere page in about:addons

 See screenshot

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

Re: [tor-bugs] #23322 [HTTPS Everywhere]: HTTPS Everywhere Preferences has visible File Upload

[Tor Bug Tracker & Wiki]

#23322: HTTPS Everywhere Preferences has visible File Upload
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "addons_browse.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] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Closed #23321 as 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

Re: [tor-bugs] #23321 [HTTPS Everywhere]: HTTPS Everywhere Settings Text is not Displayed

[Tor Bug Tracker & Wiki]

#23321: HTTPS Everywhere Settings Text is not Displayed
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by yawning):

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


Comment:

 Duplicate of #23258

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23321 [HTTPS Everywhere]: HTTPS Everywhere Settings Text is not Displayed

[Tor Bug Tracker & Wiki]

#23321: HTTPS Everywhere Settings Text is not Displayed
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor Browser 7.0.4 (based on Mozilla Firefox 52.3.0) (64-bit)
 HTTPS Everywhere 2017.8.19
 macOS 10.12.6

 After opening Tor Browser, the HTTPS Everywhere icon showed up on the
 front bar. When I open it, the text is almost completely missing (see
 screenshot).

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

Re: [tor-bugs] #23321 [HTTPS Everywhere]: HTTPS Everywhere Settings Text is not Displayed

[Tor Bug Tracker & Wiki]

#23321: HTTPS Everywhere Settings Text is not Displayed
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  HTTPS Everywhere  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * Attachment "tor_httpse_bug.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] #22271 [Core Tor/Fallback Scripts]: Regenerate fallback list for 0.3.2 or 0.3.3

[Tor Bug Tracker & Wiki]

#22271: Regenerate fallback list for 0.3.2 or 0.3.3
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 I think we might want to aim for ~200 fallbacks this time, but I don't
 have the time to opt-in. I'll see if someone else wants to do it.

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

Re: [tor-bugs] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * type:  enhancement => task


Comment:

 ln5 contacted tor-relays [1] with the following changes:
 {{{
 Fallback directory mirror DFRI7 [0] is down, due to multiple disk
 krashes, since about 30h and will not come alive with the same key.

 [0] 171.25.193.131:80 orport=443
 id=79861CF8522FC637EF046F7688F5289E49D94576

 A new DFRI7 will appear on the same address and port within a couple of
 days.
 }}}

 We need to change to the new fingerprint once it's available.

 [1]: https://lists.torproject.org/pipermail/tor-
 relays/2017-August/012885.html

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

Re: [tor-bugs] #22527 [Core Tor/Fallback Scripts]: Add new operators to fallback directory whitelist

[Tor Bug Tracker & Wiki]

#22527: Add new operators to fallback directory whitelist
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #22271 | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * type:  defect => task


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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by yawning):

 Replying to [comment:21 nickm]:
 > but can we do better?

 On a more serious attempt at giving an answer, as a non-portable "better"
 (that I still think is largely pointless), you can probably use a variant
 of my solution with `long double` and cast to `double`.

 Note that the behavior of such a routine is entirely compiler and
 architecture dependent, and it'll probably be a lot slower when it works.

 If it were up to me, I would fully document the behavior and be done with
 it, under the assumption that anyone doing something that requires a less
 leaky floating point abstraction can either scale their values correctly
 (and use integer math) or write their own sampler.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by yawning):

 If the test assuming `f(n-1) < f(n) < f(n+1)` is ok, then you can do:

 {{{
   double expected_increment = pow(FLT_RADIX, -DBL_MANT_DIG);

   assert(uint64_to_dbl_0_1(1) == expected_increment);

   // Hell, stick this in a for loop that randomly samples n, and asserts
 if you really care.
   assert(uint64_to_dbl_0_1(2) - uint64_to_dbl_0_1(1) ==
 expected_increment);
 }}}

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by yawning):

 Replying to [comment:21 nickm]:
 > but can we do better?

 Yeah, fix the broken test.

 {{{
 do {
   d = crypto_rand_double(); // d = n * pow(2, -53) (Where n is the post
 mask sampled integer)

   /* Now check the granularity, by finding the lower bits of the result.
 */
   d *= pow(2, EXPECTED_RAND_MANTISSA_BITS);  // d *= pow(2, 53)
  // d  = n * pow(2, -53) *
 pow(2, 53)
  // d  = n
   d -= trunc(d); // d -= d (trunc(d) = d)
 } while (d == 0.0);
 }}}

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

Re: [tor-bugs] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by linda):

 Mark:

 My feedback: yay!

 The prototype accurately reflect the behavior/layout that I envisioned for
 Tor launcher. I like the network settings screen, and am excited about the
 simplicity of Tor launcher flow for the user, how much clearer what
 options should be chosen and when, and that people can see all their
 settings right before they connect. Kudos on getting everything that I
 designed to fit neatly into the current window size, even with the
 settings combination that took up the most space (inputting my own bridge
 lines + using a proxy).

 What I think we should do next:
 * the prototype doesn't incorporate all the text changes/include the moat
 option like the final version of the Tor launcher. That being said, I know
 that this is not the final version, and these changes would be made
 eventually.
 * We should work on sizing/styling--font sizes, images sizes, placement,
 etc. I didn't specify any of this in the prototype, and haven't thought
 about it. I think it's most of the way there, except the initial Tor |
 Browser image looks a bit big, and some of the text might look better if
 the containers they were in were tinkered with a bit.

 Thanks for creating the prototype!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23320 [Webpages/Website]: Add "Android OS Developer" job description to website

[Tor Bug Tracker & Wiki]

#23320: Add "Android OS Developer" job description to website
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Please add the below job description to the website. Thank you!




 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 The Tor Project is looking for an Android OS developer!

 August 23, 2017

 The Tor Project is looking for an Android OS Developer!

 As an Android OS Developer, your job will be to work closely with other
 members of the development team to build and release a Tor Browser for
 Android with functionality and build processes in parity with the desktop
 browser. This is a full-time position.

 Being a Tor developer includes triaging, diagnosing, and fixing bugs;
 looking for and resolving mobile privacy issues; responding on short
 notice to urgent security issues; and working collaboratively with
 coworkers and volunteers to implement new features and mobile behavior
 changes. We also need help making our code more maintainable, testable,
 and mergeable by upstream. The person in this position will review other
 people's code, designs, and academic research papers to make suggestions
 for improvement.

 This position will also focus on the following tasks/projects:

 ·  Design TorService API/integration with Fennec Mobile Android Java
 code
 ·  Automate a continuous build process
 ·  Make Tor Browser for Android a standalone application by porting
 the Orbot connection to Tor
 ·  Create a Gradle-dependent standalone Tor Service Library for
 Android
 ·  Coordinate uplifting of mobile patches

 Required Qualifications:

 ·  5+ years experience with developing and testing Java/JNI, Android
 APIs, and library dependencies
 ·  Experience with process management services on Android
 ·  Experience with Android Software Development Kit (SDK)
 ·  Experience in cross-compiling Linux/C/C++ code and libraries to
 mobile devices via Android Native Development Kit (NDK)
 ·  Experience using network traffic capture and monitoring tools
 (Wireshark, PCAP)
 ·  Test writing in Espresso, Robotum, JUnit, and/or comparable
 environment
 ·  Good interpersonal and open-source collaboration skills

 Desired Qualifications:

 ·  Experience with reproducible builds on desktop or mobile
 ·  User interface and usability skills (nice, but not essential for
 this role)
 ·  Shipped public applications with NDK features
 ·  Experience with Rust and Go on Android
 ·  Automated testing and continuous integration using cloud based
 services
 ·  Network knowledge and/or experience; experience investigating leaks

 Other notes:

 Academic degrees are great, but not required if you have the right
 experience!

 The team coordinates via IRC, email, and bug trackers. This position may
 be performed remotely, but we would be happy to provide a desk at our
 office in Seattle, Washington. We also have an informal shared workspace
 arrangement in San Francisco.

 The Tor Project, Inc., is a 501(c)(3) non-profit organization that
 provides the technical infrastructure for privacy protection over the
 Internet. With paid staff and contractors of around 30 technologists and
 operational support people, plus many volunteers all over the world who
 contribute to our work, the Tor Project is funded in part by government
 grants and contracts, as well as by individual, foundation, and corporate
 donations. We only write free and open source software, and we don't
 believe in software patents.

 The Tor Project has a competitive benefits package, including a generous
 PTO policy; 14 paid holidays per year (including the week between
 Christmas and New Year's, when the office is closed); health, vision,
 dental, disability, (and life insurance, where available) paid in full for
 employee; flexible work schedule; and occasional travel opportunities.

 The Tor Project, Inc., is an equal opportunity, affirmative action
 employer.

 To apply:

 Please email a PDF of your resume/CV, and a cover letter explaining how
 your qualifications and experience meet the requirements of this job
 description, including why you want to work on Tor. Email should be sent
 to hr at torproject.org with "Browser Developer Android OS" in the subject
 line. Link to at least one of your code samples (ideally, more than one
 and all of which we will presume you are authorized to disclose). No phone
 calls, please!

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 

Re: [tor-bugs] #22918 [Core Tor/Tor]: Add link protocol 5 throughout torspec

[Tor Bug Tracker & Wiki]

#22918: Add link protocol 5 throughout torspec
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:  #18856| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * priority:  Medium => Very High
 * status:  new => accepted


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

Re: [tor-bugs] #22377 [Core Tor/Tor]: Rip out AUTHDIR_NEWDESCS event?

[Tor Bug Tracker & Wiki]

#22377: Rip out AUTHDIR_NEWDESCS event?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 See branch `ticket22377` in my public Tor repository.

 See also branch `ticket22377_spec` in my torspec repository.

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

Re: [tor-bugs] #22377 [Core Tor/Tor]: Rip out AUTHDIR_NEWDESCS event?

[Tor Bug Tracker & Wiki]

#22377: Rip out AUTHDIR_NEWDESCS event?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #12898| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * 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] #23260 [Core Tor]: Encoding onion key creation date in the url

[Tor Bug Tracker & Wiki]

#23260: Encoding onion key creation date in the url
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 needs-design tricky  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: unspecified


Comment:

 please see my questions above; I think this might not be as possible as
 you think it is.  But if it _is_ possible, I want to know how. ;)

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

Re: [tor-bugs] #23309 [Core Tor/Tor]: hs: We need to get rid of a descriptor when entering non-overlap mode

[Tor Bug Tracker & Wiki]

#23309: hs: We need to get rid of a descriptor when entering non-overlap mode
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:  SponsorR-must
-+

Comment (by nickm):

 Could you rebase this onto master and squash it?  I tried to do it myself,
 but it didn't apply cleanly, and I wasn't sure how to fix it up.

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

Re: [tor-bugs] #23319 [Core Tor/Tor]: hs: Memory leak in test hs_descriptor/decode_bad_signature

[Tor Bug Tracker & Wiki]

#23319: hs: Memory leak in test hs_descriptor/decode_bad_signature
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  test, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by nickm):

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


Comment:

 lgtm; wfm; merging!

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

Re: [tor-bugs] #23319 [Core Tor/Tor]: hs: Memory leak in test hs_descriptor/decode_bad_signature

[Tor Bug Tracker & Wiki]

#23319: hs: Memory leak in test hs_descriptor/decode_bad_signature
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, tor-hs  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * status:  assigned => merge_ready


Comment:

 Branch: `bug23319_032_01`

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

[tor-bugs] #23319 [Core Tor/Tor]: hs: Memory leak in test hs_descriptor/decode_bad_signature

[Tor Bug Tracker & Wiki]

#23319: hs: Memory leak in test hs_descriptor/decode_bad_signature
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  test, tor-hs
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  SponsorR-must  |
---+
 Trivial fix.

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

Re: [tor-bugs] #22497 [Core Tor/Tor]: Clean-up tt_assert() usage in our tests

[Tor Bug Tracker & Wiki]

#22497: Clean-up tt_assert() usage in our tests
-+
 Reporter:  ahf  |  Owner:  ahf
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  review-group-18  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+
Changes (by nickm):

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


Comment:

 Okay.  Now that the hidden service patches are in, I'm no longer scared to
 merge this.  I split this branch up a little, in a new branch called
 ahf_bug22497_redux.  It has the same patches and scripts as the previous
 version, but I regenerated the C changes based on the latest master.

 Thanks, ahf!

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

Re: [tor-bugs] #17242 [Core Tor/Tor]: prop224: Implement client support

[Tor Bug Tracker & Wiki]

#17242: prop224: Implement client support
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs, prop224, review-group-22  |  Actual Points:
Parent ID:  #12424| Points:  parent
 Reviewer:  nickm |Sponsor:  SponsorR-
  |  must
--+
Changes (by dgoulet):

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


Comment:

 It is upstream! Lagavulin 16 for everyone! :)

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

Re: [tor-bugs] #17520 [Core Tor/Tor]: Relax the rend cache failure cleanup timer

[Tor Bug Tracker & Wiki]

#17520: Relax the rend cache failure cleanup timer
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, prop224  |  Actual Points:
Parent ID:  #23300   | Points:  1
 Reviewer:   |Sponsor:  SponsorR-can
-+-
Changes (by dgoulet):

 * parent:  #17242 => #23300


Comment:

 {{{
   rend_cache_failure_clean(now);
   hs_cache_client_intro_state_clean(now);
 }}}

 ... is called every 30 seconds actually which is done by
 `rend_cache_failure_clean_callback()`.

 1) Cleanup any entry that expired at lookup.
 2) v2 entries expire after 5 minutes. and v3 after 2 minutes.

 So, calling the callback every 2 minutes could be what we want to fit both
 use case *OR* we bring down to 2 minutes the 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] #23130 [Core Tor/Tor]: prop224: Synchronize spec with implementation (August 2017)

[Tor Bug Tracker & Wiki]

#23130: prop224: Synchronize spec with implementation (August 2017)
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224 tor-hs tor-spec  |  Actual Points:
Parent ID:  #23300   | Points:  0.4
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by dgoulet):

 * parent:  #17242 => #23300


Comment:

 Switching parent to client side issues 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] #23019 [Core Tor/Tor]: prop224: Validate received onion addresses on the client side

[Tor Bug Tracker & Wiki]

#23019: prop224: Validate received onion addresses on the client side
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * parent:  #17242 => #23300


Comment:

 Switching parent to client side issues 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] #21858 [Core Tor/Tor]: prop224: Client rendezvous point establishment

[Tor Bug Tracker & Wiki]

#21858: prop224: Client rendezvous point establishment
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #17242   | Points:  6
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

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


Comment:

 Done in #17242.

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

Re: [tor-bugs] #21857 [Core Tor/Tor]: prop224: Client introduction point establishment

[Tor Bug Tracker & Wiki]

#21857: prop224: Client introduction point establishment
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #17242   | Points:  6
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

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


Comment:

 Done in #17242.

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

Re: [tor-bugs] #21856 [Core Tor/Tor]: prop224: Client introduction point failure cache

[Tor Bug Tracker & Wiki]

#21856: prop224: Client introduction point failure cache
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #17242   | Points:  2
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

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


Comment:

 Done in #17242.

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

Re: [tor-bugs] #21403 [Core Tor/Tor]: prop224: Implement HS descriptor fetching

[Tor Bug Tracker & Wiki]

#21403: prop224: Implement HS descriptor fetching
-+
 Reporter:  haxxpop  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #17242   | Points:  7
 Reviewer:   |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

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


Comment:

 All done in #17242 which was just 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] #20371 [Core Tor/Tor]: Lower HSDir query backoff delay

[Tor Bug Tracker & Wiki]

#20371: Lower HSDir query backoff delay
---+--
 Reporter:  twim   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, research, prop224  |  Actual Points:
Parent ID:  #23300 | Points:
 Reviewer: |Sponsor:  SponsorR-can
---+--
Changes (by dgoulet):

 * parent:  #17242 => #23300


Comment:

 Switching parent for client side issues.

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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  path-selection  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

 * keywords:   => path-selection
 * priority:  Medium => High
 * cc: mikeperry (added)
 * milestone:   => Tor: 0.3.2.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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 I think in original code 0.5 contradicts to tor_llround(), it should be
 (int64_t)(weight*this_bw + 0.5) or tor_llround(weight*this_bw)

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

Re: [tor-bugs] #3733 [Core Tor/Tor]: Tor should abandon rendezvous circuits that cause a client request to time out

[Tor Bug Tracker & Wiki]

#3733: Tor should abandon rendezvous circuits that cause a client request to 
time
out
-+-
 Reporter:  rransom  |  Owner:  dgoulet
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, tor-client  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+-
Changes (by dgoulet):

 * parent:  #17242 => #23300


Comment:

 Switching parent so we can close #17242.

 (Only speaking v3):

 `CIRCUIT_PURPOSE_C_ESTABLISH_REND` is handled properly, if it's open and
 passes its cutoff, it will get expired.

 `CIRCUIT_PURPOSE_C_REND_READY` is '''not''' handled properly I believe. An
 intro and rend circuit are linked together when the client sends an
 INTRODUCE1 cell that is when the `rendezvous_cookie` is copied from the
 rend circuit `hs_ident` to the intro circuit one. Once they are linked
 together, the rend circuit is closed by any error on the intro circuit
 side.

 `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED` is handled properly, same exact
 cutoff check as the establish rend purpose but then it is flagged has
 `hs_circ_has_timed_out`.

 So all in all, we need to handle correctly the rend ready purpose for a v3
 service and we should have this 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] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * component:  - Select a component => Core Tor/Tor


Comment:

 
[https://gitweb.torproject.org/tor.git/commit/src/or/routerlist.c?id=e106812a778f53760c819ab20a214ac3222b3b15
 Original code]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23318 [- Select a component]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This extra 0.5 leads to non-zero probability to bypass bandwidth weights
 limitations. Like to pick Exit+Guard as Guard while there are not enough
 bandwidth.

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

Re: [tor-bugs] #22605 [Core Tor/Tor]: sandbox_intern_string(): Bug: No interned sandbox parameter found for /etc/tor/torrc.d/

[Tor Bug Tracker & Wiki]

#22605: sandbox_intern_string(): Bug: No interned sandbox parameter found for
/etc/tor/torrc.d/
-+
 Reporter:  toralf   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 I gave it a shot here: `bug22605_031_01`

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

Re: [tor-bugs] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #12898| Points:
 Reviewer:|Sponsor:
--+

Comment (by neel):

 Hi,

 I have created a patch 0001-networkstatus_nickname_is_unnamed.patch​ which
 removes networkstatus_nickname_is_unnamed(), the named_flag and
 unnamed_flag, and checks for Named and Unnamed flags.

 Please tell me what you think of this patch.

 Thanks,

 Neel Chauhan

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

Re: [tor-bugs] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #12898| Points:
 Reviewer:|Sponsor:
--+

Comment (by neel):

 BTW, I did not remove is_named and is_unnamed as I saw more code using
 these variables, so I did not want to mess with 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] #22215 [Core Tor/Tor]: networkstatus_nickname_is_unnamed() can get ripped out

[Tor Bug Tracker & Wiki]

#22215: networkstatus_nickname_is_unnamed() can get ripped out
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #12898| Points:
 Reviewer:|Sponsor:
--+
Changes (by neel):

 * Attachment "0001-networkstatus_nickname_is_unnamed.patch" added.

 Patch to remove networkstatus_nickname_is_unnamed(), as well as named_flag
 and unnamed_flag, and checks for Named and Unnamed flags

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

Re: [tor-bugs] #20375 [Applications/Tor Browser]: warn users when entering fullscreen

[Tor Bug Tracker & Wiki]

#20375: warn users when entering fullscreen
-+-
 Reporter:  fem  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-fingerprinting,   |  Actual Points:
  tbb-torbutton, TorBrowserTeam201708R   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Sorry -- no new code. I just thought we should somehow mark this ticket as
 a candidate for backporting. Is there a preferred way to do 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] #21905 [Applications/Tor Browser]: Allow third-party cookies as we are isolating them to the first party in ESR52

[Tor Bug Tracker & Wiki]

#21905: Allow third-party cookies as we are isolating them to the first party in
ESR52
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, ff52-esr  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by pastly):

 pastly said more things on IRC.

 {{{
 [18:08:23]  Some guy that was really really sure of himself kept
 asserting that '3rd party' cookies aren't always third party or could
 somehow still be sent depending on special flags in a JavaScript request
 function. Idk. I made a PoC and tested with FF, Chrome, and TB. But think
 found that JS func and gave up trying to figure out if I was right or if
 he
 was right.
 [18:08:47]  s/But think found/but then I found/
 [18:09:40] 
 https://developer.mozilla.org/en-
 US/docs/Web/API/XMLHttpRequest/withCredent
 ials
 [18:10:08]  I guess it allows 3rd party cookies to be sent as long
 as the sites are colluding with Access-Control-Allow-Origin
 [18:11:00]  I would guess that an ad site might ask the browser
 to request the first party site in such a way that passes information such
 that the first party deposits a cookie that contains information from the
 ad site.
 [18:11:28]  is that what ACAO does?
 [18:11:41]  Dunno. I stopped thinking about it. :p
 }}}

 This may not be new to you smart browser people.

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

Re: [tor-bugs] #23314 [Core Tor/Stem]: `make test-stem` starts up tor on 9050: Address already in use

[Tor Bug Tracker & Wiki]

#23314: `make test-stem` starts up tor on 9050: Address already in use
+
 Reporter:  asn |  Owner:  atagar
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Stem   |Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  tor-tests stem  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by atagar):

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


Comment:

 Oh wait, I did this months ago. You're simply out of date. ;)

 https://gitweb.torproject.org/stem.git/commit/?id=e35286dd

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by catalyst):

 The potential problem is less about omitting rare small values and more
 about missing lots of representable intermediate values.  I think with
 this kind of approach we're losing half of the representable values
 between 0.25 and 0.5-2^-52^; 3/4 of the possible values between 0.125 and
 0.25-2^-51^, etc., which was kind of the motivation for the Downey paper.
 We might decide we don't care, but I think that's highly dependent on what
 the caller ends up doing with the results.  (We should also document this
 choice; the comment currently focuses on small rare values instead of
 "holes" in the range.)

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

Re: [tor-bugs] #23304 [Core Tor/Tor]: prop224: Dump a malformed descriptor in a file and log_warn about it

[Tor Bug Tracker & Wiki]

#23304: prop224: Dump a malformed descriptor in a file and log_warn about it
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 Yeah... I'm uncertain also about this one... And even having the malformed
 descriptor, chances are that a non malicious tor created it are slim. Not
 sure I even saw that in v2 in the wild...

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

Re: [tor-bugs] #23309 [Core Tor/Tor]: hs: We need to get rid of a descriptor when entering non-overlap mode

[Tor Bug Tracker & Wiki]

#23309: hs: We need to get rid of a descriptor when entering non-overlap mode
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 All good with latest fixup. 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] #23314 [Core Tor/Stem]: `make test-stem` starts up tor on 9050: Address already in use

[Tor Bug Tracker & Wiki]

#23314: `make test-stem` starts up tor on 9050: Address already in use
+
 Reporter:  asn |  Owner:  atagar
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Stem   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-tests stem  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+

Comment (by atagar):

 Hi asn, thanks for pointing this out! Actually, Stem is *trying* to use a
 non-standard port but tor's ignoring it...

 "Aug 24 14:20:28.567 [warn] Skipping obsolete configuration option
 'SocksListenAddress'"
 https://www.torproject.org/docs/tor-manual.html.en#SocksListenAddress
 https://gitweb.torproject.org/stem.git/tree/test/runner.py#n60

 Simple to fix.

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

Re: [tor-bugs] #23317 [Applications/Tor Browser]: Update font whitelists to reflect any changed Firefox default fonts

[Tor Bug Tracker & Wiki]

#23317: Update font whitelists to reflect any changed Firefox default fonts
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting, ff59-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> Masayuki Nakano writes (about Windows fonts):
>
> > We decided that we should change our default Japanese fonts from legacy
> "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap
> glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho"
> (serif).
>
> We should update "font.system.whitelist" to reflect this. We should also
> check if any other default fonts have been added that we should include
> in our whitelists.

New description:

 Masayuki Nakano writes (about Windows fonts):

 > We decided that we should change our default Japanese fonts from legacy
 "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap glyph
 to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho" (serif).

 We should consider updating "font.system.whitelist" to reflect this,
 although it depends on what fonts are available by default on most Windows
 systems. We should also check if any other default fonts have been added
 that we should include in our whitelists.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23317 [Applications/Tor Browser]: Update font whitelists to reflect any changed Firefox default fonts

[Tor Bug Tracker & Wiki]

#23317: Update font whitelists to reflect any changed Firefox default fonts
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-fingerprinting,
 Severity:  Normal   |  ff59-esr
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Masayuki Nakano writes (about Windows fonts):

 > We decided that we should change our default Japanese fonts from legacy
 "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap glyph
 to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho" (serif).

 We should update "font.system.whitelist" to reflect this. We should also
 check if any other default fonts have been added that we should include in
 our whitelists.

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

Re: [tor-bugs] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * Attachment "Tor_Project_Document_Template.odt" 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] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * Attachment "Tor_Project_Report_Template.odt" 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] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * Attachment "Tor-Project-Presentation-Template.odp" 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] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * Attachment "Tor-Project-Presentation-Template.pptx" added.


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

[tor-bugs] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 There were issues with these templates I didn't notice

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

Re: [tor-bugs] #22688 [Core Tor/Tor]: Make sure HSDir3s never know service, client, or bridge IP addresses

[Tor Bug Tracker & Wiki]

#22688: Make sure HSDir3s never know service, client, or bridge IP addresses
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  prop224, relay-safety,   |  Actual Points:  0.3
  031-backport, maybe-030-backport-with-21406|
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 031 release approaches rapidly, moving this to 032. I think it's not
 critical to have in 031 but nice to have!

 @teor, re-assign if you think otherwise.

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

Re: [tor-bugs] #17242 [Core Tor/Tor]: prop224: Implement client support

[Tor Bug Tracker & Wiki]

#17242: prop224: Implement client support
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:
  |  merge_ready
 Priority:  Very High |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, review-group-22  |  Actual Points:
Parent ID:  #12424| Points:  parent
 Reviewer:  nickm |Sponsor:  SponsorR-
  |  must
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ok, squashed branch is in: `ticket17242_032_03-squashed`

 Git diff with `ticket17242_032_03` is empty.

 Test passes as well as integration test with chutney and real network.

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

Re: [tor-bugs] #22348 [Core Tor/Tor]: 16 relays have mismatched rsa/ed keys currently

[Tor Bug Tracker & Wiki]

#22348: 16 relays have mismatched rsa/ed keys currently
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-22  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Good question. There isn't really much options actually other than doing
 something like "rm keys/*" and restart tor? Or put back the backed up keys
 in keys/ ?

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

Re: [tor-bugs] #21509 [Core Tor/Tor]: Fuzz v3 hidden services

[Tor Bug Tracker & Wiki]

#21509: Fuzz v3 hidden services
---+
 Reporter:  teor   |  Owner:  dgoulet
 Type:  task   | Status:  accepted
 Priority:  Very High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  fuzz, prop224, tor-hs  |  Actual Points:
Parent ID: | Points:  2
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by dgoulet):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 I've done some initial fuzzing for the descriptor encoding/decoding. More
 is needed for service and client in 032. Moving this out of 031 milestone.

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

Re: [tor-bugs] #23163 [Core Tor/Tor]: Wrong name for new tor config options

[Tor Bug Tracker & Wiki]

#23163: Wrong name for new tor config options
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  tor-config|  Actual Points:
Parent ID:  #12541| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:   => tor-config
 * parent:   => #12541
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 Putting the KIST ticket as parent because it's possible they get changed
 or something.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by yawning):

 Replying to [comment:21 nickm]:
 > Okay, I've tried it out, and gotten some results.  Apparently when
 Yawning's code above is used, Teor's tests no longer report that 53 bits
 of mantissa are set -- only 52 bits are set.  I think this is okay, but
 can we do better?  See branch here for more: `feature23061_v2_yawning`.

 The routine I provided has this property on "sane" systems:

   `uint64_to_dbl_0_1(1) == 1.1102230246251565e-16 /* 2^-53 */`

 I don't think anything more is actually useful.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by cypherpunks):

 https://stackoverflow.com/questions/1340729/how-do-you-generate-a-random-
 double-uniformly-distributed-between-0-and-1-from-c

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

Re: [tor-bugs] #23309 [Core Tor/Tor]: hs: We need to get rid of a descriptor when entering non-overlap mode

[Tor Bug Tracker & Wiki]

#23309: hs: We need to get rid of a descriptor when entering non-overlap mode
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet
 * sponsor:   => SponsorR-must


Comment:

 Couple of comments.

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by catalyst):

 If we want more entropy than `DBL_MANT_DIG` we could look at the exponent
 to decide how many bits to mask when adding the last chunk of randomness,
 but of course that might not be constant time.  (I'm not sure we can
 assume basic floating point arithmetic will be constant time, so we might
 not care.)

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

Re: [tor-bugs] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by catalyst):

 Replying to [comment:21 nickm]:
 > I tried the ldexp() trick too, but that fails the test that
 `uint64_to_dbl_0_1(UINT64_MAX) < 1.0` if have all four ldexp() calls.  If
 I remove the lowest-magnitude one, it's fine, but of course we only get 48
 bits.
 Oh right, it'll round off the bits past `DBL_MANT_DIG`.  Maybe mask off
 all but the high 5 bits?

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

Re: [tor-bugs] #22779 [Core Tor/Tor]: choose_good_entry_server() is no longer used to choose entry guards

[Tor Bug Tracker & Wiki]

#22779: choose_good_entry_server() is no longer used to choose entry guards
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  maybe-030-backport, review-group-22  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-

Comment (by asn):

 ACKing this as well.

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

Re: [tor-bugs] #23309 [Core Tor/Tor]: hs: We need to get rid of a descriptor when entering non-overlap mode

[Tor Bug Tracker & Wiki]

#23309: hs: We need to get rid of a descriptor when entering non-overlap mode
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 Opened MR here: https://oniongit.eu/asn/tor/merge_requests/5

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

Re: [tor-bugs] #23312 [Internal Services/Service - git]: Please create tor-browser-bundle repo under user/isis on git.tpo

[Tor Bug Tracker & Wiki]

#23312: Please create tor-browser-bundle repo under user/isis on git.tpo
-+
 Reporter:  isis |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Isis, do you still want this repo, or something different?

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

Re: [tor-bugs] #21816 [Core Tor/Tor]: Add support for Pluggable Transports 2.0

[Tor Bug Tracker & Wiki]

#21816: Add support for Pluggable Transports 2.0
-+-
 Reporter:  chelseakomlo |  Owner:
 |  dasyatid1
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-pt tor-bridge design  |  Actual Points:
  pt2|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dasyatid1):

 * status:  new => assigned
 * owner:  (none) => dasyatid1
 * cc: dasyatid1 (added)


Comment:

 As I posted on tor-dev a little while ago, I've been working on a patchset
 for this as part of work I've been doing with blanu / Operator. This is
 available at Bitbucket ([https://bitbucket.org/DasyatidPrime/tor-
 rtt2017-21816.git Git], [https://bitbucket.org/DasyatidPrime/tor-
 rtt2017-21816/src Web]).

 With commit 887352263569, I've completed successful circuits through the
 "rtt2017" [https://github.com/OperatorFoundation/shapeshifter-
 dispatcher/tree/rtt2017 branch of shapeshifter-dispatcher] and
 [https://github.com/OperatorFoundation/shapeshifter-ipc/tree/rtt2017
 associated shapeshifter-ipc] using PT2 configuration protocol (there are
 changes there I still want to upstream), and through obfs4proxy using PT1,
 each acting as an obfs4 client for connecting via a bridge.

 I'd like to hear what would be necessary to merge a version of this.
 Currently on my radar: unit tests for JSON/RFC1929 encoding functions,
 'changes' documentation, possibly commit-level cleanup, possibly pushing
 on PT spec and/or Shapeshifter upstream to lock them down. I'm probably
 missing something, though. There are some other details in my
 [https://lists.torproject.org/pipermail/tor-dev/2017-August/012411.html
 original post to tor-dev].

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

Re: [tor-bugs] #23215 [Metrics/CollecTor]: set annotation from descriptor during sync-runs

[Tor Bug Tracker & Wiki]

#23215: set annotation from descriptor during sync-runs
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  accepted => 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] #23215 [Metrics/CollecTor]: set annotation from descriptor during sync-runs

[Tor Bug Tracker & Wiki]

#23215: set annotation from descriptor during sync-runs
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Please take a look at the two commits on top of
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-23215
 this branch].

 When the change and test data make sense I'll add more test data with
 currently valid annotations and the corresponding changelog entry.

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

Re: [tor-bugs] #23267 [Applications/Tor Browser]: Cross-platform brand and features consistency: make Android and iOS browsers as good as TBB

[Tor Bug Tracker & Wiki]

#23267: Cross-platform brand and features consistency: make Android and iOS
browsers as good as TBB
--+--
 Reporter:  linda |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:36 gk]:
 > Shipping HTTPS-Everywhere based on the new WebExtensions model broke its
 > functionality on higher security levels as our JavaScript blocking does
 > not whitelist moz-extension: which is needed.
 Shipping NoScript as our JavaScript blocking on higher security levels
 does not whitelist `moz-extension:` which is needed and broke
 functionality of HTTPS-Everywhere based on the new WebExtensions model.
 > It turns out that vanilla Firefox 52 ESR is affected as well but
 differently:
 > Backorting https://bugzilla.mozilla.org/show_bug.cgi?id=1329731 does not
 help
 > us as NoScript is regulating JavaScript related things.
 Remove as irrelevant.

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

Re: [tor-bugs] #23267 [Applications/Tor Browser]: Cross-platform brand and features consistency: make Android and iOS browsers as good as TBB

[Tor Bug Tracker & Wiki]

#23267: Cross-platform brand and features consistency: make Android and iOS
browsers as good as TBB
--+--
 Reporter:  linda |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by linda):

 * owner:  (none) => tbb-team
 * component:  - Select a component => 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] #23061 [Core Tor/Tor]: crypto_rand_double() should produce all possible outputs on platforms with 32-bit int

[Tor Bug Tracker & Wiki]

#23061: crypto_rand_double() should produce all possible outputs on platforms 
with
32-bit int
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.14-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:  0.5
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 027-backport-maybe, 026   |
  -backport-maybe, review-group-22   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by nickm):

 Okay, I've tried it out, and gotten some results.  Apparently when
 Yawning's code above is used, Teor's tests no longer report that 53 bits
 of mantissa are set -- only 52 bits are set.  I think this is okay, but
 can we do better?  See branch here for more: `feature23061_v2_yawning`.

 I tried the ldexp() trick too, but that fails the test that
 `uint64_to_dbl_0_1(UINT64_MAX) < 1.0` if have all four ldexp() calls.  If
 I remove the lowest-magnitude one, it's fine, but of course we only get 48
 bits.

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  TorBrowserTeam201708R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  assigned => needs_review
 * keywords:  TorBrowserTeam201708 => TorBrowserTeam201708R


Comment:

 See: https://oniongit.eu/gk/tor-browser-bundle/merge_requests/4 for a
 patch up for review.

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

Re: [tor-bugs] #23309 [Core Tor/Tor]: hs: We need to get rid of a descriptor when entering non-overlap mode

[Tor Bug Tracker & Wiki]

#23309: hs: We need to get rid of a descriptor when entering non-overlap mode
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #22348 [Core Tor/Tor]: 16 relays have mismatched rsa/ed keys currently

[Tor Bug Tracker & Wiki]

#22348: 16 relays have mismatched rsa/ed keys currently
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-22  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Hm. Any ideas what that should say? The problem is that the right fix
 depends on the user's situation.

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

Re: [tor-bugs] #23106 [Core Tor/Tor]: Audit code for swapped ntoh*/hton* calls

[Tor Bug Tracker & Wiki]

#23106: Audit code for swapped ntoh*/hton* calls
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  review-group-22  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 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] #23149 [Core Tor/Tor]: Refactor buffer.c: split and rename functions.

[Tor Bug Tracker & Wiki]

#23149: Refactor buffer.c: split and rename functions.
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-22  |  Actual Points:  .2
Parent ID:  #22342   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 That's mostly code movement, but sure!  Here you go:

 https://oniongit.eu/nickm/tor/merge_requests/5

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

Re: [tor-bugs] #23309 [Core Tor/Tor]: hs: We need to get rid of a descriptor when entering non-overlap mode

[Tor Bug Tracker & Wiki]

#23309: hs: We need to get rid of a descriptor when entering non-overlap mode
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 Pushed fixes for this in `bug23309`.

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

Re: [tor-bugs] #19281 [Core Tor/Tor]: Potential heap corruption via `write_escaped_data` in control.c

[Tor Bug Tracker & Wiki]

#19281: Potential heap corruption via `write_escaped_data` in control.c
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bug-bounty, heap-correctness,|  Actual Points:
  disaster-waiting-to-happen, review-group-22|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

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


Comment:

 Yeah, I don't think this can happen either, but guido has a pretty good
 track record, and we might as well fix all the stuff he found.  Code
 that's harmless today can become harmful tomorrow if somebody changes it
 or copies under the assumption that it was correct to start with.

 Merging to 0.3.2, no backport.

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

Re: [tor-bugs] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  sandbox, review-group-22  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
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] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox, review-group-22  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 fixed, squashed, 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] #22976 [Core Tor/Tor]: disallow tor exec'ing

[Tor Bug Tracker & Wiki]

#22976: disallow tor exec'ing
--+
 Reporter:  dawuud|  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox, review-group-22  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Replying to [comment:10 dgoulet]:
 > >  This isn't fundamentally about seccomp; it's about disabling
 functionality. Our sandbox already disables all exec calls.
 >
 > Not sure it does... All the exeve() calls are disabled by `#if 0`.

 Ah, but that code is for _enabling_ execve.  Unless a syscall is
 specifically enabled, the sandbox code doesn't allow it.

 > The changes file has this weird sentence:
 >
 > {{{
 > - Added a new NoExec option to . When this option is set to 1,
 > }}}

 Oops. Will fix.

 > Apart from that, lgtm;

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

Re: [tor-bugs] #22779 [Core Tor/Tor]: choose_good_entry_server() is no longer used to choose entry guards

[Tor Bug Tracker & Wiki]

#22779: choose_good_entry_server() is no longer used to choose entry guards
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  maybe-030-backport, review-group-22  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

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


Comment:

 merged to 0.3.2; I think we don't need to backport.

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

Re: [tor-bugs] #22677 [Core Tor/Tor]: Document that Sandbox 1 requires linux and seccomp2.

[Tor Bug Tracker & Wiki]

#22677: Document that Sandbox 1 requires linux and seccomp2.
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  documentation, trivial, review-  |  Actual Points:
  group-22   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 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] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

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

Comment (by iwakeh):

 Please also merge [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22983-2=e8e783d3a9ae4e220e70fbd14240d0979672ac2a
 this commit] to current master, to avoid [https://metrics.torproject.org
 /metrics-lib/index.html?org/torproject/descriptor/internal/package-
 summary.html javadoc for package 'internal'] on the metrics.tp.o web site.

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

Re: [tor-bugs] #23205 [Internal Services/Tor Sysadmin Team]: Grant hiro access to civi

[Tor Bug Tracker & Wiki]

#23205: Grant hiro access to civi
-+
 Reporter:  jselon   |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 Hiro, here's your password.

 https://volatile.noreply.org/2017-08-24-A3Hu8Pvpqc8/hiro

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23315 [Internal Services/Tor Sysadmin Team]: Please set up a Windows 10-64 QA machine for Tor Browser related things

[Tor Bug Tracker & Wiki]

#23315: Please set up a Windows 10-64 QA machine for Tor Browser related things
-+-
 Reporter:  gk   |  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:   |
-+-
 While talking about a new TBB build machine (#22764) the topic of a
 Windows QA machine came up as well. It seems we have a plan, see the
 thread: "Windows QA machine (was: Setting up a VM on eclipsis HKG for TBB
 team)".

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

Re: [tor-bugs] #22841 [Internal Services/Tor Sysadmin Team]: Fix donate-amazon page on the website

[Tor Bug Tracker & Wiki]

#22841: Fix donate-amazon page on the website
-+-
 Reporter:  hiro |  Owner:  hiro
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 We also have to allow the  following src:

 * api-cdn.amazon.com

 * payments.amazon.com

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

Re: [tor-bugs] #22764 [Internal Services/Tor Sysadmin Team]: New TBB build machine?

[Tor Bug Tracker & Wiki]

#22764: New TBB build machine?
-+-
 Reporter:  mikeperry|  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 The relevant thread is "Setting up a VM on eclipsis HKG for TBB team".

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

Re: [tor-bugs] #23133 [Internal Services/Tor Sysadmin Team]: Use .onion more. Redirect traffic to .onion if the user come from Tor.

[Tor Bug Tracker & Wiki]

#23133: Use .onion more. Redirect traffic to .onion if the user come from Tor.
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23314 [Core Tor/Stem]: `make test-stem` starts up tor on 9050: Address already in use

[Tor Bug Tracker & Wiki]

#23314: `make test-stem` starts up tor on 9050: Address already in use
---+
 Reporter:  asn|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  tor-tests stem
Actual Points: |  Parent ID:
   Points:  0.1|   Reviewer:
  Sponsor: |
---+
 I tried to run the little-t-tor stem tests using `make test-stem`. The
 unittests finished successfuly but all the integration tests failed
 because stem couldn't start up tor. It was trying to launch tor with a
 socksport on 9050 but it was failing because my system tor was already
 occupying that port:

 {{{
 ==
   INTEGRATION TESTS
 ==

 Setting up a test instance...
   making test directory (/home/f/Computers/tor/stem/test/data)... done
   configuring logger (/home/f/Computers/tor/stem/test/data/log)... done
   writing torrc (/home/f/Computers/tor/stem/test/data/torrc)... done
 # configuration for stem integration tests
 DataDirectory /home/f/Computers/tor/stem/test/data
 SocksListenAddress 127.0.0.1:1112
 DownloadExtraInfo 1
 Log notice stdout
 Log notice file /home/f/Computers/tor/stem/test/data/tor_log

 Starting ./src/or/tor...

   Aug 24 14:20:28.564 [notice] Tor 0.3.2.0-alpha-dev (git-
 40acdc357e08ab03) running on Linux with Libevent 2.0.21-stable, OpenSSL
 1.0.1t, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
   Aug 24 14:20:28.564 [notice] Tor can't help you if you use it wrong!
 Learn how to be safe at
 https://www.torproject.org/download/download#warning
   Aug 24 14:20:28.564 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
   Aug 24 14:20:28.564 [notice] Read configuration file
 "/home/f/Computers/tor/stem/test/data/torrc".
   Aug 24 14:20:28.567 [warn] Skipping obsolete configuration option
 'SocksListenAddress'
   Aug 24 14:20:28.567 [notice] Opening Socks listener on 127.0.0.1:9050
   Aug 24 14:20:28.567 [warn] Could not bind to 127.0.0.1:9050: Address
 already in use. Is Tor already running?
   Aug 24 14:20:28.567 [warn] Failed to parse/validate config: Failed to
 bind one of the listener ports.
   Aug 24 14:20:28.567 [err] Reading config failed--see warnings above.
   failed to start tor: Process terminated: Failed to bind one of the
 listener ports.


 Shutting down tor... done
 }}}

 I think stem should start up tor on a different non-default port, or just
 use `SocksPort auto`.

 Cheers!

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

Re: [tor-bugs] #23299 [Applications/Tor Browser]: Crash when trying to save a PDF in Tor Browser

[Tor Bug Tracker & Wiki]

#23299: Crash when trying to save a PDF in Tor Browser
--+---
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Let's close this as a duplicate of #22471. I believe the underlying issue
 is the same. We are currently testing a fix for it in the alpha and hope
 to backport it soon.

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