Re: [tor-bugs] #23724 [Applications/Tor Browser]: NoScript restartless update breaks Security Slider and its icon disappears

[Tor Bug Tracker & Wiki]

#23724: NoScript restartless update breaks Security Slider and its icon 
disappears
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 On Win 10 TBB 7.5a5 updates itself to 5.1.0 (why?) and icon doesn't appear
 after restart.
 Also
 {{{
 1507179043900   addons.xpi  WARNException running bootstrap method
 shutdown on {73a6fe31-595d-460b-a920-fcc0f8843232}: TypeError:
 module.shutdown is not a function
 (resource://gre/modules/addons/XPIProvider.jsm ->
 
jar:file:///C:/Tor%20Browser/Browser/TorBrowser/Data/Browser/profile.default/extensions/%7B73a6fe31
 -595d-460b-a920-fcc0f8843232%7D.xpi!/bootstrap.js:30:5) JS Stack trace:
 shutd...@bootstrap.js:30:5 <
 this.xpiprovider.callbootstrapmet...@xpiprovider.jsm:5041:9 <
 startInstall/<@XPIProvider.jsm:5932:15
 }}}
 Seems NoScript conflicts with other add-ons (calls their chrome.manifest),
 fails to move its file to /trash and so on...

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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by Felixix):

 The number of circuits for this particular tor process was pretty high
 (200k) for hours compared to other relays (typ <20k).
 An increase in mbuf clusters usage could be observed after one day and
 having set the MaxMemInQueues higher.

 I changed from
 `MaxMemInQueues 2 GB`
 to
 `MaxMemInQueues 4 GB`
 service tor reload

 {{{
 Oct 01 08:20:52.000 [notice] Received reload signal (hup). Reloading
 config and resetting internal state.
 Oct 01 08:20:52.000 [notice] Read configuration file
 "/usr/local/etc/tor/torrc".
 }}}

 The last 4 minutes (on minutes log base)

 top -nCSjI
 {{{
   PID JID USERNAMETHR PRI NICE   SIZERES
 STATE   C   TIME CPU COMMAND
 2017-10-02_02-57-00:66451   52566  200  3050M  2984M
 uwait   0  71.9H  11.87% tor
 2017-10-02_02-58-00:66451   52566  200  3054M  2986M
 uwait   3  71.9H  11.47% tor
 2017-10-02_02-59-00:66451   52566  200  3054M  2986M
 uwait   2  71.9H 100.00% tor
 2017-10-02_03-00-00:66451   52566  200  3054M  2986M
 uwait   2  71.9H 100.00% tor
 }}}

 netstat -m | grep "mbuf clusters in use"
 {{{
 2017-10-02_02-57-00: 2508/43038/45546/2035262 mbuf clusters in use
 (current/cache/total/max)
 2017-10-02_02-58-00: 2552/42994/45546/2035262 mbuf clusters in use
 (current/cache/total/max)
 2017-10-02_02-59-00: 19335/26211/45546/2035262 mbuf clusters in use
 (current/cache/total/max)
 2017-10-02_03-00-00: 33636/11910/45546/2035262 mbuf clusters in use
 (current/cache/total/max)
 }}}

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 teor, thank you so much for your comments. Also, respond whenever you
 want.

 Also, I have made a new patch with the filename 002-desriptive_msg.patch​
 including your suggestions.

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
---+--
 Reporter:  gk |  Owner:  igt0
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by igt0):

 Replying to [comment:5 gk]:
 > Replying to [comment:4 igt0]:
 > > There is already an upstream fix for this bug:
 > >
 > > https://hg.mozilla.org/mozilla-central/rev/69970dbe2b5a
 > > https://hg.mozilla.org/mozilla-central/rev/12f8c79dabb4
 >
 > Thanks. I guess we want to backport those for our esr52-based branch. Do
 you think you want to do that?

 Yep, I am on 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] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * Attachment "002-desriptive_msg.patch" added.

 Revised Patch (Revision 1)

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

Re: [tor-bugs] #23745 [Applications/Tor Browser]: Tab crashes when using Tor Browser to access Google Drive

[Tor Bug Tracker & Wiki]

#23745: Tab crashes when using Tor Browser to access Google Drive
-+-
 Reporter:  angelotheram2|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-e10s, |  Actual Points:
  TorBrowserTeam201710   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I was able to reliably reproduce this crash and by bisecting our patches I
 tracked it down to our indexedDB patch:
 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.4.0esr-7.5-1=31348e47a340494c4002b43d8fb509689f8f7e63
 The work for this patch and its predecessor are at #21308 and #16528
 respectively.

 I also confirmed that if I set "dom.indexedDB.enabled" to true, the
 browser no longer crashes. (Flipping this pref is not recommended for
 users, because of privacy/tracking implications. I mention it only for
 debugging purposes.)

 gk observed that the crash is being caused by a block of code in
 ActorsParent.cpp:
 {{{
 if (principalInfo.type() != PrincipalInfo::TSystemPrincipalInfo &&
 NS_WARN_IF(!Preferences::GetBool(kPrefIndexedDBEnabled, false))) {
   if (aContentParent) {
 // The DOM in the other process should have kept us from receiving any
 // indexedDB messages so assume that the child is misbehaving.
 aContentParent->KillHard("IndexedDB CheckPermission 1");
   }
   return NS_ERROR_DOM_INDEXEDDB_NOT_ALLOWED_ERR;
 }
 }}}

 But this does not happen if "dom.indexedDB.enabled" is true. I have yet to
 investigate why.

 In the meantime, I am trying to work out what our strategy should be for
 indexedDB.
 * indexedDB is a supercookie vector and has not yet been patched to
 respect first-party isolation in Tor Browser or Firefox.
 * There is [https://bugzilla.mozilla.org/show_bug.cgi?id=781982 a Mozilla
 ticket] for enabling a memory-only indexeddb in Firefox but this has not
 been resolved. In other words, indexeddb always writes to disk.
 * As [https://trac.torproject.org/projects/tor/ticket/16528#comment:7
 mikperry pointed out], there wasn't a good way to programmatically clear
 indexedDB databases. That issue may have been recently fixed in
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1047098 Firefox] and we
 should investigate if we can use this in New Identity.
 * In PBM, indexedDB is already effectively disabled, even when
 "dom.indexedDB.enabled" is true.
 * Modernizr was [https://github.com/Modernizr/Modernizr/pull/2030 updated]
 a year ago to correctly detect the absence of indexedDB in Firefox PBM.
 So here are my thoughts. We should of course continue to disable indexedDB
 in PBM until it can be
 [https://bugzilla.mozilla.org/show_bug.cgi?id=781982 memory-only],
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1047098 programmatically
 cleared], and [https://bugzilla.mozilla.org/show_bug.cgi?id=1405884
 isolated by first party].

 There was a concern that some users might disable PBM and then New
 Identity would fail to wipe indexedDB. Do we actually want to claim to
 protect users who turn off PBM? That seems possibly out of scope to me. If
 that's the case, it seems to me we can rely on indexedDB being disabled in
 PBM by Firefox's built-in mechanism and drop the #21308 patch?

 But if we want to protect non-PBM users, then we should investigate
 whether New Identity can clear indexedDB (#23768). That ticket would be
 useful in the future if we wanted to enable indexedDB in PBM as well.

 If instead we want to ensure we have disabled indexedDB in non-PBM windows
 as well, then I would suggest writing a new patch that simply stops
 exposing indexedDB to content by modifying [https://dxr.mozilla.org
 /mozilla-
 
esr52/rev/8abd6da9603d45bb1e29994a480e10affbb8c7d8/dom/webidl/WindowOrWorkerGlobalScope.webidl#61
 dom/webidl/WindowOrWorkGlobalScope.webidl], so indexedDB is not exposed
 when the pref "dom.indexedDB.enabled" is false.

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

Re: [tor-bugs] #21694 [- Select a component]: Tor source tarball signed with sha1

[Tor Bug Tracker & Wiki]

#21694: Tor source tarball signed with sha1
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  - Select a component  |Version:  Tor: 0.3.1.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by isis):

 Maybe try also setting (in `~/.gnupg/gpg.conf`):

 {{{
 personal-digest-preferences SHA512 SHA384 SHA256
 }}}

 The preferences which you had set when you created the key are burned into
 the key, but `gpg2 --export-options 'export-minimal' --export
 FE43009C4607B1FB | pgpdump | grep 'Hash alg'` says that it's SHA256, so I
 honestly don't know what is getting it to use SHA1.

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

Re: [tor-bugs] #23768 [Applications/Tor Browser]: Wipe indexedDB in New Identity (was: Wipe indexeDB in New Identity)

[Tor Bug Tracker & Wiki]

#23768: Wipe indexedDB in New Identity
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * keywords:   => tbb-linkability


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23768 [Applications/Tor Browser]: Wipe indexeDB in New Identity

[Tor Bug Tracker & Wiki]

#23768: Wipe indexeDB in New Identity
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 Looks like Mozilla may have fixed the issue of wiping indexedDB.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1405884

 Let's see if we can get this working in New Identity.

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

Re: [tor-bugs] #23644 [Applications/Quality Assurance and Testing]: Fix the https-everywhere test in Tor Browser testsuite

[Tor Bug Tracker & Wiki]

#23644: Fix the https-everywhere test in Tor Browser testsuite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201710 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 Thanks!

 The patch has been merged as commit
 54dbfb2201fdaf071e01269b59750fae2c68de2a.

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

Re: [tor-bugs] #23697 [Webpages/Website]: List frontdesk, not execdir, on the contact page

[Tor Bug Tracker & Wiki]

#23697: List frontdesk, not execdir, on the contact page
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by t0mmy):

 Worth noting, as well, that donations@ is about to get 10x busier when we
 launch the end of year crowdfunding campaign.

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

Re: [tor-bugs] #23766 [Applications/Tor Browser]: Document build error when resolv.conf contains 127.0.0.1 in README.BUILD_ERRORS

[Tor Bug Tracker & Wiki]

#23766: Document build error when resolv.conf contains 127.0.0.1 in
README.BUILD_ERRORS
---+--
 Reporter:  kkuehl@…   |  Owner:  tbb-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201710  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by kkuehl@…):

 * Attachment "README.BUILD_ERRORS.patch" added.

 patch file documenting README.BUILD_ERRORS

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

Re: [tor-bugs] #23697 [Webpages/Website]: List frontdesk, not execdir, on the contact page

[Tor Bug Tracker & Wiki]

#23697: List frontdesk, not execdir, on the contact page
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by t0mmy):

 * cc: t0mmy (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] #23644 [Applications/Quality Assurance and Testing]: Fix the https-everywhere test in Tor Browser testsuite

[Tor Bug Tracker & Wiki]

#23644: Fix the https-everywhere test in Tor Browser testsuite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201710 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gacar):

 I attach a patch to change the test URL to http(s)://httpbin.org.

 httpbin.org is a test site that has a non-forwarding http endpoint. I
 think it's ideal for this test.

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

Re: [tor-bugs] #23644 [Applications/Quality Assurance and Testing]: Fix the https-everywhere test in Tor Browser testsuite

[Tor Bug Tracker & Wiki]

#23644: Fix the https-everywhere test in Tor Browser testsuite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201710 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gacar):

 * Attachment "fix_httpseverywhere.patch" added.


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

Re: [tor-bugs] #23716 [Metrics/Website]: Rename Operation section to Services

[Tor Bug Tracker & Wiki]

#23716: Rename Operation section to Services
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I like to maintain redirects for a short time at least, to allow for
 search engines to update.

 I wonder if "Query" is a good name, instead of "Services" as most of the
 tools listed on the page are for querying databases/datasets. Perhaps
 "Explore".

 I'm thinking more a verb for the user, if that makes sense, than a noun
 describing what the things are.

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

Re: [tor-bugs] #23767 [Metrics/Atlas]: Link to the new relay lifecycle blog post if it's a new relay

[Tor Bug Tracker & Wiki]

#23767: Link to the new relay lifecycle blog post if it's a new relay
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Description changed by irl:

Old description:

> Useful criteria for determining if it's a new relay would be:
>
>  * if the consensus weight is twenty, add a link to the blog post
>  * if the first-seen is within the past week
>
> We could consider adding a "new_relay" field to Onionoo, but this is
> simple enough that I'd be happy enough adding this to Atlas directly.
>
> The new relay lifecycle blog post is at https://blog.torproject.org
> /lifecycle-new-relay.
>
> When we move Atlas to the Metrics website, we can use the bootstrap alert
> classes to style this across the top of the Atlas details page.

New description:

 Useful criteria for determining if it's a new relay would be:

  * if the consensus weight is twenty
  * if the first-seen is within the past week

 We could consider adding a "new_relay" field to Onionoo, but this is
 simple enough that I'd be happy enough adding this to Atlas directly.

 The new relay lifecycle blog post is at https://blog.torproject.org
 /lifecycle-new-relay.

 When we move Atlas to the Metrics website, we can use the bootstrap alert
 classes to style this across the top of the Atlas details page.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23767 [Metrics/Atlas]: Link to the new relay lifecycle blog post if it's a new relay

[Tor Bug Tracker & Wiki]

#23767: Link to the new relay lifecycle blog post if it's a new relay
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Useful criteria for determining if it's a new relay would be:

  * if the consensus weight is twenty, add a link to the blog post
  * if the first-seen is within the past week

 We could consider adding a "new_relay" field to Onionoo, but this is
 simple enough that I'd be happy enough adding this to Atlas directly.

 The new relay lifecycle blog post is at https://blog.torproject.org
 /lifecycle-new-relay.

 When we move Atlas to the Metrics website, we can use the bootstrap alert
 classes to style this across the top of the Atlas details page.

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

Re: [tor-bugs] #22489 [Core Tor/Tor]: Bridge oftenly reports Failed to find node for hop 0 of our path. Discarding this circuit.

[Tor Bug Tracker & Wiki]

#22489: Bridge oftenly reports Failed to find node for hop 0 of our path.
Discarding this circuit.
+--
 Reporter:  s7r |  Owner:  (none)
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.2-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-client tor-bridge 030-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by s7r):

 On a more recent master `0.3.2.0-alpha-dev (git-209bfe715cc8c1c5)`:
 {{{
 Oct 04 11:17:27.000 [notice] Heartbeat: Tor's uptime is 32 days 11:59
 hours, with 18 circuits open. I've sent 31.64 GB and received 31.90 GB.
 Oct 04 11:17:27.000 [notice] Heartbeat: In the last 6 hours, I have seen
 11 unique clients.
 Oct 04 17:13:29.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:17:27.000 [notice] Heartbeat: Tor's uptime is 32 days 17:59
 hours, with 14 circuits open. I've sent 31.78 GB and received 32.05 GB.
 Oct 04 17:17:27.000 [notice] Heartbeat: In the last 6 hours, I have seen
 11 unique clients.
 Oct 04 17:20:24.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:28:25.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:34:29.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:38:36.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:45:23.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:50:04.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:54:06.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 17:58:18.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 18:03:28.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 18:07:39.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 18:11:44.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 Oct 04 20:12:42.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 }}}

 Again the client that uses this bridge to enter the Tor network didn't
 notice anything when this occured nor logged anything strange, so can
 confirm arma's comment:5 - we are looking at bridge's own circuits that it
 was making for itself.

 As I can see this also appears in #8185 - I'll keep an eye out for this
 after upgrading to latest git master.

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

Re: [tor-bugs] #23756 [Core Tor/Tor]: tor's .gitlab-ci.yml is doing mirroring? why?

[Tor Bug Tracker & Wiki]

#23756: tor's .gitlab-ci.yml is doing mirroring? why?
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 I'm experimenting with a scheduled mirroring job at
 https://oniongit.eu/catalyst/tor-mirror-test/tree/mirrortest on oniongit
 that runs every 30 minutes.  It's more parameterized, even though some
 (safe) parameters are set in the `.gitlab-ci.yml` file for now.

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

Re: [tor-bugs] #23762 [Core Tor/Tor]: hs-v3: Client request with missing dirinfo will always timeout

[Tor Bug Tracker & Wiki]

#23762: hs-v3: Client request with missing dirinfo will always timeout
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, tor-client  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_review
 * reviewer:   => asn


Comment:

 After discussing with asn, I went with a third option which was is to let
 the connection state in "renddesc wait" and add a callback to the HS
 client subsystem if the directory information changes.

 This turns out to be tricky but here is an attempt. I believe it is not
 perfect but it gives us a baseline to discuss:

 See branch: `bug23762_032_01`.

 First commit is a refactor splitting our refetch function into validation
 and fetching. Nothing to do with the fix per-se, we can easily just remove
 it but originally it was part of the fix and I kept it because I think it
 is nicer.

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

Re: [tor-bugs] #23697 [Webpages/Website]: List frontdesk, not execdir, on the contact page

[Tor Bug Tracker & Wiki]

#23697: List frontdesk, not execdir, on the contact page
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 Ok to add me.

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

Re: [tor-bugs] #23758 [Core Tor/Tor]: test config/include_no_permission fails when run as root

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails when run as root
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged to master!

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

Re: [tor-bugs] #22359 [Core Tor/Tor]: Community team and network team are constructing glossaries in parallel

[Tor Bug Tracker & Wiki]

#22359: Community team and network team are constructing glossaries in parallel
+--
 Reporter:  arma|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  doc wiki glossary website tor-spec  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by alison):

 Sorry for my late arrival. Looking at these two glossaries, there is
 already some overlap even if the torspec one is more technical. I'm happy
 to work on making these two more in sync with whoever is working on the
 network team 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] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 FWIW, I'm currently reviewing this branch.

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

Re: [tor-bugs] #23766 [Applications/Tor Browser]: Document build error when resolv.conf contains 127.0.0.1 in README.BUILD_ERRORS

[Tor Bug Tracker & Wiki]

#23766: Document build error when resolv.conf contains 127.0.0.1 in
README.BUILD_ERRORS
---+--
 Reporter:  kkuehl@…   |  Owner:  tbb-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201710  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by kkuehl@…):

 Not currently in README.BUILD_ERRORS

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kkuehl@…):

 That is correct. Also upgrading runc is another solution.

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
---+--
 Reporter:  gk |  Owner:  igt0
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 Replying to [comment:4 igt0]:
 > There is already an upstream fix for this bug:
 >
 > https://hg.mozilla.org/mozilla-central/rev/69970dbe2b5a
 > https://hg.mozilla.org/mozilla-central/rev/12f8c79dabb4

 Thanks. I guess we want to backport those for our esr52-based branch. Do
 you think you want to do that?

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 I think we mainly care about Guard IPv6 ORPorts and Bridge IPv6 ORPorts
 and PTs at this stage.
 Later we might be interested in middle and exit ORPorts.

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

Re: [tor-bugs] #23585 [Applications/Tor Browser]: Build is failing with runc version 1.0.0-rc2

[Tor Bug Tracker & Wiki]

#23585: Build is failing with runc version 1.0.0-rc2
+--
 Reporter:  boklm   |  Owner:  boklm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm, TorBrowserTeam201709 => tbb-rbm,
   TorBrowserTeam201710R
 * status:  assigned => needs_review


Comment:

 I pushed branch `bug_23585_v2` which contains the same patch rebased on
 master:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23585_v2=8c4c05ddcfc30107b967b204d491523685460226

 This patch fixed the problem in #23754.

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I was about to ask for the same graphs.
 Until it gets implemented you can see current data here:
 https://nusenu.github.io/OrNetStats/#ipv6-relay-stats

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

Re: [tor-bugs] #23585 [Applications/Tor Browser]: Build is failing with runc version 1.0.0-rc2

[Tor Bug Tracker & Wiki]

#23585: Build is failing with runc version 1.0.0-rc2
---+--
 Reporter:  boklm  |  Owner:  boklm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201709  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by boklm):

 #23754 is a duplicate.

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by boklm):

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


Comment:

 Thanks. So the patch from branch `bug_23585` is fixing the issue, and the
 next error was caused by having `127.0.0.1` in the resolv.conf file?

 So I think we can close this ticket as a duplicate of #23585.

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

Re: [tor-bugs] #23766 [Applications/Tor Browser]: Document build error when resolv.conf contains 127.0.0.1 in README.BUILD_ERRORS

[Tor Bug Tracker & Wiki]

#23766: Document build error when resolv.conf contains 127.0.0.1 in
README.BUILD_ERRORS
---+--
 Reporter:  kkuehl@…   |  Owner:  tbb-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201710  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by boklm):

 * keywords:   => tbb-rbm, TorBrowserTeam201710


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

Re: [tor-bugs] #23766 [Applications/Tor Browser]: Document build error when resolv.conf contains 127.0.0.1 in README.BUILD_ERRORS (was: runc bash: cannot set terminal process group (8): Inappropriate

[Tor Bug Tracker & Wiki]

#23766: Document build error when resolv.conf contains 127.0.0.1 in
README.BUILD_ERRORS
--+--
 Reporter:  kkuehl@…  |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * type:  defect => task


Comment:

 Thanks.

 I think we can mention this in the list of possible errors in the
 `README.BUILD_ERRORS` file.

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

Re: [tor-bugs] #17064 [Core Tor/Torflow]: scanner.9 in torflow/bwauth failing

[Tor Bug Tracker & Wiki]

#17064: scanner.9 in torflow/bwauth failing
--+
 Reporter:  tom   |  Owner:  aagbsn
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

 * severity:   => Blocker


Comment:

 Still a problem.  Here's some less verbose logs showing how it looks at
 the end:

 {{{
 WARN[Wed Oct 04 11:56:14 2017]:Not enough streams yet. 0 < 17.875
 NOTICE[Wed Oct 04 11:56:14 2017]:Stream 1452310 FAILED with TIMEOUT
 NOTICE[Wed Oct 04 11:56:14 2017]:Stream 1452310 CLOSED with TIMEOUT
 NOTICE[Wed Oct 04 11:58:14 2017]:Tor timed out our SOCKS stream request.
 WARN[Wed Oct 04 11:58:14 2017]:Not enough streams yet. 0 < 17.875
 NOTICE[Wed Oct 04 11:58:14 2017]:Stream 1452349 FAILED with TIMEOUT
 NOTICE[Wed Oct 04 11:58:14 2017]:Stream 1452349 CLOSED with TIMEOUT
 NOTICE[Wed Oct 04 12:00:14 2017]:Tor timed out our SOCKS stream request.
 WARN[Wed Oct 04 12:00:14 2017]:Not enough streams yet. 0 < 17.875
 NOTICE[Wed Oct 04 12:00:14 2017]:Stream 1452388 FAILED with TIMEOUT
 NOTICE[Wed Oct 04 12:00:14 2017]:Stream 1452388 CLOSED with TIMEOUT
 }}}

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

Re: [tor-bugs] #18660 [Core Tor/Stem]: OSX's man command lacks '--encoding' argument

[Tor Bug Tracker & Wiki]

#18660: OSX's man command lacks '--encoding' argument
---+--
 Reporter:  Sebastian  |  Owner:  atagar
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  utils  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Thanks Edmund! Fix pushed.

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

Re: [tor-bugs] #23766 [Applications/Tor Browser]: runc bash: cannot set terminal process group (8): Inappropriate ioctl for device

[Tor Bug Tracker & Wiki]

#23766: runc bash: cannot set terminal process group (8): Inappropriate ioctl 
for
device
--+--
 Reporter:  kkuehl@…  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by kkuehl@…):

 I figured out that this was due to me running dnsmasq which sets
 resolv.conf to 127.0.0.1 so when the container mounts
 After seeing:
  {
  "type": "bind",
  "source": "/etc/resolv.conf",
  "destination": "/etc/resolv.conf",
  "options": [
  "rbind",
  "ro"
  ]
  },

 It wouldn't work.
 Solution: put resonable values in resolv.conf and disable dnsmasq.

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kkuehl@…):

 The resolv.conf contents were the clue.
 After seeing:
 {
 "type": "bind",
 "source": "/etc/resolv.conf",
 "destination": "/etc/resolv.conf",
 "options": [
 "rbind",
 "ro"
 ]
 },

 I looked at resolv.conf on my main system and it was of course set to
 127.0.0.1.
 NOTE: This is common if your system is running dnsmasq

 Once I set this to 8.8.8.8 so the container would have something useful,
 things worked :)

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kkuehl@…):

 After looking at the contents of the pre shell script inside the
 container.
 cat pre
 #!/bin/sh
 set -e
 apt-get update -y
 apt-get install -y debian-archive-keyring ubuntu-keyring debootstrap
 debootstrap --arch=amd64  wheezy base-image
 tar -C ./base-image -czf /var/tmp/tmp.spYLcjXI7k/container-image_wheezy-
 amd64.tar.gz .

 I tried running pre and received errors like the following:
  Failed to fetch http://archive.ubuntu.com/ubuntu/dists/zesty/InRelease
 Temporary failure resolving 'archive.ubuntu.com'

 root@runc:/var/tmp/tmp.o9sbbmB4dP# cat /etc/resolv.conf
 # Generated by NetworkManager
 nameserver 127.0.1.1

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

Re: [tor-bugs] #23766 [Applications/Tor Browser]: runc bash: cannot set terminal process group (8): Inappropriate ioctl for device

[Tor Bug Tracker & Wiki]

#23766: runc bash: cannot set terminal process group (8): Inappropriate ioctl 
for
device
--+--
 Reporter:  kkuehl@…  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by kkuehl@…):

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


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

[tor-bugs] #23766 [- Select a component]: runc bash: cannot set terminal process group (8): Inappropriate ioctl for device

[Tor Bug Tracker & Wiki]

#23766: runc bash: cannot set terminal process group (8): Inappropriate ioctl 
for
device
--+
 Reporter:  kkuehl@…  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 $ sudo runc --version
 runc version 1.0.0-rc4
 spec: 1.0.0
 $ make testbuild-linux-x86_64
 git submodule update --init
 ./rbm/rbm build release --target testbuild --target torbrowser-linux-
 x86_64
 Building project tor-browser - tor-browser-7.5a5-linux-x86_64-a14a6a
 Building project container-image - container-image_wheezy-
 amd64-df3a332e7b34.tar.gz
 Building project debootstrap-image - container-image_wheezy-amd64.tar.gz
 Using file /home/kkuehl/Downloads/tor-browser-build/out/debootstrap-image
 /container-image_ubuntu-base-17.04-base-amd64.tar.gz
 Build log: /home/kkuehl/Downloads/tor-browser-build/logs/debootstrap-
 image-.log
 Error running build
 Opening debug shell
 Warning: build files will be removed when you exit this shell.
 Container directory: /home/kkuehl/Downloads/tor-browser-build/tmp/rbm-
 VVRGNR/rbm-
 containers/57870e7709fe3f3d4e0c557d05b94261d803b70d43e8298f6e2efebcf9477ac0
 bash: cannot set terminal process group (8): Inappropriate ioctl for
 device
 bash: no job control in this shell
 root@runc:/var/tmp/tmp.ILRlYNjrAb#

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kkuehl@…):

 $ sudo runc --version
 runc version 1.0.0-rc4
 spec: 1.0.0
 $ make testbuild-linux-x86_64
 git submodule update --init
 ./rbm/rbm build release --target testbuild --target torbrowser-linux-
 x86_64
 Building project tor-browser - tor-browser-7.5a5-linux-x86_64-a14a6a
 Building project container-image - container-image_wheezy-
 amd64-df3a332e7b34.tar.gz
 Building project debootstrap-image - container-image_wheezy-amd64.tar.gz
 Using file /home/kkuehl/Downloads/tor-browser-build/out/debootstrap-image
 /container-image_ubuntu-base-17.04-base-amd64.tar.gz
 Build log: /home/kkuehl/Downloads/tor-browser-build/logs/debootstrap-
 image-.log
 Error running build
 Opening debug shell
 Warning: build files will be removed when you exit this shell.
 Container directory: /home/kkuehl/Downloads/tor-browser-build/tmp/rbm-
 VVRGNR/rbm-
 containers/57870e7709fe3f3d4e0c557d05b94261d803b70d43e8298f6e2efebcf9477ac0
 bash: cannot set terminal process group (8): Inappropriate ioctl for
 device
 bash: no job control in this shell
 root@runc:/var/tmp/tmp.ILRlYNjrAb#

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kkuehl@…):

 From the referenced log:
 Starting build: Wed Oct  4 15:32:44 2017
 mesg: ttyname failed: Inappropriate ioctl for device
 Err:1 http://archive.ubuntu.com/ubuntu zesty InRelease
   Temporary failure resolving 'archive.ubuntu.com'
 Err:2 http://security.ubuntu.com/ubuntu zesty-security InRelease
   Temporary failure resolving 'security.ubuntu.com'
 Err:3 http://archive.ubuntu.com/ubuntu zesty-updates InRelease
   Temporary failure resolving 'archive.ubuntu.com'
 Err:4 http://archive.ubuntu.com/ubuntu zesty-backports InRelease
   Temporary failure resolving 'archive.ubuntu.com'
 Reading package lists...
 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/zesty/InRelease
 Temporary failure resolving 'archive.ubuntu.com'
 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/zesty-
 updates/InRelease  Temporary failure resolving 'archive.ubuntu.com'
 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/zesty-
 backports/InRelease  Temporary failure resolving 'archive.ubuntu.com'
 W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/zesty-
 security/InRelease  Temporary failure resolving 'security.ubuntu.com'
 W: Some index files failed to download. They have been ignored, or old
 ones used instead.
 Reading package lists...
 Building dependency tree...
 E: Unable to locate package debian-archive-keyring

 $ ping archive.ubuntu.com
 PING archive.ubuntu.com(danava.canonical.com (2001:67c:1360:8001::17)) 56
 data bytes
 64 bytes from danava.canonical.com (2001:67c:1360:8001::17): icmp_seq=1
 ttl=57 time=155 ms
 64 bytes from danava.canonical.com (2001:67c:1360:8001::17): icmp_seq=2
 ttl=57 time=152 ms

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kkuehl@…):

 git apply 23585.diff
 git status
 On branch master
 Your branch is up-to-date with 'origin/master'.
 Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git checkout -- ..." to discard changes in working
 directory)

 modified:   projects/common/runc-config.json
 modified:   rbm.conf
 make testbuild-linux-x86_64
 git submodule update --init
 ./rbm/rbm build release --target testbuild --target torbrowser-linux-
 x86_64
 Building project tor-browser - tor-browser-7.5a5-linux-x86_64-a14a6a
 Building project container-image - container-image_wheezy-
 amd64-df3a332e7b34.tar.gz
 Building project debootstrap-image - container-image_wheezy-amd64.tar.gz
 Using file /home/kkuehl/Downloads/tor-browser-build/out/debootstrap-image
 /container-image_ubuntu-base-17.04-base-amd64.tar.gz
 Build log: /home/kkuehl/Downloads/tor-browser-build/logs/debootstrap-
 image-.log
 Error running build
 Opening debug shell
 Warning: build files will be removed when you exit this shell.
 Container directory: /home/kkuehl/Downloads/tor-browser-build/tmp/rbm-
 nPJpET/rbm-
 containers/ba6fbe182fa7d3ed641c266de19acb5a779debdf260293a68080248c25106ff9
 mesg: ttyname failed: No such device
 bash: cannot set terminal process group (7): Inappropriate ioctl for
 device
 bash: no job control in this shell
 root@runc:/var/tmp/tmp.RzjlEWVmNu# exit

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

Re: [tor-bugs] #23754 [Applications/rbm]: rbm make failing do to golang error while unmarshalling json

[Tor Bug Tracker & Wiki]

#23754: rbm make failing do to golang error while unmarshalling json
--+---
 Reporter:  kkuehl@…  |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by kkuehl@…):

 * Attachment "23585.diff" added.

 patch from ticket 23585

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

Re: [tor-bugs] #23733 [Applications/Tor Browser]: Tor failed to launch in OSX

[Tor Bug Tracker & Wiki]

#23733: Tor failed to launch in OSX
--+---
 Reporter:  jakob4800 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability ux osx  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Replying to [comment:7 catalyst]:
 > Maybe Tor Launcher can detect when there's already a `tor.real` running
 and offer to kill it if it seems to prevent it from launching tor?

 I am wary about adding code to Tor Launcher that will kill processes that
 it does not own. The tor.real process should exit if the control port
 connection disappears or if the firefox process exits (Tor Launcher passes
 `__OwningControllerProcess` to tor and it issues a `TAKEOWNERSHIP` control
 port command).

 In this case, I assume this did not happen because the original reporter
 did this: '''i force ejected the disk image of tor while i had the
 application open.''' I am not sure what Bad Things happen if you do that,
 but I can imagine macOS does not handle everything cleanly. Usually macOS
 prevents you from ejecting a disk image that has files on it that are in
 use, so the user may have done a "Force Eject" even after receiving a
 warning. This seems like a rare scenario to me, so my preference would be
 to resolve this ticket as "Won't fix."

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

Re: [tor-bugs] #13575 [Applications/Tor Browser]: Disable randomised Firefox HTTP cache decay user test groups

[Tor Bug Tracker & Wiki]

#13575: Disable randomised Firefox HTTP cache decay user test groups
-+-
 Reporter:  isis |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-pref, tbb-fingerprinting,|  Actual Points:
  ff52-esr, tbb-easy |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  tbb-pref, tbb-fingerprinting, ff52-esr => tbb-pref, tbb-
 fingerprinting, ff52-esr, tbb-easy


Comment:

 Replying to [comment:4 gk]:
 > Thanks for contributing.
 Thank you too. We made a great progress for the last several years. So,
 glad to hear it from you.
 > We use `needs_review` for tickets that have patches attached we can
 reason about and merge if we think they are okay.
 `needs_review` was used to show that thorough code analysis didn't reveal
 anything wrong with the proposed solution, and it can be merged as is.
 > I am happy to consider a patch to get this ticket moved forward.
 Sure, but no one added it during 3 years, for some reason.
 > So, if you could attach one or point to some commit in a (preferably)
 git repository that would be great.
 It is so easy that it's better suited as an exercise for new job
 applicants.

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

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
+--
 Reporter:  kernelcorn  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-usability tbb-security  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by intrigeri):

 * cc: intrigeri (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] #23758 [Core Tor/Tor]: test config/include_no_permission fails when run as root

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails when run as root
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 hrm. Is there really nothing we can do to the directory that makes
 opendir() not open it?  If not, then we may as well take this 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] #23758 [Core Tor/Tor]: test config/include_no_permission fails when run as root

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails when run as root
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * version:   => Tor: 0.3.2.2-alpha


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

Re: [tor-bugs] #23758 [Core Tor/Tor]: test config/include_no_permission fails when run as root

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails when run as root
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

 * status:  accepted => needs_review


Comment:

 Proposed fix in https://oniongit.eu/catalyst/tor/merge_requests/10

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

[tor-bugs] #23765 [Internal Services/Service - git]: oniongit CI test runner out of disk?

[Tor Bug Tracker & Wiki]

#23765: oniongit CI test runner out of disk?
-+
 Reporter:  catalyst |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:  tor-ci
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 It looks like the CI runner on oniongit is out of disk space:
 {{{
 Preparing to unpack .../libglib2.0-0-refdbg_2.42.1-1+b1_amd64.deb ...
 Unpacking libglib2.0-0-refdbg:amd64 (2.42.1-1+b1) ...
 dpkg: error processing archive
 /var/cache/apt/archives/libglib2.0-0-refdbg_2.42.1-1+b1_amd64.deb
 (--unpack):
  cannot copy extracted data for './usr/lib/x86_64-linux-
 gnu/refdbg/libgobject-2.0.so.0.4200.1' to '/usr/lib/x86_64-linux-
 gnu/refdbg/libgobject-2.0.so.0.4200.1.dpkg-new': failed to write (No space
 left on device)
 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
 Processing triggers for systemd (215-17+deb8u7) ...
 dpkg: error: failed to write status database record about 'mono-gac' to
 '/var/lib/dpkg/status': No space left on device
 E: Sub-process /usr/bin/dpkg returned an error code (2)
 ERROR: Job failed: exit code 1
 }}}
 Or maybe that's just the Docker container?  I can't tell.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23764 [Core Tor/Tor]: hs-v3: No live consensus on client with a bridge

[Tor Bug Tracker & Wiki]

#23764: hs-v3: No live consensus on client with a bridge
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Today we got someone coming in the v3 testing hub IRC channel that
 couldn't use v3 onion at all.

 Turns out that this log kept happening for any v3 address:

 {{{
 [info] hs_client_refetch_hsdesc(): Can't fetch descriptor for service
 [scrubbed] because we are missing a live consensus. Stalling connection.
 }}}

 But its tor never got a live consensus. We could see it was trying to get
 it from its bridge:

 {{{
 [info] Received http status code 304 ("Not modified") from server
 'BRIDGE_IP' while fetching consensus directory.
 }}}

 So, somehow the bridge has a consensus that thinks is live enough to
 use but when the client gets it, it doesn't think it is live. I can
 imagine clock skew between the client and bridge could be causing this?

 Thus, this makes me question the use of "live consensus" in the HS v3
 subsystem. v2 doesn't look for that at all, it only cares if tor has
 completed a circuit then it uses the consensus even if not live.

 Maybe client side could only use the consensus tor thinks it can use and
 we hope that it is enough to reach the service?

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

[tor-bugs] #23763 [Core Tor/Tor]: hs-v3: If a client can't launch a desc fetch, it shouldn't try to open IP/RP circuits

[Tor Bug Tracker & Wiki]

#23763: hs-v3: If a client can't launch a desc fetch, it shouldn't try to open
IP/RP circuits
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Because the SOCKS connection is put in "circuit wait" state if we are ever
 missing dirinfo, tor connection subsystem will try to launch the IP/RP
 because it thinks the socks request is waiting for those circuits.

 The IP circuit won't work because we can't pick an intro point from the
 non existing descriptor so that is OK but the RP is still launched. It
 could be OK but then it can timeout if getting the descriptor takes too
 long or if the .onion simply doesn't exists.

 Because of #23762, I think the right solution here is to have a new AP
 connection state that is "missing dirinfo" and just avoid entirely to try
 to open circuits in that situation.

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

Re: [tor-bugs] #23758 [Core Tor/Tor]: test config/include_no_permission fails when run as root (was: test config/include_no_permission fails on gitlab.com CI because Docker?)

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails when run as root
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by catalyst:

Old description:

> I managed to get the gitlab.com CI running using the `.gitlab-ci.yml` on
> master.  (There are other issues with that CI configuration; see #23755
> and #23756.)  It fails with
> {{{
> config/include_no_permission:
>   FAIL src/test/test_config.c:4975:
> assert(config_get_lines_include(torrc_contents, , 0,_used)
> OP_EQ -1): 0 vs -1
>   [include_no_permission FAILED]
> }}}
>
> As far as I can tell, this can only happen if `opendir()` can succeed on
> a mode `0100` directory.  Maybe this strange thing can happen in the
> Docker environment that runs gitlab.com CI jobs?  I don't know enough
> about Docker to say how plausible that explanation is.

New description:

 I managed to get the gitlab.com CI running using the `.gitlab-ci.yml` on
 master.  (There are other issues with that CI configuration; see #23755
 and #23756.)  It fails with
 {{{
 config/include_no_permission:
   FAIL src/test/test_config.c:4975:
 assert(config_get_lines_include(torrc_contents, , 0,_used)
 OP_EQ -1): 0 vs -1
   [include_no_permission FAILED]
 }}}

 As far as I can tell, this can only happen if `opendir()` can succeed on a
 mode `0100` directory.  Maybe this strange thing can happen in the Docker
 environment that runs gitlab.com CI jobs?  I don't know enough about
 Docker to say how plausible that explanation is.

 Edit: This seems to be because the gitlab.com CI runs as root.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23762 [Core Tor/Tor]: hs-v3: Client request with missing dirinfo will always timeout

[Tor Bug Tracker & Wiki]

#23762: hs-v3: Client request with missing dirinfo will always timeout
--+-
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224, tor-client
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 When the SOCKS request is handled in `connection_ap_handle_onion()`, if we
 are missing dirinfo (including missing a live consensus), the connection
 state is put in "AP_CONN_STATE_CIRCUIT_WAIT".

 Then it is retried every second through
 `connection_ap_handshake_attach_circuit()` which does a gazillion things
 but among those it tries to open the IP/RP circuits. Of course, we can't
 get an IP because we have no descriptor so
 `circuit_get_open_circ_or_launch()`, which tries to get that IP circuit,
 won't be able so that function will get an intro point from the descriptor
 (that doesn't exists because we can't even fetch it) but won't work.

 It then triggers a descriptor fetch and then puts the connection in
 `AP_CONN_STATE_RENDDESC_WAIT`. Now, because we don't look at the returned
 code, we don't know what really happened and if tor still doesn't have
 enough dirinfo to proceed, the connection is still put in "renddesc wait"
 making it NOT a pending connection anymore thus never retried after that.

 The only way for a connection to get out of that "renddesc wait" state is
 either timing out (which is what happens for v3) or the descriptor arrives
 and then there is a callback in the HS client subsystem to handle that
 desc.

 The possible solutions are I believe:

 1. Either we keep the connection in "circuit wait" so it gets retried
 regularly.

 2. We create a new "AP CONN" state that is "waiting for dirinfo" and then
 when we get the live consensus or/and minimum dirinfo, we callback the HS
 subsystem and look for SOCKS conn in that state.

 This is not a problem v2 HS suffers because it only care about a
 "reasonably live consensus".

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

Re: [tor-bugs] #23758 [Core Tor/Tor]: test config/include_no_permission fails on gitlab.com CI because Docker?

[Tor Bug Tracker & Wiki]

#23758: test config/include_no_permission fails on gitlab.com CI because Docker?
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci tor-tests  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by catalyst):

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


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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 I'm a little suspicious of this stack trace. scheduler_init() shouldn't be
 getting called when Tor has already been running for 10 days; what is it
 doing there?  And since when does scheduler_init call
 channel_flush_some_cells or update_socket_written?

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

Re: [tor-bugs] #23751 [Core Tor/Tor]: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.

[Tor Bug Tracker & Wiki]

#23751: [warn] tor_bug_occurred_: Bug: src/common/buffers.c, etc.
+--
 Reporter:  Felixix |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-channel, tor-sched, tor-buffer  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by nickm):

 Another possibility to consider is integer underflow of some kind.

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

Re: [tor-bugs] #23756 [Core Tor/Tor]: tor's .gitlab-ci.yml is doing mirroring? why?

[Tor Bug Tracker & Wiki]

#23756: tor's .gitlab-ci.yml is doing mirroring? why?
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 I would like to add that we should consider the variety of different
 automated processes that will interpret our `.gitlab-ci.yml` now that we
 have published it, not all of which share the same goals.  These include
 (but are not limited to):
 * The network/tor.git on our own self-hosted gitlab
 * Network team members' repositories on our own self-hosted gitlab
 * People's repositories on gitlab.com (or maybe some of them also self-
 host)
 Keeping an official (read-only) mirror on oniongit has different
 requirements than a developer keeping their forked repo in sync with
 upstream.  Some developers might be OK with the risk of having their
 branches clobbered by a force-push of the upstream ones; others might want
 to confine those to an `upstream/` namespace.  (It looks like the
 gitlab.com mirroring does both the `upstream/` namespace and maybe some
 conflict-detection for the unqualified branch names?)  Some might want to
 do all their upstream repository synchronization manually.

 Requiring the setting of some (well-documented!) CI variables in the
 repository before doing mirroring might be a good idea.

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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_key() in extend_info_from_node()

[Tor Bug Tracker & Wiki]

#23760: Use node_get_curve25519_key() in extend_info_from_node()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, refactor |
Parent ID:  #23577   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 ntor_key, ntor_onion_key, curve25519_ntor_key, and curve25519_onion_key
 are also good names for this key -- we just shouldn't call it
 curve25519_key (with no indication of its purpose).

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

Re: [tor-bugs] #23757 [Core Tor/Tor]: tor's .gitlab-ci.yml doesn't have the same behaviour as our .travis.yml

[Tor Bug Tracker & Wiki]

#23757: tor's .gitlab-ci.yml doesn't have the same behaviour as our .travis.yml
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 Maybe we should have helper scripts that can run in a variety of different
 CI environments with small parameter changes.

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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_key() in extend_info_from_node()

[Tor Bug Tracker & Wiki]

#23760: Use node_get_curve25519_key() in extend_info_from_node()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, refactor |
Parent ID:  #23577   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 If we do this, we should rename the existing
 `node_has_curve25519_onion_key()` to `node_has_ntor_key()`.

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

Re: [tor-bugs] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Also, are we going to regret the transition away from IF_BUG_ONCE? Will
 this flood people's logs now?

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

Re: [tor-bugs] #23733 [Applications/Tor Browser]: Tor failed to launch in OSX

[Tor Bug Tracker & Wiki]

#23733: Tor failed to launch in OSX
--+---
 Reporter:  jakob4800 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability ux osx  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by catalyst):

 * keywords:  tbb-usability ux => tbb-usability ux osx


Comment:

 When this came up recently on IRC (I don't know if the reporter is the
 same person), there was a background `tor.real` process that prevented the
 tor subprocess from launching.  I think it might have been due to a Tor
 Browser auto-update to 7.0.6 given the timing but there wasn't really
 enough information to be sure.

 Maybe Tor Launcher can detect when there's already a `tor.real` running
 and offer to kill it if it seems to prevent it from launching 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] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 bcaa6b5159d67e4420e8db17a9fbfde760a69529 looks like it needs an if?

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

Re: [tor-bugs] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => needs_revision


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

Re: [tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merged; added credit.

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

Re: [tor-bugs] #21445 [Applications/Tor Browser]: Launching Tor Browser from the .dmg should obviously fail or install correclty, not neither

[Tor Bug Tracker & Wiki]

#21445: Launching Tor Browser from the .dmg should obviously fail or install
correclty, not neither
--+--
 Reporter:  pastly|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, ff52-esr, osx  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:  tbb-usability, ff52-esr => tbb-usability, ff52-esr, osx


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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * status:  needs_revision => needs_information


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

Re: [tor-bugs] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  new => needs_information


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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance 031-backport 030-backport  |
  029-backport   |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-

Comment (by teor):

 FYI, the scheduler bug in the log is fixed in #23696:
 {{{
 Tor WARN: tor_bug_occurred_(): Bug: scheduler_kist.c:520:
 kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed. (Future
 instances of this warning will be silenced.) (on Tor 0.3.2.1-alpha )
 Tor WARN: Bug: Non-fatal assertion !((diff < 0)) failed in
 kist_scheduler_schedule at scheduler_kist.c:520. (Stack trace not
 available) (on Tor 0.3.2.1-alpha )
 }}}

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

Re: [tor-bugs] #23597 [Metrics/Library]: Correct links in metrics-lib overview page.

[Tor Bug Tracker & Wiki]

#23597: Correct links in metrics-lib overview page.
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  karsten  |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Looks good, merged. 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

Re: [tor-bugs] #23753 [Core Tor/Tor]: sched: Implement a SCHED_BUG() that prints more information

[Tor Bug Tracker & Wiki]

#23753: sched: Implement a SCHED_BUG() that prints more information
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 ack lgtm.

 pastly's branch `ticket23753_032_01` is what should be considered for
 merge. 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] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 It is for non-e10s only. As you see it is already disabled in e10s and
 removed in upstream. Some legacy things would break in non-e10s, but
 that's not what we should take care of. (So you want the backported patch
 to remove it completely, but it looks better to keep the pref, if somebody
 would complain.)

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
--+--
 Reporter:  iwakeh|  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics   |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-2017  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by iwakeh):

 * keywords:   => metrics-2017


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

Re: [tor-bugs] #23597 [Metrics/Library]: Correct links in metrics-lib overview page.

[Tor Bug Tracker & Wiki]

#23597: Correct links in metrics-lib overview page.
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  karsten  |Sponsor:
-+---
Changes (by iwakeh):

 * reviewer:   => karsten


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

Re: [tor-bugs] #23760 [Core Tor/Tor]: Use node_get_curve25519_key() in extend_info_from_node()

[Tor Bug Tracker & Wiki]

#23760: Use node_get_curve25519_key() in extend_info_from_node()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, refactor |
Parent ID:  #23577   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Maybe call it node_get_ntor_key() instead?

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

Re: [tor-bugs] #22548 [Applications/Tor Browser]: Firefox downgrades VP9 videos to VP8 when measured performance is not enough

[Tor Bug Tracker & Wiki]

#22548: Firefox downgrades VP9 videos to VP8 when measured performance is not
enough
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 Replying to [comment:14 gk]:
 > Replying to [comment:13 cypherpunks]:
 > > Set `media.benchmark.vp9.threshold` to `0` to fix this ticket without
 patching.
 >
 > Thanks for this suggestion.
 This is not only a suggestion, but the result of code analysis.
 > What are the implications of this proposed fix? (We'd need a patch for
 it as well)
 All clients will get better experience and lower traffic, because TBB
 doesn't use `Use hardware acceleration when available` anyway. (Code
 analysis shows that you don't need a patch, `-#include "WebMSample.h"` is
 for cleanup only.)

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

Re: [tor-bugs] #23716 [Metrics/Website]: Rename Operation section to Services

[Tor Bug Tracker & Wiki]

#23716: Rename Operation section to Services
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 I think the renaming would improve the site.  There doesn't need to be a
 common theme in the sense 'we provide xyz' or similar.  It is more
 important that a first time user can sort of guess what could be behind a
 link.

 Do we really need the redirects?  Not that many people might have
 bookmarked operation.html (during fourteen days of logs there were 34
 requests/day for this page on average compared to 594 for userstats-relay-
 country or 178 for userstats-bridge-country).

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

Re: [tor-bugs] #22538 [Applications/Tor Browser]: Changing circuit for page with error switches catch-all circuit instead

[Tor Bug Tracker & Wiki]

#22538: Changing circuit for page with error switches catch-all circuit instead
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


Comment:

 > Changing circuit for page with error switches catch-all circuit instead
 The page with error usually is `about:*`, so that's technically correct to
 switch its circuit (catch-all), but it's not what is expected. If some
 error page is caused by bad circuit, then it's necessary to change it, but
 it's impossible. Thus, `tbb-usability-website`.
 TBB has no feature to remove linkability by switching circuits, everything
 is perfectly linkable by cookies.

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

Re: [tor-bugs] #23748 [Core Tor/Tor]: inconsistent/redundant handling of hs_ed25519_public_key file

[Tor Bug Tracker & Wiki]

#23748: inconsistent/redundant handling of hs_ed25519_public_key file
-+
 Reporter:  cathugger|  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by asn):

 LGTM!

 Perhaps worth crediting cathugger in the changes file tho.

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

Re: [tor-bugs] #13575 [Applications/Tor Browser]: Disable randomised Firefox HTTP cache decay user test groups

[Tor Bug Tracker & Wiki]

#13575: Disable randomised Firefox HTTP cache decay user test groups
-+-
 Reporter:  isis |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-pref, tbb-fingerprinting,|  Actual Points:
  ff52-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => assigned


Comment:

 Thanks for contributing. We use `needs_review` for tickets that have
 patches attached we can reason about and merge if we think they are okay.
 I am happy to consider a patch to get this ticket moved forward. So, if
 you could attach one or point to some commit in a (preferably) git
 repository that would be great.

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:3 cypherpunks]:
 > Set `dom.disable_window_showModalDialog` to `true` to fix the obvious
 part of this ticket without patching.

 But that prevents the parent process from using that feature as well,
 right? Do we have some estimate about what that would break? (We'd need a
 patch for actual 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] #22548 [Applications/Tor Browser]: Firefox downgrades VP9 videos to VP8 when measured performance is not enough

[Tor Bug Tracker & Wiki]

#22548: Firefox downgrades VP9 videos to VP8 when measured performance is not
enough
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-fingerprinting|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  needs_review => needs_information
 * keywords:  tbb-fingerprinting, tbb-easy => tbb-fingerprinting


Comment:

 Replying to [comment:13 cypherpunks]:
 > Set `media.benchmark.vp9.threshold` to `0` to fix this ticket without
 patching.

 Thanks for this suggestion. What are the implications of this proposed
 fix? (We'd need a patch for it as well)

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

Re: [tor-bugs] #23733 [Applications/Tor Browser]: Tor failed to launch in OSX

[Tor Bug Tracker & Wiki]

#23733: Tor failed to launch in OSX
--+---
 Reporter:  jakob4800 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability ux  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Does starting Tor Browser from a shell like
 `/Applications/TorBrowser.app/Contents/MacOS/firefox` give you some output
 in the terminal which could shed some light on your proplem?

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

Re: [tor-bugs] #22538 [Applications/Tor Browser]: Changing circuit for page with error switches catch-all circuit instead

[Tor Bug Tracker & Wiki]

#22538: Changing circuit for page with error switches catch-all circuit instead
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:3 gk]:
 > The usability of the website is not affected by that. Could you explain
 your reasoning behind the keyword change? (Reverting it back to the
 original one meanwhile)

 Expanding on that: I think the option to change a circuit for a particular
 domain might indeed perceived as an easy way to reduce linkability (which
 it actually even is). So, if that's not working but the old circuit is
 still used as only the catch-all one gets rotated that's bad.

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

Re: [tor-bugs] #23597 [Metrics/Library]: Correct links in metrics-lib overview page.

[Tor Bug Tracker & Wiki]

#23597: Correct links in metrics-lib overview page.
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-23597 this patch].

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

Re: [tor-bugs] #22538 [Applications/Tor Browser]: Changing circuit for page with error switches catch-all circuit instead

[Tor Bug Tracker & Wiki]

#22538: Changing circuit for page with error switches catch-all circuit instead
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * keywords:  tbb-usability-website => tbb-linkability
 * status:  new => needs_information


Comment:

 The usability of the website is not affected by that. Could you explain
 your reasoning behind the keyword change? (Reverting it back to the
 original one meanwhile)

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

Re: [tor-bugs] #23629 [Applications/Tor Browser]: CSP error reports not sent - intended/safe ?

[Tor Bug Tracker & Wiki]

#23629: CSP error reports not sent - intended/safe ?
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 An example URL would be handy. I think we did not block this
 intentionally. It might be a side-effect by removing other data reporting
 options.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+---
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201710R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Thanks. Applied to `tor-browser-52.4.0esr-7.5-1` as commit
 e3b99866dbdc29a2949d0a53806b99a94f34cc73.

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Major| Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance 031-backport 030-backport  |
  029-backport   |
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-

Comment (by cypherpunks):

 Okay. What do we have after hibernation?
 {{{
 Tor NOTICE: Your system clock just jumped 45518 seconds forward; assuming
 established circuits no longer work.
 Tor NOTICE: Heartbeat: Tor's uptime is 3:46 hours, with 1 circuits open.
 I've sent 1.97 MB and received 12.17 MB.
 Tor NOTICE: Average packaged cell fullness: 53.187%. TLS write overhead:
 4%
 Tor WARN: tor_bug_occurred_(): Bug: scheduler_kist.c:520:
 kist_scheduler_schedule: Non-fatal assertion !((diff < 0)) failed. (Future
 instances of this warning will be silenced.) (on Tor 0.3.2.1-alpha )
 Tor WARN: Bug: Non-fatal assertion !((diff < 0)) failed in
 kist_scheduler_schedule at scheduler_kist.c:520. (Stack trace not
 available) (on Tor 0.3.2.1-alpha )
 Tor WARN: circuit_package_relay_cell(): Bug: outgoing relay cell sent from
 src/or/relay.c:825 has n_chan==NULL. Dropping. (on Tor 0.3.2.1-alpha )
 Tor WARN: Bug: . (Stack trace not available) (on Tor 0.3.2.1-alpha )
 Tor NOTICE: Tor has successfully opened a circuit. Looks like client
 functionality is working.
 Tor WARN: Failed to find node for hop #1 of our path. Discarding this
 circuit.
 Tor NOTICE: Scheduler type KISTLite has been enabled.
 }}}
 Seems `with 1 circuits open` points to the root cause of 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] #23046 [Metrics/Library]: Add sub-interface LogDescriptor.LogLine (and the extension to WebServerAccessLogLine)

[Tor Bug Tracker & Wiki]

#23046: Add sub-interface LogDescriptor.LogLine (and the extension to
WebServerAccessLogLine)
-+---
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_information => accepted
 * owner:  metrics-team => iwakeh


Comment:

 The first step is to provide the interface definitions and extensions
 based on the latest branch in #22983.
 Once everyone is happy with these definitions the implementation will
 follow.

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

Re: [tor-bugs] #21751 [Metrics/Library]: Use multiple threads to parse descriptors

[Tor Bug Tracker & Wiki]

#21751: Use multiple threads to parse descriptors
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Look at java 8 features for accoplishing this task, e.g. #23752 comments
 6&2.

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Make use of new functionality in java.util.concurrent (for example in
 #21751 together with parallel streams).

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Use `Optional` wherever appropriate instead of `null` values.

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Use `java.util.Base64` instead of other classes for de/encoding.

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

Re: [tor-bugs] #23752 [Metrics]: Use Java 8 features in all of Metrics' Java products (Summary ticket)

[Tor Bug Tracker & Wiki]

#23752: Use Java 8 features in all of Metrics' Java products  (Summary ticket)
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Use java 8 methods from 'Files' wherever useful, e.g., `lines`, `walk`,
 newBufferedReader`, `readAllLines` etc.

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

Re: [tor-bugs] #23724 [Applications/Tor Browser]: NoScript restartless update breaks Security Slider and its icon disappears

[Tor Bug Tracker & Wiki]

#23724: NoScript restartless update breaks Security Slider and its icon 
disappears
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 {{{
 [10-04 08:01:29] Torbutton WARN: New Identity: Error clearing NoScript
 Temporary Permissions: [Exception... "Component returned failure code:
 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"
 nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS
 frame :: chrome://torbutton/content/torbutton.js ::
 torbutton_do_new_identity :: line 1058"  data: no]
 }}}

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