Re: [tor-bugs] #26073 [Applications/Tor Browser]: patch tor-browser-build.git for Firefox 60 ESR

[Tor Bug Tracker & Wiki]

#26073: patch tor-browser-build.git for Firefox 60 ESR
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201805, ff60-esr  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 igt0: Could you point me to the branch for this ticket I should 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] #25156 [Core Tor/Tor]: Stop duplicating static strings between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Stop duplicating static strings between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 > Also, duplicating strings costs RAM, so de-duplicating will save us RAM.

 This isn't true: we only compile the C module or the Rust module, not
 both.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26198 [Applications/Tor Browser]: Review WebGL mitigations

[Tor Bug Tracker & Wiki]

#26198: Review WebGL mitigations
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should review Firefox's existing WebGL patch and see if we have
 sufficient protections.

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

Re: [tor-bugs] #25544 [Core Tor/Tor]: Complete vanguard specification

[Tor Bug Tracker & Wiki]

#25544: Complete vanguard specification
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, torspec, guard-   |  Actual Points:
  discovery, 034-roadmap-master, |
  034-triage-20180328, 034-included-20180328 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Looks good!

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

Re: [tor-bugs] #26158 [Core Tor/Tor]: A little bug of circular path of Tor

[Tor Bug Tracker & Wiki]

#26158: A little bug of circular path of Tor
-+-
 Reporter:  TBD.Chen |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  circular-path, security-low, |  Actual Points:
  031-backport, 032-backport, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by TBD.Chen):

 So that's it! Thank you for the explanation!
 I have seen the modification, I think it is enough to remove the hidden
 danger.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26197 [Internal Services/Service - git]: Sync git.torproject.org/stem.git to github.com/torproject/stem.git

[Tor Bug Tracker & Wiki]

#26197: Sync git.torproject.org/stem.git to github.com/torproject/stem.git
-+
 Reporter:  teor |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Hi,

 Can you please create a stem repository at github.com/torproject/stem.git
 and make tor-bot (?) sync it from git.torproject.org/stem.git ?

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

Re: [tor-bugs] #26073 [Applications/Tor Browser]: patch tor-browser-build.git for Firefox 60 ESR

[Tor Bug Tracker & Wiki]

#26073: patch tor-browser-build.git for Firefox 60 ESR
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201805, ff60-esr  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by igt0):

 * 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] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff60-esr, tbb-torbutton, TorBrowserTeam201805 => ff60-esr,
 tbb-torbutton, TorBrowserTeam201805R


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

Re: [tor-bugs] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review


Comment:

 Here's a revised branch for review:
 https://github.com/arthuredelstein/torbutton/commits/26100+11
 (482abfb95de85bce98043338d8f7fcad9f6b7845)

 Details of the revision follow:

 Replying to [comment:8 gk]:
 > Okay, this works for me, nice! Here comes a first batch of review
 comments (sorry, I have to split this up as I must switch context but
 wanted you to give some feedback to already work on):
 >
 > commit 1eafafefd2dfb6006f9f2686e6ecb591da8bc434
 >
 > Adding a hint to the underlying Mozilla bug
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414390) to the commit
 message would be good I think.

 Done.

 > commit 629f58cfffefb3f58ceab7275e0f1e1194a6f012
 >
 > Is that new that `catch` statements can't have `if` statements anymore?

 Yes -- I added a link to the bugzilla bug.

 > commit 9c3e58597f3f3c41af2d44ae809a652c3a7d91a7
 >
 > Could you move the moz- removals in this bug to the previous commit?

 Done.

 > I don't understand your `plugin.disable` related commit/code change.
 It's not set by Mozilla code in ESR52 either. We are setting it in our own
 pref file we ship with the browser. Thus, it seems to me setting it here
 is not necessary?

 This was a leftover from mobile work and has been removed.

 > What speaks against using `getBrowser()`? It's cheaper to use
 `window.gBrowser`?

 igt0 noticed in base/content/browser.js:
 {{{
 function getBrowser() {
return gBrowser;
 }
 /* DEPRECATED */
 }}}

 > Starting with "1." in the commit message without a "2." seems weird. :)
 Could you add more stuff as you seemed to want or reword that part?

 Reworded.

 > commit ec0e146668a817954ee75b78216151830e626ebc
 >
 > Please do a
 > {{{
 > const Cu = Components.utils;
 > }}}
 > and use `Cu` in `cookie-jar-selector.js`

 Done.

 > {{{
 > +  //Services.console.logStringMessage(`getPrefValue(${prefName})`);
 > }}}
 > No need for this commented out log statement

 Removed.

 > {{{
 > +   this.logmethod = 2;
 > }}}
 > Why is that needed?

 Removed.

 > There are two additional new lines in `startup-observer.js` which are
 not needed.

 Removed.

 > Re the pref loading:
 >
 > 1) Speaks anything against having that in utils.js instead of creating a
 new module?

 I'm inclined to have a separate module because, unlike the function in
 utils.js, this function uniquely needs to run before most other code. But
 I don't feel too strongly.

 > 2) I think we should set the prefs on the default prefs branch as it is
 done right now. That allows the user easily see which preferences got
 modified by themselves/the browser and more importantly there is the
 option to return to save defaults. tor-launcher's
 949379555010a04633c64b08ed52896a86c2cce6 might give some inspiration.

 Good point! I think I have fixed this.

 Replying to [comment:9 gk]:
 [snip]
 > c1f2c1f79d334c43ffdbd598312d5de2e3b54a34
 >
 > "tor button" -> "Torbutton"
 [snip]

 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] #25939 [Core Tor/Tor]: A Tor commit seems to have broken creation of V3 onion services with stem

[Tor Bug Tracker & Wiki]

#25939: A Tor commit seems to have broken creation of V3 onion services with 
stem
+--
 Reporter:  maqp|  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  High|  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Major   | Resolution:
 Keywords:  034-must regression tor-hs  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by maqp):

 dgoulet: Confirming the fix works for me
 [https://gist.github.com/maqp/78978698493ea41903005e40a7eaf059 (bash
 script)].

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

Re: [tor-bugs] #25975 [Applications/Tor Browser]: Get a rust cross-compiler for macOS

[Tor Bug Tracker & Wiki]

#25975: Get a rust cross-compiler for macOS
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201805R, GeorgKoppen201805R, |
  boklm201805|
Parent ID:  #25779   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 I didn't try to build it, but the patch looks good to me.

 One minor thing: the line `cat > $distdir/helper/x86_64-apple-darwin-clang
 << 'EOF'` and the comment before can be indented.

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

Re: [tor-bugs] #26175 [Applications/GetTor]: Support Experimental Tor Browser for Github Provider

[Tor Bug Tracker & Wiki]

#26175: Support Experimental Tor Browser for Github Provider
-+-
 Reporter:  iry  |  Owner:  ilv
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ilv):

 * priority:  Medium => Low
 * type:  defect => enhancement
 * severity:  Normal => Minor


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

Re: [tor-bugs] #26196 [Core Tor/Tor]: Abort in test_bridges.c

[Tor Bug Tracker & Wiki]

#26196: Abort in test_bridges.c
--+
 Reporter:  gvanem|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  crash, tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: catalyst (added)
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: 0.3.5.x-final


Comment:

 This is a bug that we should fix: we should never access a smart list
 index beyond the used values.

 But it's harmless in practice, because:
 * it's in the unit tests
 * smartlists are initialised with a minimum capacity of 16, and the
 allocation is zero-initialised
 * smartlist allocations never shrink
 * when elements are removed, the index is set to NULL

 To prevent bugs like this in future, we should make unit tests and fragile
 hardening set DEBUG_SMARTLIST.

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Stop duplicating static strings between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Stop duplicating static strings between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 If calling into C for strings costs too much CPU, we can generate the
 files at build time.
 Or, if we access the string many times, we can take a copy in Rust.

 Also, duplicating strings costs RAM, so de-duplicating will save us RAM.

 I'm not sure if either effect will be significant in practice.

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

Re: [tor-bugs] #26060 [Core Tor/Stem]: Invalid [Length] field when receiving RELAY cells via stem.client.Circuit

[Tor Bug Tracker & Wiki]

#26060: Invalid [Length] field when receiving RELAY cells via 
stem.client.Circuit
---+
 Reporter:  plcp   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi plcp, sorry about the delay and thanks for the catch! Stared at this a
 few hours and finally pushed a couple fixes. How does this look?

 https://gitweb.torproject.org/stem.git/commit/?id=72ba79d
 https://gitweb.torproject.org/stem.git/commit/?id=e3fab7b

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Stop duplicating static strings between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Stop duplicating static strings between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 Replying to [comment:6 teor]:
 > I think we should have one copy of strings (and other constants) across
 Rust and C, as much as possible.
 >
 > Let's make it a coding standard, and see how we go adopting it in
 protover?

 Yes I think that is a good idea. On one hand, removing duplication as much
 as possible is valuable. On the other hand, we'll need FFI calls for every
 static string (and we should look at the cost with string copying when
 moving across language boundaries). Either way it is messy but having a
 standard way of doing things will be helpful to managing
 complexity/possible bugs.

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Stop duplicating static strings between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Stop duplicating static strings between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I think we should have one copy of strings (and other constants) across
 Rust and C, as much as possible.

 Let's make it a coding standard, and see how we go adopting it in
 protover?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26196 [- Select a component]: Abort in test_bridges.c

[Tor Bug Tracker & Wiki]

#26196: Abort in test_bridges.c
--+--
 Reporter:  gvanem|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  crash, tests
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Running {{{test.exe bridges/clear_bridge_list}}} causes this assertion:

 {{{
   bridges/clear_bridge_list: May 23 17:12:53.714 [err]
 tor_assertion_failed_():
   Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed;

 }}}

 AFAICS, since {{{sweep_bridge_list()}}} caused all entries in
 {{{bridgelist}}} to get deleted, an index of zero is illegal. Don't ask me
 why.

 And since I compiled all {{{test/*.c}}} sources with
 {{{-DDEBUG_SMARTLIST}}}, this will trigger this abort(). I fail to see why
 this isn't done in the officially.
 \\

 PS1. I'm on Win-10, tor.exe + libs was built with MSVC 2017.
 \\
 PS2. Build tor.exe from master at 23 May 2018.

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Stop duplicating static strings between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Stop duplicating static strings between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 I agree about having a single source of truth for cases like static
 strings- if we do this for protover, we should make it a coding standard
 for all new Rust functionality? It would be nice to standardize our
 approach.

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

Re: [tor-bugs] #25156 [Core Tor/Tor]: Stop duplicating static strings between Rust and C

[Tor Bug Tracker & Wiki]

#25156: Stop duplicating static strings between Rust and C
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, memory-leaks, technical-debt,  |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #25895 [Core Tor/Tor]: Cross-compiling tor rust for Windows is broken

[Tor Bug Tracker & Wiki]

#25895: Cross-compiling tor rust for Windows is broken
-+-
 Reporter:  gk   |  Owner:  Hello71
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, 034-proposed, tbb-wants,   |  Actual Points:
  033-backport, 034-roadmap-proposed |
Parent ID:  #25849   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #26195 [Applications/Tor Browser]: Use new cctools in our macosx-toolchain project

[Tor Bug Tracker & Wiki]

#26195: Use new cctools in our macosx-toolchain project
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, ff60-esr,
 Severity:  Normal   |  TorBrowserTeam201805,
 |  GeorgKoppen201805
Actual Points:   |  Parent ID:  #24632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Solving #9711 gives us a new cctools which we should use in our macosx-
 toolchain project.

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

Re: [tor-bugs] #20350 [Metrics/CollecTor]: Replace create-tarball.sh shell script with Java module

[Tor Bug Tracker & Wiki]

#20350: Replace create-tarball.sh shell script with Java module
---+-
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  CollecTor 2.0.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:  #20518 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 The implementation should take the situation of #26193 into account and
 provide a solution, too.

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

[tor-bugs] #26194 [Internal Services/Service - git]: Create repository for user/sukhbir

[Tor Bug Tracker & Wiki]

#26194: Create repository for user/sukhbir
-+
 Reporter:  sukhbir  |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Hi. May I please have a repository for pushing my Tor Browser commits?
 Something like user/sukhbir/tor-browser-build. 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] #26035 [Metrics/Statistics]: Streamline sample quantile types used in the various modules

[Tor Bug Tracker & Wiki]

#26035: Streamline sample quantile types used in the various modules
+
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_revision
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  Sponsor13
+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:15 karsten]:
 > Replying to [comment:14 iwakeh]:
 > > Taking you up on your offer from comment:13, so I can concentrate on
 reviews and tickets of CollecTor.
 >
 > Alright, happy to implement this change.

 Thanks!

 >
 > Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-26035 my task-26035 branch] with three commits:
 >
 >  - [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26035=4f92894a1ee5315b9e4a17b38f3cdb229612f0f1
 4f92894] changes how we're computing median and inter-quartile range in
 the censorship detector code, which is still written in Python. I tested
 the change by running on our user number estimates. I found that it
 changes 159 of 2447 days in our data (6.5%) and leaves the remaining days
 entirely unchanged. This also makes sense: with a slightly different
 median and inter-quartile range we either include a value or exclude it as
 outlier. I'd say we cannot conclude that one of the implementations is
 correct and the other is not. The new implementation will simply be more
 consistent throughout our code base.

 This looks fine and will make it easier to transfer this into Java later.

 >
 >  - [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26035=2685c78f13cbf9402d5ba0b4380df03f246e86e5
 2685c78] makes the same change to our advertised bandwidth statistics.
 Obviously, this changes results a bit, because we're now interpolating
 between actually reported advertised bandwidths rather than returning a
 value that was actually reported by one of the relays. Still, for the sake
 of consistency throughout our code base, we should switch.
 >
 >  - [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26035=f9c24cab1006bf5999c662e9d06767c59c71a3e6
 f9c24ca] makes the third change in this series, this time to the
 connbidirect module. The change is quite significant in years 2011 and
 2012 where we had just a handful of relays reporting these statistics.
 Then it does make a difference whether we're interpolating or not. Same
 argument in favor of doing it now.

 The advbwdist module has a new static method, which should be made more
 visible and thus facilitate re-use as well as testing.
 Of course, for re-use it needs to be made more generic and maybe also
 placed in a different class (maybe `**.stats.Utiliy`).

 Remarks & suggestions in no particular order:
 * the sorting step in advbwdist changes an input parameter, which is bad
 practice.
 * commons-math Percentile class doesn't require the input data to be
 sorted. (The javadoc comment only talks about sorting in order to explain
 what will happen for edge cases.)
 * Maybe rather use `doubleValue()` instead of casting a Number sub-type to
 a primitive.
 * Casting of percentile results could be performed by the caller, which
 could guarantee that there are only values of for example type short
 entered (see connbiderect).  Or, provide special utility methods that re-
 use code internally.
 * connbidirect uses similar code as advbwdist for almost the same
 computations. The input fraction list also get changed by the unnecessary
 sorting step (this might not matter in that case, but still)
 * The Java re-implementation of the python detector will also benefit from
 a percentile function.
 * The percentile input parameter `int[] percentiles` could be changed to
 `int ... percentiles`.

 Encapsulation and testability of this type of functionality that is needed
 throughout the code is essential and will also make documentation now and
 in future much easier.
 The functionality should especially be tested b/c of the large impact such
 changes have, i.e., re-computation of everything.  This should be revised.

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

Re: [tor-bugs] #18543 [Applications/Tor Launcher]: Change dialog message when there is no protocol to copy

[Tor Bug Tracker & Wiki]

#18543: Change dialog message when there is no protocol to copy
---+---
 Reporter:  qbi|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by boklm):

 * cc: tbb-team (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] #26193 [Metrics/CollecTor]: Tarballs are not compressed in a run following an aborted run

[Tor Bug Tracker & Wiki]

#26193: Tarballs are not compressed in a run following an aborted run
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Today I wondered why some of our 2018-05 tarballs are over 3 days old even
 though we're creating new tarballs every 2 days. And I wondered even more
 after finding a seemingly completed run from yesterday. Here's what
 happened:

  - The May 19 run succeeded without issues.
  - The May 21 run was interrupted, probably due to a host reboot.
 Apparently, it finished compressing tarballs except for bridge extra-info
 descriptors, but it did not move any of them in place.
  - The May 23 run went through, but it did not compress any tarballs
 except for bridge extra-info descriptors.

 I think this is related to
 [https://gitweb.torproject.org/collector.git/tree/src/main/resources
 /create-tarballs.sh#n102 line 102 in the script]:

 {{{
 for (( i = 0 ; i < ${#TARBALLS[@]} ; i++ )); do
   echo `date` "Creating" ${TARBALLS[$i]}'.tar'
   tar chf ${TARBALLS[$i]}.tar ${TARBALLS[$i]}
   if [ ! -f ${TARBALLS[$i]}.tar.xz ]; then   # <- this one
 echo `date` "Compressing" ${TARBALLS[$i]}'.tar'
 xz -9e ${TARBALLS[$i]}.tar
   fi
 done
 }}}

 Explanation: there were still compressed files in the working directory
 from May 21, and as a result we did not attempt to compress new tarballs
 from May 23.

 Suggested fix: remove that `if` statement and compress the tarball
 regardless of whether a previous compressed tarball exists in the working
 directory using `xz -9e -f`:

 {{{
 diff --git a/src/main/resources/create-tarballs.sh b/src/main/resources
 /create-tarballs.sh
 index cd16b2dc..d247c520 100755
 --- a/src/main/resources/create-tarballs.sh
 +++ b/src/main/resources/create-tarballs.sh
 @@ -99,10 +99,8 @@ done
  for (( i = 0 ; i < ${#TARBALLS[@]} ; i++ )); do
echo `date` "Creating" ${TARBALLS[$i]}'.tar'
tar chf ${TARBALLS[$i]}.tar ${TARBALLS[$i]}
 -  if [ ! -f ${TARBALLS[$i]}.tar.xz ]; then
 -echo `date` "Compressing" ${TARBALLS[$i]}'.tar'
 -xz -9e ${TARBALLS[$i]}.tar
 -  fi
 +  echo `date` "Compressing" ${TARBALLS[$i]}'.tar'
 +  xz -9e -f ${TARBALLS[$i]}.tar
  done

  cd $OUTDIR/webstats/
 }}}

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

Re: [tor-bugs] #26193 [Metrics/CollecTor]: Tarballs are not compressed in a run following an aborted run

[Tor Bug Tracker & Wiki]

#26193: Tarballs are not compressed in a run following an aborted run
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * 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] #18543 [Applications/Tor Launcher]: Change dialog message when there is no protocol to copy

[Tor Bug Tracker & Wiki]

#18543: Change dialog message when there is no protocol to copy
---+---
 Reporter:  qbi|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * owner:  tbb-team => brade
 * cc: brade, mcs (added)
 * component:  Applications/Tor Browser => Applications/Tor Launcher


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

Re: [tor-bugs] #26172 [Applications/Tor Launcher]: torrc-defaults is not optional

[Tor Bug Tracker & Wiki]

#26172: torrc-defaults is not optional
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: mcs (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] #25691 [Core Tor/Tor]: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in onion_pick_cpath_exit

[Tor Bug Tracker & Wiki]

#25691: Bridges don't work: Non-fatal assertion !(exit_ei == NULL) failed in
onion_pick_cpath_exit
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-must 033-backport|  Actual Points:
  033-maybe-must |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet, teor|Sponsor:
-+-

Comment (by teor):

 Can we backport this fix to 0.3.3?

 Relay operators on 0.3.3.6 are complaining about #25692:
 https://lists.torproject.org/pipermail/tor-relays/2018-May/015309.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] #26015 [Metrics/Statistics]: Remove inconsistency between bandwidth history graphs

[Tor Bug Tracker & Wiki]

#26015: Remove inconsistency between bandwidth history graphs
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  closed
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+-
Changes (by karsten):

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


Comment:

 Yes, local tests have been successful before. Merged and deployed. It will
 first run tonight. Thanks! Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26192 [Internal Services/Service - git]: Grant tommyc access to tor-browser/user-manual git

[Tor Bug Tracker & Wiki]

#26192: Grant tommyc access to tor-browser/user-manual git
-+
 Reporter:  phoul|  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Please grant user tommyc access to the the following git repo:

 https://gitweb.torproject.org/tor-browser/user-manual.git/

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

Re: [tor-bugs] #25975 [Applications/Tor Browser]: Get a rust cross-compiler for macOS

[Tor Bug Tracker & Wiki]

#25975: Get a rust cross-compiler for macOS
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201805R, GeorgKoppen201805R, |
  boklm201805|
Parent ID:  #25779   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-rbm, ff60-esr, TorBrowserTeam201805R, GeorgKoppen201805,
 boklm201805
 =>
 tbb-rbm, ff60-esr, TorBrowserTeam201805R, GeorgKoppen201805R,
 boklm201805
 * status:  needs_revision => needs_review
 * cc: boklm (added)


Comment:

 Actually, we are good. The reason for this problem is that we are setting
 MACOSX__DEPLOYMENT_TARGET=10.6 which fits to the current toolchain we use.
 `thread_local` is not supported for 10.6 but it is for 10.7 onward. Thus,
 we are good for now and will be later on when switching to our new
 toolchain. I just tested that and could successfully build esr60.

 I've rebased my patch on `master` and pushed an update to bug_25975_v2
 (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_25975_v2=040cc0560eb21cf09dbdbbd33d501b805a28d6bd).

 boklm could you review that one?

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

Re: [tor-bugs] #26061 [Webpages/Blog]: Add blog posts to contributor pages

[Tor Bug Tracker & Wiki]

#26061: Add blog posts to contributor pages
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by steph):

 Thanks, 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

Re: [tor-bugs] #26061 [Webpages/Blog]: Add blog posts to contributor pages

[Tor Bug Tracker & Wiki]

#26061: Add blog posts to contributor pages
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 Hey Steph,
 Yes I have noticed this just after I closed the ticket. There are some
 mismatches. I am still working on this. Thanks for reopening.
 -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

Re: [tor-bugs] #26156 [Core Tor/Tor]: Undefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprecated

[Tor Bug Tracker & Wiki]

#26156: Undefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-
deprecated
+
 Reporter:  laomaiweng  |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal  | Resolution:  fixed
 Keywords:  openssl tor-crypto  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorZ
+
Changes (by nickm):

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


Comment:

 Please feel free to reopen this ticket if there is a remaining problem
 here, but if you do, please explain what the problem is.

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

Re: [tor-bugs] #26015 [Metrics/Statistics]: Remove inconsistency between bandwidth history graphs

[Tor Bug Tracker & Wiki]

#26015: Remove inconsistency between bandwidth history graphs
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  merge_ready
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks fine; assuming you performed test runs for db code (I don't have a
 useful environment at hand) ready for merge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26191 [Internal Services/Tor Sysadmin Team]: Strip DKIM headers

[Tor Bug Tracker & Wiki]

#26191: Strip DKIM headers
-+-
 Reporter:  starlight|  Owner:  tpa
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hi lovely sysadmin folks. Periodically we've had Mailman => Gmail bounce
 issues. Last week this cropped up again with a tor-relays@ post from
 starlight that got rejected by gmail subscribers (such as Nick and me).

 Starlight reached out with this tip I thought I'd pass on...

 {{{
 Presently I think a simple config change will help significantly.

 If they enable From: "munging" and stripping of DKIM
 headers it will eliminate hard SPF+DMARC and in-general
 DKIM message failures and spam scoring.  Then messages
 from the lists will be judged on the reputation of
 the listserv and standard content-based spam scoring,
 and not start with a black-mark due to authentication
 fails.

 I'm happy to reply to any questions the admin may have.
 }}}

 Feel free to resolve if we shouldn't go this route. I'll point starlight
 toward this ticket so he can continue the discussion.

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

Re: [tor-bugs] #26181 [Core Tor/Tor]: Apparmor + systemd failures when loading included service files + DisableAllSwap Fix (was: Systemd fails to load included service files tor@.service or tor@defaul

[Tor Bug Tracker & Wiki]

#26181: Apparmor + systemd failures when loading included service files +
DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:
 Keywords:  apparmor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * keywords:   => apparmor
 * severity:  Major => Normal
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.5.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

[tor-bugs] #26190 [Metrics/Statistics]: Use slf4j throughout all stats modules

[Tor Bug Tracker & Wiki]

#26190: Use slf4j throughout all stats modules
+--
 Reporter:  iwakeh  |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 Some modules, for example ipv6servers, use slf4j for logging, others, bad
 example hidserv, use System.err/out for logging.

 Check all org.torproject.metrics.stats sub-packages and make them use
 slf4j.
 Secondly, create an appropriate logback.xml file and adapt the run-java
 ant-task to use logback logging.

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

Re: [tor-bugs] #26181 [Core Tor/Tor]: Systemd fails to load included service files tor@.service or tor@default.service + DisableAllSwap Fix (was: Apparmor + systemd failures when loading included serv

[Tor Bug Tracker & Wiki]

#26181: Systemd fails to load included service files tor@.service or
tor@default.service + DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Hello71):

 * keywords:  apparmor =>
 * severity:  Normal => Major
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.3.x-final


Comment:

 what is the actual problem here? please use the following report format:

 brief description:

 how to reproduce:

 expected results:

 actual results:

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

Re: [tor-bugs] #26181 [Core Tor/Tor]: Apparmor + systemd failures when loading included service files + DisableAllSwap Fix

[Tor Bug Tracker & Wiki]

#26181: Apparmor + systemd failures when loading included service files  +
DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:
 Keywords:  apparmor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.5.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] #26181 [Core Tor/Tor]: Apparmor + systemd failures when loading included service files + DisableAllSwap Fix (was: Systemd fails to load included service files tor@.service or tor@defaul

[Tor Bug Tracker & Wiki]

#26181: Apparmor + systemd failures when loading included service files  +
DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:
 Keywords:  apparmor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * keywords:   => apparmor
 * severity:  Major => Normal


Comment:

 Trying to triage this ticket. Pretty complicated summary.

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

Re: [tor-bugs] #26022 [Metrics/Statistics]: Fix a flaw in the noise-removing code in our onion service statistics

[Tor Bug Tracker & Wiki]

#26022: Fix a flaw in the noise-removing code in our onion service statistics
+-
 Reporter:  karsten |  Owner:  karsten
 Type:  defect  | Status:  merge_ready
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:18 karsten]:
 > Please review commits [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26022=d297e80ba990f0163018e5ce5b2d9d131d9a1fb3
 d297e80] and [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-26022=4a518a29306e6c372b207fc172dc82b1956c28ec
 4a518a2] in [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-26022 my task-26022 branch].

 Both commits are fine, pass tests and checks.
 I think there are other places in Metrics' code where rounding is
 performed implicitly by relying on integer operations.  These should be
 looked for and also be replaced by explicit rounding.  Maybe, a new
 ticket?

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

Re: [tor-bugs] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by igt0):

 Replying to [comment:8 gk]:
 > Okay, this works for me, nice! Here comes a first batch of review
 comments (sorry, I have to split this up as I must switch context but
 wanted you to give some feedback to already work on):
 >
 > commit 1eafafefd2dfb6006f9f2686e6ecb591da8bc434
 >
 > Adding a hint to the underlying Mozilla bug
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414390) to the commit
 message would be good I think.

 OK!

 >
 >
 > commit 629f58cfffefb3f58ceab7275e0f1e1194a6f012
 >
 > Is that new that `catch` statements can't have `if` statements anymore?

 Yes, conditional clause was removed.

 In the page https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Statements/try...catch
 it says:

 Reminder: this functionality is not part of the ECMAScript specification
 and has been removed in Firefox 59. It's not supported in any current
 browser anymore.



 >
 >
 > commit 9c3e58597f3f3c41af2d44ae809a652c3a7d91a7
 >
 > Could you move the moz- removals in this bug to the previous commit?
 >
 > I don't understand your `plugin.disable` related commit/code change.
 It's not set by Mozilla code in ESR52 either. We are setting it in our own
 pref file we ship with the browser. Thus, it seems to me setting it here
 is not necessary?
 >
 > What speaks against using `getBrowser()`? It's cheaper to use
 `window.gBrowser`?
 >
 > Starting with "1." in the commit message without a "2." seems weird. :)
 Could you add more stuff as you seemed to want or reword that part?
 >
 >
 > commit ec0e146668a817954ee75b78216151830e626ebc
 >
 > Please do a
 > {{{
 > const Cu = Components.utils;
 > }}}
 > and use `Cu` in `cookie-jar-selector.js`
 > {{{
 > +  //Services.console.logStringMessage(`getPrefValue(${prefName})`);
 > }}}
 > No need for this commented out log statement
 > {{{
 > +   this.logmethod = 2;
 > }}}
 > Why is that needed?
 >
 > There are two additional new lines in `startup-observer.js` which are
 not needed.
 >
 > Re the pref loading:
 >
 > 1) Speaks anything against having that in utils.js instead of creating a
 new module?
 >
 > 2) I think we should set the prefs on the default prefs branch as it is
 done right now. That allows the user easily see which preferences got
 modified by themselves/the browser and more importantly there is the
 option to return to save defaults. tor-launcher's
 949379555010a04633c64b08ed52896a86c2cce6 might give some inspiration.

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

Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:
  034-triage-20180328, 034-removed-20180502  |
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 Now I'm curious what nickm thinks. Time to `merge_ready`.

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

Re: [tor-bugs] #26172 [Applications/Tor Launcher]: torrc-defaults is not optional (was: geoipFile and geoip6File cloned from optional torrcDefaultsFile)

[Tor Bug Tracker & Wiki]

#26172: torrc-defaults is not optional
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

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

Re: [tor-bugs] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:9 gk]:
 > Okay I looked over the remaining commits. There is just one additional
 thing to change I think:

 Oh, and another nit: Some commits start with "bug 26100" and some with
 "Bug 26100". I think all of them should start with "Bug 26100" if they are
 related to this bug.

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

Re: [tor-bugs] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 FWIW, I opened #26189 for removing our content-policy.js component. We
 should do this in a separate ticket and not during the general update for
 ESR60 done here.

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

[tor-bugs] #26189 [Applications/Tor Browser]: Remove our content policy hack for #8725

[Tor Bug Tracker & Wiki]

#26189: Remove our content policy hack for #8725
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr, tbb-
  |  torbutton
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Back then Yawning implemented a hack to defend leaking installed Tor
 Browser resources to content (see: #8725). Thus got upstreamed during the
 ESR60 timeframe (https://bugzilla.mozilla.org/show_bug.cgi?id=863246) and
 is available in Tor Browser now. We can think about removing this
 workaround from Torbutton then.

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

Re: [tor-bugs] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Okay I looked over the remaining commits. There is just one additional
 thing to change I think:

 5e59e4c941e1b8a0c7b3ac868ca4e8417dcfd4f8

 lgtm

 862ed4fb7b5a1709c59cbef25038b37673e8546f

 lgtm

 e90ff32809cae6800b919b9b7e30d9b5b65ee3b9

 lgtm

 c1f2c1f79d334c43ffdbd598312d5de2e3b54a34

 "tor button" -> "Torbutton"

 75505702f257c0bd4230025ce826797157436427

 lgtm

 674e336f587d687934b74b37244353a27fa95a18

 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] #26184 [Applications/Tor Browser]: Think about using `const` as much as possible in Torbutton code

[Tor Bug Tracker & Wiki]

#26184: Think about using `const` as much as possible in Torbutton code
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by igt0):

 Hi I also like this article https://mathiasbynens.be/notes/es6-const
 (TL;DR const doesn't allow rebinding [it is not about immutability]).

 I agree with mcs about in the end the **technical** advantages are small,
 however for new contributors it reduces the cognitive load, because they
 know that variable will not change in that scope.

 E.g Every time I see a let in the beginning of the file, I assume that
 variable can change and it can be undefined or null!

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

Re: [tor-bugs] #26188 [Core Tor/Tor]: Bug: src/or/circuitbuild.c:2779

[Tor Bug Tracker & Wiki]

#26188: Bug: src/or/circuitbuild.c:2779
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


Comment:

 Duplicate #25692

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26188 [Core Tor/Tor]: Bug: src/or/circuitbuild.c:2779

[Tor Bug Tracker & Wiki]

#26188: Bug: src/or/circuitbuild.c:2779
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
  Bug: src/or/circuitbuild.c:2779: onion_extend_cpath: Non-fatal assertion
 info failed. (on Tor 0.3.3.6 7dd0813e783ae16e)
  Non-fatal assertion info failed in onion_extend_cpath at
 src/or/circuitbuild.c:2779. Stack trace: (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x11b0428  at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
  0x11cb8ea  at /usr/local/bin/tor (on Tor
 0.3.3.6 7dd0813e783ae16e)
  0x10fe2ea  at /usr/local/bin/tor
 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x10bf2b2  at /usr/local/bin/tor
 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x10feeb5  at /usr/local/bin/tor
 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x10a174b  at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
  0x10a0ab3  at /usr/local/bin/tor
 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x1115d4f  at /usr/local/bin/tor (on Tor
 0.3.3.6 7dd0813e783ae16e)
  0x113d4db  at /usr/local/bin/tor
 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x112ff41  at /usr/local/bin/tor (on
 Tor 0.3.3.6 7dd0813e783ae16e)
  0x1075f64  at /usr/local/bin/tor (on Tor
 0.3.3.6 7dd0813e783ae16e)
  0x801b5006f  at
 /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x801b4bf4e  at
 /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.3.6 7dd0813e783ae16e)
  0x107815b  at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
  0x107a785  at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
  0x1075c2c  at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
  0x1075ac9  at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
  0x10759c0 <_start+0x180> at /usr/local/bin/tor (on Tor 0.3.3.6
 7dd0813e783ae16e)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26187 [Applications/Tor Browser]: Url not working - even with NoScript disabled

[Tor Bug Tracker & Wiki]

#26187: Url not working - even with NoScript disabled
--+--
 Reporter:  tange |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This URL does not work in Tor Browser.

 It is unclear to me what is wrong:

 https://www.rejsekort.dk/kundeservice/kontaktformular.aspx

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

Re: [tor-bugs] #26061 [Webpages/Blog]: Add blog posts to contributor pages

[Tor Bug Tracker & Wiki]

#26061: Add blog posts to contributor pages
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

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


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

Re: [tor-bugs] #26061 [Webpages/Blog]: Add blog posts to contributor pages

[Tor Bug Tracker & Wiki]

#26061: Add blog posts to contributor pages
---+-
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by steph):

 I don't see this working for everything.

 Posts aren't showing up on my profile:
 https://blog.torproject.org/contributors/steph

 And there seems to be some difference between people. For instance, when I
 click Phoul from https://blog.torproject.org/get-help-running-your-relay-
 our-new-advocate , it links to https://blog.torproject.org/users/phoul
 which doesn't have his posts. I do see his posts here though, but it's not
 linked from his name on posts he's authored:
 https://blog.torproject.org/contributors/phoul

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

Re: [tor-bugs] #26061 [Webpages/Blog]: Add blog posts to contributor pages

[Tor Bug Tracker & Wiki]

#26061: Add blog posts to contributor pages
---+-
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by hiro):

 * status:  new => 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] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

[Tor Bug Tracker & Wiki]

#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by Hello71):

 one small thing: as I said on IRC, my informal profiling seems to show
 that a significant amount of CPU time is spent in the kernel networking
 stack, including TCP/IP and waiting for the network device. it's possible
 that that last bit is partially because of an old virtio-net though. it
 could potentially be easier to integrate recv multithreading at this
 point; or maybe not! maybe it would be easier (even in total) to just do
 crypto first, and then the other stuff.

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

Re: [tor-bugs] #26184 [Applications/Tor Browser]: Think about using `const` as much as possible in Torbutton code

[Tor Bug Tracker & Wiki]

#26184: Think about using `const` as much as possible in Torbutton code
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I am not sure if we should use `const` everywhere we can. Is Mozilla doing
 this? Here is an article that makes for interesting reading; especially
 look at the "Liberal let" and "Constantly const" sections. What to do
 probably comes down to personal preference, but as a team it would be good
 to adopt some guidelines.

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

Re: [tor-bugs] #26158 [Core Tor/Tor]: A little bug of circular path of Tor

[Tor Bug Tracker & Wiki]

#26158: A little bug of circular path of Tor
-+-
 Reporter:  TBD.Chen |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  circular-path, security-low, |  Actual Points:
  031-backport, 032-backport, 033-backport,  |
  034-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Whoops, sorry -- my branches are in my personal repository at
 https://git.torproject.org/nickm/tor.git !

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

Re: [tor-bugs] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

[Tor Bug Tracker & Wiki]

#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 I have few comment about the proposed design. This is something I thought
 about a while back but never got cycles to implement.

 Where should I discuss the plan? I would avoid using the ticket for that.
 I think a tor-dev@ thread would be ideal here?

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

Re: [tor-bugs] #26116 [Core Tor/Tor]: OpenSSL 1.1.1 changed the semantics of the password callback return value

[Tor Bug Tracker & Wiki]

#26116: OpenSSL 1.1.1 changed the semantics of the password callback return 
value
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport 031-backport|  Actual Points:
  032-backport 033-backport  |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #26116 [Core Tor/Tor]: OpenSSL 1.1.1 changed the semantics of the password callback return value

[Tor Bug Tracker & Wiki]

#26116: OpenSSL 1.1.1 changed the semantics of the password callback return 
value
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 031-backport|  Actual Points:
  032-backport 033-backport  |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by nickm):

 aeb4be1d5a17f8ff836e370f8942c09c66b31e1d has a unit test to check these
 cases.

 We don't expect to get a legit password-protected key, but somebody could
 maliciously (or accidentally) send one in.

 I'm merging this to 0.2.9 and forward

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

Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:
  034-triage-20180328, 034-removed-20180502  |
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by dgoulet):

 Indeed... that is true. Probably the current approach is fine and should
 cover the majority of issues. And ultimately it will get fixed after a
 while at the next consensus.

 Detecting non-live to live is a PITA... I think our best bet is probably
 what you did which is to readjust everything on clock jump regardless of
 what we think we have or not. Safe.

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

Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--+
 Reporter:  cypherpunks   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #22455| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:18 asn]:
 > Approach seems reasonable but I'm not sure whether it addresses the root
 issue which is that the service has an intro circuit open to an intro
 point which it does not respond to (the client connects fine if it fetches
 a new HS desc). Do you think that's because of the small 2 second timeout,
 or could it be another bug?

 Hmmm... I'm not seeing that in the logs. The intro point is fine and does
 relay the INTRO cell to the service, then the client gets the ACK from the
 intro point and wait on the RP.

 The issue seems that the service does NOT go to the RP and that ultimately
 makes the RP circuit *client* side to timeout *but* quite fast (2sec).

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

Re: [tor-bugs] #26116 [Core Tor/Tor]: OpenSSL 1.1.1 changed the semantics of the password callback return value

[Tor Bug Tracker & Wiki]

#26116: OpenSSL 1.1.1 changed the semantics of the password callback return 
value
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 031-backport|  Actual Points:
  032-backport 033-backport  |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by nickm):

 See also https://github.com/openssl/openssl/issues/6347 for an OpenSSL bug
 exposed by this bug.  I'm working on tests. :)

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

Re: [tor-bugs] #16472 [Applications/Tor Browser]: Upgrade Binutils to 2.25+ for Tor Browser builds

[Tor Bug Tracker & Wiki]

#16472: Upgrade Binutils to 2.25+ for Tor Browser builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201805,|  Actual Points:
  TorBrowserTeam201805   |
Parent ID:  #12968   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, boklm201805, TorBrowserTeam201805R => tbb-rbm,
 boklm201805, TorBrowserTeam201805
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:84 boklm]:
 > Commit `d96fc6ca36f6a0b13e8d41749c62fd50c0edab06` in branch
 `bug_16472_v12` is updating binutils to 2.26.1, with the patch from
 binutils commit `13e570f80cbfb299a8858ce6830e91a6cb40ab7b` reverted for
 the Windows builds:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_16472_v12=d96fc6ca36f6a0b13e8d41749c62fd50c0edab06

 This commit is conflicting with the changes from #25862, so I will rebase
 it on #25862.

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

Re: [tor-bugs] #25862 [Applications/Tor Browser]: Clean up wrapper script/CFLAGS and friends mix on Windows

[Tor Bug Tracker & Wiki]

#25862: Clean up wrapper script/CFLAGS and friends mix on Windows
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201805R,  |  Actual Points:
  boklm201805|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Branch `bug_25862_v3` contains the same commit, rebased on master:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25862_v3=e74129cd57d41cd929395749338fcec8d6092076

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

Re: [tor-bugs] #26100 [Applications/Tor Browser]: Update Tor Button for ESR 60

[Tor Bug Tracker & Wiki]

#26100: Update Tor Button for ESR 60
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-torbutton, |  Actual Points:
  TorBrowserTeam201805   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 Okay, this works for me, nice! Here comes a first batch of review comments
 (sorry, I have to split this up as I must switch context but wanted you to
 give some feedback to already work on):

 commit 1eafafefd2dfb6006f9f2686e6ecb591da8bc434

 Adding a hint to the underlying Mozilla bug
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414390) to the commit
 message would be good I think.


 commit 629f58cfffefb3f58ceab7275e0f1e1194a6f012

 Is that new that `catch` statements can't have `if` statements anymore?


 commit 9c3e58597f3f3c41af2d44ae809a652c3a7d91a7

 Could you move the moz- removals in this bug to the previous commit?

 I don't understand your `plugin.disable` related commit/code change. It's
 not set by Mozilla code in ESR52 either. We are setting it in our own pref
 file we ship with the browser. Thus, it seems to me setting it here is not
 necessary?

 What speaks against using `getBrowser()`? It's cheaper to use
 `window.gBrowser`?

 Starting with "1." in the commit message without a "2." seems weird. :)
 Could you add more stuff as you seemed to want or reword that part?


 commit ec0e146668a817954ee75b78216151830e626ebc

 Please do a
 {{{
 const Cu = Components.utils;
 }}}
 and use `Cu` in `cookie-jar-selector.js`
 {{{
 +  //Services.console.logStringMessage(`getPrefValue(${prefName})`);
 }}}
 No need for this commented out log statement
 {{{
 + this.logmethod = 2;
 }}}
 Why is that needed?

 There are two additional new lines in `startup-observer.js` which are not
 needed.

 Re the pref loading:

 1) Speaks anything against having that in utils.js instead of creating a
 new module?

 2) I think we should set the prefs on the default prefs branch as it is
 done right now. That allows the user easily see which preferences got
 modified by themselves/the browser and more importantly there is the
 option to return to save defaults. tor-launcher's
 949379555010a04633c64b08ed52896a86c2cce6 might give some inspiration.

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

Re: [tor-bugs] #25960 [Core Tor/Tor]: Allow additional header lines in bandwidth measurements documents

[Tor Bug Tracker & Wiki]

#25960: Allow additional header lines in bandwidth measurements documents
-+-
 Reporter:  juga |  Owner:  juga
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-proposed, bwauth, 034-backport,  |  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  033-backport   |
Parent ID:  #25925   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => merge_ready


Comment:

 Change to merge_ready because of #25947.

 Probably there is no need to backport it to versions earlier than 032.

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

Re: [tor-bugs] #25947 [Core Tor/Tor]: Create unit test for dirserv_read_measured_bandwidths

[Tor Bug Tracker & Wiki]

#25947: Create unit test for dirserv_read_measured_bandwidths
--+
 Reporter:  juga  |  Owner:  juga
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bwauth, test  |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by juga):

 * status:  needs_revision => merge_ready


Comment:

 I agree with the changes and have squashed them in my
 `ticket25947_032_03_refactor` branch.

 I've run the branch using torflow and sbws generated bandwidth file, and
 there was no any warnings (`grep -r warn /pathtotorlogs/*.log|grep -i
 bandwidth`).

 Probably this should be backported to 032-backport, as #25960

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26186 [Applications/Tor Browser]: Replace usage of `intl.locale.matchOS` in tor-browser's build script

[Tor Bug Tracker & Wiki]

#26186: Replace usage of `intl.locale.matchOS` in tor-browser's build script
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 `intl.locale.matchOS` is not anymore (see the respective Torbutton change
 in #26100), we need to replace it in tor-browser's build script.

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

Re: [tor-bugs] #26165 [Applications/Tor Browser]: Make it possible to use gcc:var/setup without hardening wrapper

[Tor Bug Tracker & Wiki]

#26165: Make it possible to use gcc:var/setup without hardening wrapper
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201805,|  Actual Points:
  TorBrowserTeam201805R  |
Parent ID:  #26073   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * status:  needs_revision => needs_review
 * keywords:  tbb-rbm, boklm201805, TorBrowserTeam201805 => tbb-rbm,
 boklm201805, TorBrowserTeam201805R


Comment:

 I pushed a new version of this patch in branch `bug_26165_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_26165_v2=2b3a35530ece4f61f86786bc524d18448bc009eb

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

Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, |  Actual Points:
  034-triage-20180328, 034-removed-20180502  |
Parent ID:   | Points:  1
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:15 dgoulet]:
 > I think ideally we would like to do this if those two conditions are
 met:
 >
 > 1. Clock has jumped (at least the discrepancy from the code of 2+ sec)
 > 2. If we transition from "not live" to "live"
 >
 > Recomputing the voting timings and HSDir index only makes sense if we
 had a consensus before that we didn't think it was live and after the
 clock jump, it became live.
 >
 > I'm not sure how easily we can achieve (2) here. Probably something like
 two flags where one says "previous consensus was not live" and second says
 "the whole recalculation of a new live consensus needs to happen"...
 Becomes a bit non-trivial to correctly set those with our code flow...
 >

 Yeah the code flow is not very welcoming to this flag approach, because no
 particular event happens when we move from non-live to live, and we would
 probably have to check every second for the transition; otherwise if we
 miss the transition even for a second this bug can occur again I think. I
 wonder how to do this cleanly...

 > The other option is to possibly keep the `valid_after` time of the
 consensus that was used for the HSDir index computation. If that time is 0
 (unset) or smaller than the one we have in our *live* consensus and we
 detect the clock jump, we should readjust.
 >

 Hmm, I kinda get the idea here, but it seems a bit dirty to rely on
 whether HSDir index is set, to also readjust voting schedule etc. I wonder
 what else we could rely on here...

 > The whole point of the above I think is to avoid only recomputing with
 the >= 100 seconds clock jump since edge cases appear if for instance we
 correct for only 10 seconds.

 Hmm, I get the theoretical issue here, but it seems ultra unlikely we will
 miss the transition for 10 seconds skew, given the way consensus documents
 are propagated on the network. Because this can only happen if Alice
 fetches a consensus with `valid-after 12:00` at 12:00:05, but her system
 time is skewed at 11:59:56. It's very unlikely that Alice will fetch the
 consensus so early in its lifetime and also have so tiny skewed clock, but
 I guess the theoretical issue is there.

 Need to think of how to do this cleanly and without too much overhead.

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

Re: [tor-bugs] #26165 [Applications/Tor Browser]: Make it possible to use gcc:var/setup without hardening wrapper

[Tor Bug Tracker & Wiki]

#26165: Make it possible to use gcc:var/setup without hardening wrapper
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201805,|  Actual Points:
  TorBrowserTeam201805   |
Parent ID:  #26073   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-rbm, boklm201805, TorBrowserTeam201805R => tbb-rbm,
 boklm201805, TorBrowserTeam201805
 * status:  needs_review => needs_revision


Comment:

 Because of #26185 it is not easy to override `var/hardenned_cc`. To avoid
 that, we should call it `hardenned_cc` instead of `var/hardenned_cc`
 (until #26185 is 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

[tor-bugs] #26185 [Applications/rbm]: rbm should do deep merge of options hashes

[Tor Bug Tracker & Wiki]

#26185: rbm should do deep merge of options hashes
--+---
 Reporter:  boklm |  Owner:  boklm
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 In templates, when using the `c()` or `pc()` functions, it is possible to
 give as 2nd or 3rd argument an hash table containing variables to be
 overridden. To do that, we merge this hash table into the main options
 hash table. However we only merge one level, which means that if the new
 options hash table contains variables in a second level with something
 like `var => { option_1 => 'value1' }`, then `var` is replaced instead of
 merged, and all `var/*` options other than `option_1` are removed.

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

Re: [tor-bugs] #26179 [Metrics/CollecTor]: Release CollecTor 1.6.0

[Tor Bug Tracker & Wiki]

#26179: Release CollecTor 1.6.0
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  iwakeh, irl|Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 All fine, checks and tests pass, jars are signed, changelog looks good.

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

Re: [tor-bugs] #25975 [Applications/Tor Browser]: Get a rust cross-compiler for macOS

[Tor Bug Tracker & Wiki]

#25975: Get a rust cross-compiler for macOS
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201805R, GeorgKoppen201805,  |
  boklm201805|
Parent ID:  #25779   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 `__FastLocalKeyInner` seems to be missing in our `libstd` .rlib, hm, yet I
 can see
 {{{
 thread :: __FastLocalKeyInner < $ t > = $ crate :: thread ::
 __FastLocalKeyInner :: new (  ) ; # [ cfg ( not ( target_thread_local ) )
 ]
 static __KEY : $ crate :: thread :: __OsLocalKeyInner < $ t > = $ crate ::
 thread :: __OsLocalKeyInner :: new (  ) ; __KEY . get (  ) } unsafe {
 }}}
 as in the lib downloaded via `rustup`.

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

Re: [tor-bugs] #25975 [Applications/Tor Browser]: Get a rust cross-compiler for macOS

[Tor Bug Tracker & Wiki]

#25975: Get a rust cross-compiler for macOS
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff60-esr,   |  Actual Points:
  TorBrowserTeam201805R, GeorgKoppen201805,  |
  boklm201805|
Parent ID:  #25779   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:
 tbb-rbm, ff60-esr, TorBrowserTeam201805R, GeorgKoppen201804,
 boklm201805
 =>
 tbb-rbm, ff60-esr, TorBrowserTeam201805R, GeorgKoppen201805,
 boklm201805


Comment:

 Okay, this likely needs a revision as using a so-created Rust cross-
 compiler leads to:
 {{{
  8:36.74 error[E0433]: failed to resolve. Could not find
 `__FastLocalKeyInner` in `thread`
  8:36.74   --> third_party/rust/futures/src/task_impl/std/mod.rs:28:1
  8:36.74|
  8:36.74 28 | thread_local!(static CURRENT_TASK: Cell<*mut u8> =
 Cell::new(ptr::null_mut()));
  8:36.74|
 ^^^
 Could not find `__FastLocalKeyInner` in `thread`
  8:36.74|
  8:36.74= note: this error originates in a macro outside of the
 current crate (in Nightly builds, run with -Z external-macro-backtrace for
 more info)
  8:36.74
  8:36.75 error[E0433]: failed to resolve. Could not find
 `__FastLocalKeyInner` in `thread`
  8:36.75--> third_party/rust/futures/src/task_impl/std/mod.rs:494:1
  8:36.75 |
  8:36.75 494 | / thread_local! {
  8:36.75 495 | | static CURRENT_THREAD_NOTIFY: Arc =
 Arc::new(ThreadNotify {
  8:36.75 496 | | state: AtomicUsize::new(IDLE),
  8:36.75 497 | | mutex: Mutex::new(()),
  8:36.75 498 | | condvar: Condvar::new(),
  8:36.75 499 | | });
  8:36.75 500 | | }
  8:36.75 | |_^ Could not find `__FastLocalKeyInner` in `thread`
  8:36.75 |
  8:36.75 = note: this error originates in a macro outside of the
 current crate (in Nightly builds, run with -Z external-macro-backtrace for
 more info)
  8:36.75

 }}}

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

Re: [tor-bugs] #25544 [Core Tor/Tor]: Complete vanguard specification

[Tor Bug Tracker & Wiki]

#25544: Complete vanguard specification
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, torspec, guard-   |  Actual Points:
  discovery, 034-roadmap-master, |
  034-triage-20180328, 034-included-20180328 |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV
-+-
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:9 mikeperry]:
 > Replying to [comment:8 asn]:
 > > Mike, your changes look good to me.
 > >
 > > I pushed another commit on my github repo at `mesh-vanguards` with
 some more text on how the python script is used right now. If you think
 that's inappropriate for the proposal let me now.
 >
 > Seems good.
 >
 > > I think now is the time to decide what's the role of prop#247 and
 what's the role of `xxx-mesh-vanguards.txt`. I think it's confusing to let
 both of them live at the same time because they are pretty similar in
 terms of text. We should figure this out so that we get this merged in
 torspec.
 > >
 > > Should we let prop#247 be "Vanguard integration inside Tor core",
 whereas this new proposal is "Mesh vanguard design using external script"?
 And make both of them proper proposals (aka get a proposal number for this
 new one too). Or what should be the plan?
 >
 > I think that the final Tor implementation should match the vanguards
 repo behavior (and what this new proposal says), not 247. Because what
 proposal 247 proposed is different enough than what we're doing in the
 vanguards repo (and what is specified in this proposal) that we should
 mark 247 as superseded by this one. It felt weird tossing aside the old
 247 material entirely.
 >
 > I don't have a strong preference for this, but it seems natural to me.
 Argument against might be that we've been saying prop#247 everywhere, but
 I think as long as 247 as marked as superseded and mentions the new
 proposal, this is OK.

 Sounds good. Take a look at my branch `mesh-vanguards-squashed` in my
 repo. It's rebased to latest master, I squashed all the vanguard-mesh
 commits together, and I superseded prop#247.

 The only thing that needs to happen before merging is replace all the
 `xxx-mesh-vanguards.txt` parts with the actual number we give to the new
 proposal.

 Check it out and let's merge ready it if you like 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] #26183 [Applications/Tor Launcher]: Close control connection (socket and io.streams) on failure

[Tor Bug Tracker & Wiki]

#26183: Close control connection (socket and io.streams) on failure
---+-
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  invalid
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by cypherpunks):

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


Comment:

 Socket and streams will be garbage collected later which will close
 everything if there is no reference.

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

Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--+
 Reporter:  cypherpunks   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #22455| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Replying to [comment:17 dgoulet]:
 >
 > I think, there are couple things we might want to consider.
 >
 > a. Extend the time out cutoff of an established waiting for service
 rendezvous circuit client side
 (`CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED`) so we give a bit of room to
 the service to communicate. 2 seconds timeout (in this case) is imo very
 short especially considering a popular service...
 >
 > b. Some sort of upper threshold on how many connection attempts we do to
 a service before we stop trying. For instance, we could consider that
 after 3 back and forth, we stop trying and close the SOCKS connection with
 an "Unable to connect" kind of error.
 >
 >  Right now, it will do the above dance for 120 seconds (the SOCKS port
 default timeout) so it puts pressure on the network where we could have
 stopped at 3 attempts before..
 >
 > I personally think we should maybe aim for a combination of (a) and (b).

 Approach seems reasonable but I'm not sure whether it addresses the root
 issue which is that the service has an intro circuit open to an intro
 point which it does not respond to (the client connects fine if it fetches
 a new HS desc). Do you think that's because of the small 2 second timeout,
 or could it be another bug?

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  ux-team, TorBrowserTeam201805R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  antonela|Sponsor:
+--

Comment (by gk):

 Replying to [comment:64 arthuredelstein]:
 > Replying to [comment:62 gk]:
 > > Okay, I cherry-picked ef3476c5068d8597084c781a25792ce9ccef378c and
 fixed two typos in a follow-up commit
 (a3447ddb13c279e7e4c384610b98a045e7f932bb). Thanks, great work!
 > >
 > > What's the idea behind the "const-ification" in the other commit?
 FWIW: I am not sure whether this is actually bound to this bug (given you
 used the same bug number).
 >
 > Something igt0 suggested when he reviewed the patch. Technically I
 should be using `const` often where I am using `let`. Maybe it's better to
 ignore this patch for now and we can decide whether to constify the whole
 codebase at some point.

 I opened #26184 to gather our thoughts for a "constification".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26184 [Applications/Tor Browser]: Think about using `const` as much as possible in Torbutton code

[Tor Bug Tracker & Wiki]

#26184: Think about using `const` as much as possible in Torbutton code
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-torbutton
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 While working on #24309, the idea got brought up to use `const` as much as
 possible in Torbutton code (see:
 
https://github.com/arthuredelstein/torbutton/commit/3a1aa3ff006b3f2d2e49931c71f9ec2661143192
 for an actual patch for the circuit display).

 We should summarize the pros and cons for this idea and then make a
 decision on what to do and 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] #26183 [Applications/Tor Launcher]: Close control connection (socket and io.streams) on failure

[Tor Bug Tracker & Wiki]

#26183: Close control connection (socket and io.streams) on failure
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 {{{
 catch(e)
 {
   TorLauncherLogger.safelog(4,
  "failed to open authenticated connection: ",
 e);
 + if (conn)
 +   this._closeConnection(conn);
   return null;
 }
 }}}
 {{{
   if (!this.TorCommandSucceeded(reply))
   {
 TorLauncherLogger.log(4, "authenticate failed");
 +   this._closeConnection(conn);
 return null;
   }
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26183 [Applications/Tor Launcher]: Close control connection (socket and io.streams) on failure

[Tor Bug Tracker & Wiki]

#26183: Close control connection (socket and io.streams) on failure
---+---
 Reporter:  cypherpunks|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 `_openAuthenticatedConnection` returns `null` connection on failure while
 keeping socket and io.streams open.
 It fails if can't to connect to control port or `authenticate failed`.

 Example log for refused connection:
 {{{
 TorLauncher DBUG: Opening control connection to 127.0.0.1:9151
 TorLauncher DBUG: Sending Tor command: AUTHENTICATE
 5d3a59467366772f65463d6874786b4f
 TorLauncher NOTE: failed to open authenticated connection: [Exception...
 "Component returned failure code: 0x804b000d (NS_ERROR_CONNECTION_REFUSED)
 [nsIBinaryOutputStream.writeBytes]"  nsresult: "0x804b000d
 (NS_ERROR_CONNECTION_REFUSED)"  location: "JS frame :: jar:file:///path
 /tor-browser/Browser/TorBrowser/Data/Browser/profile.default/extensions
 /tor-launc...@torproject.org.xpi!/components/tl-protocol.js ::
 TorProtocolService.prototype._sendCommand :: line 889"  data: no]
 }}}

 About dozen connections in case of very slow starting Tor.

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

Re: [tor-bugs] #26181 [Core Tor/Tor]: Systemd fails to load included service files tor@.service or tor@default.service + DisableAllSwap Fix

[Tor Bug Tracker & Wiki]

#26181: Systemd fails to load included service files tor@.service or
tor@default.service + DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by d3m0nkingx):

 Along with disabling the init script for /etc/init.d/tor, I removed the
 service files tor@default.service and tor@.service from the systemd
 directory.

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

Re: [tor-bugs] #26181 [Core Tor/Tor]: Systemd fails to load included service files tor@.service or tor@default.service + DisableAllSwap Fix

[Tor Bug Tracker & Wiki]

#26181: Systemd fails to load included service files tor@.service or
tor@default.service + DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by d3m0nkingx):

 * '''$ systemctl set-property tor.service !MemoryLimit=64M'''

 Also set the memory limit to 64 Megabytes rather than allowing all
 available. Setting less than 47MB resulted in tor having an oom and kernel
 kills the process:

 out_of_memory+0x2ce/0x4f0

 kernel:  mem_cgroup_out_of_memory+0x4b/0x80

 kernel:  mem_cgroup_oom_synchronize+0x2e8/0x320

 kernel:  ? mem_cgroup_css_online+0x40/0x40

 kernel:  pagefault_out_of_memory+0x36/0x7b

 kernel:  mm_fault_error+0x90/0x180

 kernel:  !__do_page_fault+0x4a5/0x4d0

 kernel:  do_page_fault+0x2d/0xf0

 kernel:  ? page_fault+0x2f/0x50

 kernel:  page_fault+0x45/0x50

 kernel: RIP: 0033:0x7efc1d3de786

 kernel: RSP: 002!b:7ffcd6ed4e50 EFLAGS: 00010206

 kernel: RAX: 0001c001 RBX: 7efc1d720b20 RCX: 0021

 kernel: RDX: 559948ceefe0 RSI: 559948cef000 RDI: 

 kernel: RBP: 0021 R08: 559948ceef50 R09: 2e33363120746100

 kernel: R10: 2e3637312e323731 R11:  R12: 7efc1d720b78

 kernel: R13: 7efc1d720b78 R14: 2710 R15: 7efc1d720b88

 kernel: Task in /system.slice/tor.service killed as a result of limit of
 /system.slice/tor.service

 kernel: memory: usage 1024kB, limit 1024kB, failcnt 162

 kernel: memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0

 kernel: kmem: usage 224kB, limit 9007199254740988kB, failcnt 0

 kernel: Memory cgroup stats for /system.slice/tor.service: !cache:0KB
 !rss:792KB rss_!huge:0KB !shmem:0KB mapped_!file:0KB !dirty:0

 kernel: [ pid ]   uid  tgid total_vm      rss pgtables_bytes swapents
 oom_score_adj name

 kernel: [ 5884]     0  5884    11802     2277   139264        0
 0 tor

 kernel: Memory cgroup out of memory: Kill process 5884 (tor) score 1 or
 sacrifice child

 __'''kernel: Killed process 5884 (tor)'''__ '''!total-vm:47208kB''',
 !anon-rss:800kB, !file-rss:8308kB, !shmem-rss:0kB

 kernel: oom_reaper: reaped process 5884 (tor), now !anon-rss:540kB, !file-
 rss:7016kB, !shmem-rss:0kB

 systemd![1]: tor.service: Control process exited, code=killed status=9

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

Re: [tor-bugs] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

[Tor Bug Tracker & Wiki]

#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-
Changes (by chelseakomlo):

 * Attachment "MultiThreadedCrypto.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] #1749 [Core Tor/Tor]: Split relay and link crypto across multiple CPU cores

[Tor Bug Tracker & Wiki]

#1749: Split relay and link crypto across multiple CPU cores
-+-
 Reporter:  nickm|  Owner:
 |  chelseakomlo
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, term-project-ideas,   |  Actual Points:
  threads, performance   |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by chelseakomlo):

 Ok, I have a start of a plan which I'm looking forward to
 discussing/further refining in Seattle. I took a large amount from
 
https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto
 but there are some things which are out of date (circuit priority logic,
 for example) so any further pointers on what is different between when
 that wiki was written and where we are today would be helpful.

 Below is a pad with a high level plan/starting implementation ideas; I've
 also attached a high level (pretty rough, sorry!) proposed architectural
 diagram to this ticket. Looking forward to further discussion,
 particularly around the proposal to use Rust and any Rust/C integration
 issues that could be particularly painful, and also any better ideas about
 how to cleanly register/edge trigger events.

 https://pad.riseup.net/p/MultiThreadedCrypto_ImplementationPlan-keep

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

Re: [tor-bugs] #26178 [Metrics/Library]: Release metrics-lib 2.4.0

[Tor Bug Tracker & Wiki]

#26178: Release metrics-lib 2.4.0
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  task | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh, irl  |Sponsor:
-+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 All fine and bytecode is reproducible now!
 Ready to release.

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

Re: [tor-bugs] #26162 [Metrics/CollecTor]: Replace Gson with Jackson in CollecTor

[Tor Bug Tracker & Wiki]

#26162: Replace Gson with Jackson in CollecTor
---+-
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  merge_ready
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Cool! All fine.

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

Re: [tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#24309: Activity 4.1: Improve how circuits are displayed to the user
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  ux-team, TorBrowserTeam201805R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  antonela|Sponsor:
+--
Changes (by gk):

 * keywords:  ux-team, TorBrowserTeam201805 => ux-team,
   TorBrowserTeam201805R
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Okay, I think we are good here, closing. Thanks everyone!

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

Re: [tor-bugs] #25764 [Applications/Tor Browser]: TBA - Activity 4.1: Improve how circuits are displayed to the user

[Tor Bug Tracker & Wiki]

#25764: TBA - Activity 4.1: Improve how circuits are displayed to the user
---+--
 Reporter:  antonela   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * parent:  #24309 =>


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

Re: [tor-bugs] #24918 [Applications/Tor Browser]: Help users finding the new circuit display

[Tor Bug Tracker & Wiki]

#24918: Help users finding the new circuit display
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201805  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:  ux-team => ux-team, TorBrowserTeam201805
 * priority:  Medium => High
 * parent:  #24309 =>


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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
-+-
 Reporter:  isabela  |  Owner:
 |  pospeselr
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, |  Actual Points:
  TorBrowserTeam201805R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:61 pospeselr]:
 > Not sure I'm following gk regarding the strings.  The new onion-related
 strings are not hard-coded in the Page Info dialog, but pull from
 pippki.properties file using the pkiBundle.getBLAHString API (as does
 every other string lookup).

 That's right. But where does the translation come from? Like, how would
 that string look like in a, say, arabic Tor Browser? Clearly, it does not
 get translated by Mozilla as we only ship it in our patch set. But all our
 translations are done on Transifex either via Torbutton or Tor Launcher.
 Thus, the string is essentially hard-coded assuming the browser is falling
 back to en-US in case it can't find a string for the required locale. It
 might even break, not showing the dialog at all.

 > Should I be doing something else?

 We could try, see 5) in my comment:51.

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

Re: [tor-bugs] #26181 [Core Tor/Tor]: Systemd fails to load included service files tor@.service or tor@default.service + DisableAllSwap Fix (was: Systemd fails to load included service files tor@.serv

[Tor Bug Tracker & Wiki]

#26181: Systemd fails to load included service files tor@.service or
tor@default.service + DisableAllSwap Fix
--+
 Reporter:  d3m0nkingx|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.6
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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