Re: [tor-bugs] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sysrqb):

 Also, in the release announcement, we should say the Security Slider
 setting will be reset. If the user changed the setting, they should reset
 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] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+---
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 I think it is intentional that the app profile extensions override the
 system addon: [https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/extensions/internal/XPIProvider.jsm#n2105
 in XPIProvider] - at least this is how I am reading it.

 I wonder if we should do something slightly hacky. In the
 `PostUpdateHandler`, when the system extensions are copied into the
 `features/` dir, we check if the same addon is already installed in the
 profile, and we uninstall it if it is found. (I don't know how to initiate
 an uninstall of an addon from Java - [https://gitweb.torproject.org/tor-
 browser.git/tree/mobile/android/chrome/content/aboutAddons.js#n344 the
 javascript is context sensitive] - plus it requires another restart before
 it is it fully uninstalled, but that's another problem).

 The third problem is preferences.json isn't copied from the apk into the
 app's data directory. I think this is because the the app
 [https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n520
 sets a preference] (`distribution_state`) when initialization completes,
 and then it [https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n491
 never copies new files] from newer APKs during an update.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26666, #26692, #26701, #26740, ...

[Tor Bug Tracker & Wiki]

Batch modification to #2, #26692, #26701, #26740, #26848, #26862, #26881, 
#26926, #27108, #27135, #27336, #27337, #27338, #27340, #27341, #27386, #27398, 
#27688, #27692, #27705, #27960, #27975, #27976, #27996, #28141, #28197, #28215, 
#28216, #28365, #28366, #28379, #28442, #28446, #28460, #28461, #28537, #28564, 
#28572 by teor:
milestone to sbws: 1.0.x-final

Comment:
Move all closed sbws 1.0 must tickets to sbws 1.0.x-final

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #26683, #26736, #27358, #27704, ...

[Tor Bug Tracker & Wiki]

Batch modification to #26683, #26736, #27358, #27704, #27706, #27773, #28040, 
#28041, #28042, #28043, #28061, #28062, #28103, #28155, #28159, #28451, #28500, 
#26751 by teor:
milestone to sbws: 1.0.x-final

Comment:
Move all closed sbws 1.0 nice tickets to sbws 1.0.x-final

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #27107, #28158, #28224, #28547, ...

[Tor Bug Tracker & Wiki]

Batch modification to #27107, #28158, #28224, #28547, #28563, #28565, #28566, 
#28567 by teor:
milestone to sbws 1.0.4

Comment:
Moving all sbws 1.0 must planning and feature tickets to 1.0.4.

--
Tickets URL: 

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

Re: [tor-bugs] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 A fresh installation where torbutton is installed as a system addon look
 like this (I don't see any log entries where it is explicitly
 installed...but it is and it works):

 {{{
 11-28 02:19:07.403  8977  8994 D GeckoProfile: Created new profile dir.
 11-28 02:19:07.406  8977  8994 I GeckoProfile: Enqueuing profile init.
 11-28 02:19:07.408  8977  9000 E GeckoLibLoad: Load sqlite done
 11-28 02:19:07.408  8977  9000 E GeckoLibLoad: Load nss start
 11-28 02:19:07.408  8977  9000 E GeckoLibLoad: Load nss done
 11-28 02:19:07.409  8977  8994 D GeckoProfile: Found profile dir.
 11-28 02:19:07.409  8977  8994 D GeckoProfile: Attempting to write new
 client ID
 11-28 02:19:07.424  8977  8994 D GeckoDistribution: Creating
 /data/user/0/org.torproject.torbrowser_alpha/distribution/extensions
 11-28 02:19:07.474  8977  8977 D GeckoDistribution: Custom distribution
 directory not found.
 11-28 02:19:07.551  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.563  8977  8994 D PostUpdateHandler: Build ID changed since
 last start: '20181128015826', 'null'
 11-28 02:19:07.563  8977  8994 D PostUpdateHandler: Copying system add-ons
 from APK to dataDir
 11-28 02:19:07.565  8977  8994 D PostUpdateHandler: Copying
 'features/torbut...@torproject.org.xpi' from APK to dataDir
 11-28 02:19:07.566  8977  8994 D PostUpdateHandler: Creating
 /data/user/0/org.torproject.torbrowser_alpha/features
 11-28 02:19:07.567  8977  8994 D GeckoSessInfo: Recording start of
 session: 1543371547435
 11-28 02:19:07.567  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.567  8977  8994 E GeckoDistribution: Distribution
 preferences.json has no Global entry!
 11-28 02:19:07.568  8977  8994 D GeckoApplication: Running post-
 distribution task: bookmarks.
 11-28 02:19:07.568  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.568  8977  8994 E GeckoDistribution: Distribution directory
 exists, but no file named bookmarks.json
 11-28 02:19:07.738  8977  8994 D GeckoApplication: Running post-
 distribution task: android preferences.
 11-28 02:19:07.738  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.740  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.745  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.746  8977  8994 I GeckoSearchEngineManager: This is Tor
 Browser. Skipping.
 11-28 02:19:07.746  8977  8994 D GeckoSearchEngineManager: Found default
 engine name in browsersearch.json.
 11-28 02:19:07.746  8977  8994 D GeckoDistribution: Getting file from
 distribution.
 11-28 02:19:07.746  8977  8994 E GeckoDistribution: Distribution directory
 exists, but no file named searchplugins
 11-28 02:19:10.293  8977  9000 I Gecko   : 1543371550290addons.xpi
 WARNList of valid built-in add-ons could not be parsed.: [Exception...
 "Component returned failure code: 0x80520001
 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]"
 nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)"  location: "JS
 frame :: resource://gre/modules/addons/XPIProvider.jsm :: _readAddons ::
 line 6484"  data: no] Stack trace:
 _readAddons()@resource://gre/modules/addons/XPIProvider.jsm:6484
 11-28 02:19:10.293  8977  9000 I Gecko   :
 getAddonLocations()@resource://gre/modules/addons/XPIProvider.jsm:6145
 11-28 02:19:10.293  8977  9000 I Gecko   :
 getInstallState()@resource://gre/modules/addons/XPIProvider.jsm:1601
 11-28 02:19:10.293  8977  9000 I Gecko   :
 checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:3295
 11-28 02:19:10.293  8977  9000 I Gecko   :
 startup()@resource://gre/modules/addons/XPIProvider.jsm:2203
 11-28 02:19:10.293  8977  9000 I Gecko   :
 callProvider()@resource://gre/modules/AddonManager.jsm:258
 11-28 02:19:10.293  8977  9000 I Gecko   :
 _startProvider()@resource://gre/modules/AddonManager.jsm:733
 11-28 02:19:10.293  8977  9000 I Gecko   :
 startup()@resource://gre/modules/AddonManager.jsm:921
 11-28 02:19:10.293  8977  9000 I Gecko   :
 startup()@resource://gre/modules/AddonManager.jsm:3005
 11-28 02:19:10.293  8977  9000 I Gecko   :
 observe()@jar:jar:file:///data/app/org.torproject.torbrowser_alp
 11-28 02:19:10.394  8977  9000 D GeckoThread: 

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #28458, #28471, #28585, #28588, ...

[Tor Bug Tracker & Wiki]

Batch modification to #28458, #28471, #28585, #28588, #28596, #28598, #28602, 
#28639 by teor:
milestone to sbws 1.0.3

Comment:
Moving all sbws 1.0 must bugs to 1.0.3.

--
Tickets URL: 

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #28099, #28582, #28589, #28590

[Tor Bug Tracker & Wiki]

Batch modification to #28099, #28582, #28589, #28590 by teor:
milestone to sbws 1.0.4

Comment:
Moving all sbws 1.0 nice tickets to 1.0.4

--
Tickets URL: 

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

Re: [tor-bugs] #28639 [Core Tor/sbws]: After several days, most of the circuits timeout

[Tor Bug Tracker & Wiki]

#28639: After several days, most of the circuits timeout
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by teor):

 What does tor say in its logs?

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

Re: [tor-bugs] #28463 [Core Tor/sbws]: Measure exits as non-exits with 50% probability

[Tor Bug Tracker & Wiki]

#28463: Measure exits as non-exits with 50% probability
---+--
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.1
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * parent:  #28458 =>


Comment:

 Un-parenting, so we don't accidentally work on this ticket in sbws 1.0

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

Re: [tor-bugs] #28625 [Applications/Tor Browser]: Tor Browser gets stuck

[Tor Bug Tracker & Wiki]

#28625: Tor Browser gets stuck
--+---
 Reporter:  kanda |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gapegas7uftp):

 kanda:
 good inf on pastebin

 gk & tbb-team:
 This happens to me a lot, just browsing on slashdot in "Safest" security
 level
 It will freeze, like many times when I am scrolling down. One core will
 peg at 100% when it is frozen, usually 10-30 seconds, sometimes longer.
 Usually with 3-8 tabs open, but not predictible.

 I run uBlock Origin, not Adblock Plus, but maybe is same issue? Otherwise
 clean tor browser.

 Worked OK on tor browser 7.x, problem started with 8.x.
 Problem on Ubuntu 18.04 32-bit, and also on Ubuntu 18.10 64-bit --- same.

 Slashdot has a lot of blocking on uBlock Origin, sometime over 100, not
 sure if that is why? But it happens on other sites, too, not just
 slashdot.

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

Re: [tor-bugs] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+

Comment (by teor):

 I suggest that you split this change into two separate tickets.

 We can merge the tor_addr_is_internal_ change, then work on the new
 consensus method for private_nets.

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

Re: [tor-bugs] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 This change to private_nets needs a new consensus method:
 {{{
 It is important
  *  that all authorities agree on that list when creating summaries, so
 don't
  *  just change this without a proper migration plan and a proposal and
 stuff.
 }}}

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

Re: [tor-bugs] #28588 [Core Tor/sbws]: SBWS 'bw_torflow_scale' does not appear to honor relay MaxAdvertisedBandwidth

[Tor Bug Tracker & Wiki]

#28588: SBWS 'bw_torflow_scale' does not appear to honor relay
MaxAdvertisedBandwidth
---+-
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:  sbws: 1.0.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:11 juga]:
 > If i refactor, then i'll need to modify the branch and this ticket
 should be in needs_revision

 I still think the refactor is a bad idea, see:
 https://trac.torproject.org/projects/tor/ticket/28600#comment:5

 I think we should merge this branch as it is.

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

Re: [tor-bugs] #28600 [Core Tor/sbws]: Refactor: store the minimum of the bandwidth values from the consenus in the results

[Tor Bug Tracker & Wiki]

#28600: Refactor: store the minimum of the bandwidth values from the consenus in
the results
---+
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 How does the refactor make the code easier to understand?

 The torflow code was really hard to understand, because the min() was
 hidden in pytorctl.
 Now you want to add the same problem to sbws. I don't understand why.

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

Re: [tor-bugs] #26770 [Core Tor/Tor]: Implement proposal 293: "Other ways for relays to know when to publish"

[Tor Bug Tracker & Wiki]

#26770: Implement proposal 293: "Other ways for relays to know when to publish"
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop293, prop275, 040-roadmap-   |  Actual Points:  .1
  proposed   |
Parent ID:  #21642   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Please see my review on the pull request: my main questions are about
 testing, and keeping flags in sync as we add new flags.

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

[tor-bugs] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #25013, torbutton was added as a system addon in TBA, but it seems like
 the app continues using the version in the profile after the app upgrade.
 I toggled `extensions.logging.enabled`, these are some of the log entries.

 torbutton is copied into the app's writable storage, but it isn't
 installed. It also doesn't find the new `preferences.json` file.

 {{{
 11-28 01:23:40.492  8476  8493 D GeckoProfile: Found profile dir.
 11-28 01:23:40.539  8476  8476 D StrictMode:at
 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
 11-28 01:23:40.546  8476  8493 D PostUpdateHandler: Build ID changed since
 last start: '20181128012042', '20181128011144'
 11-28 01:23:40.546  8476  8493 D PostUpdateHandler: Copying system add-ons
 from APK to dataDir
 11-28 01:23:40.548  8476  8493 D PostUpdateHandler: Copying
 'features/torbut...@torproject.org.xpi' from APK to dataDir
 11-28 01:23:40.552  8476  8493 D PostUpdateHandler: Creating
 /data/user/0/org.torproject.torbrowser_alpha/features
 11-28 01:23:40.558  8476  8493 D GeckoSessInfo: Recording start of
 session: 1543368220513
 11-28 01:23:40.558  8476  8493 D GeckoDistribution: Getting file from
 distribution.
 11-28 01:23:40.558  8476  8493 E GeckoDistribution: Distribution directory
 exists, but no file named preferences.json
 11-28 01:23:40.558  8476  8493 D GeckoSearchEngineManager: Found default
 engine name in SharedPreferences: DuckDuckGo
 11-28 01:23:40.558  8476  8493 D GeckoDistribution: Getting file from
 distribution.
 11-28 01:23:43.111  8476  8496 I Gecko   : 1543368223110
 addons.manager  DEBUG   Loaded provider scope for
 resource://gre/modules/addons/XPIProvider.jsm: ["XPIProvider",
 "XPIInternal"]
 11-28 01:23:43.114  8476  8496 I Gecko   : 1543368223114
 addons.manager  DEBUG   Loaded provider scope for
 resource://gre/modules/LightweightThemeManager.jsm:
 ["LightweightThemeManager"]
 11-28 01:23:43.137  8476  8496 I Gecko   : 1543368223136
 addons.manager  DEBUG   Loaded provider scope for
 resource://gre/modules/addons/GMPProvider.jsm
 11-28 01:23:43.137  8476  8496 I Gecko   : 1543368223137
 addons.manager  DEBUG   Starting provider: XPIProvider
 11-28 01:23:43.137  8476  8496 I Gecko   : 1543368223137addons.xpi
 DEBUG   startup
 11-28 01:23:43.139  8476  8496 I Gecko   : 1543368223139addons.xpi
 INFOSystemAddonInstallLocation directory is missing
 11-28 01:23:43.140  8476  8496 I Gecko   : 1543368223139addons.xpi
 DEBUG   checkForChanges
 11-28 01:23:43.141  8476  8496 I Gecko   : 1543368223140addons.xpi
 DEBUG   Loaded add-on state: {"app-profile":{"addons":{"{73a6fe31-595d-
 
460b-a920-fcc0f8843232}":{"enabled":true,"lastModifiedTime":1543367768000,"path":"{73a6fe31
 -595d-
 
460b-a920-fcc0f8843232}.xpi","signedState":2,"version":"10.2.0","type":"webextension","bootstrapped":true,"dependencies":[],"runInSafeMode":false,"hasEmbeddedWebExtension":false
 },"https-everywhere-
 e...@eff.org":{"enabled":true,"lastModifiedTime":1543367678000,"path
 ":"https-everywhere-
 
e...@eff.org.xpi","signedState":2,"version":"2018.4.11","type":"webextension","bootstrapped":true,"dependencies":[],"runInSafeMode":false,"hasEmbeddedWebExtension":false},"torbut...@torproject.org":{"enabled":true,"lastModifiedTime":154336772,"path":"torbut...@torproject.org.xpi","version":"2.1.1"}},"path":"/data/user/0/org.torproject.torbrowser_alpha/files/mozilla/rb02if1q.default/extensions"}}
 11-28 01:23:43.142  8476  8496 I Gecko   : 1543368223142addons.xpi
 INFOMapping {73a6fe31-595d-460b-a920-fcc0f8843232} to
 
/data/user/0/org.torproject.torbrowser_alpha/files/mozilla/rb02if1q.default/extensions/{73a6fe31
 -595d-460b-a920-fcc0f8843232}.xpi
 11-28 01:23:43.143  8476  8496 I Gecko   : 1543368223143addons.xpi
 INFOMapping https-everywhere-...@eff.org to
 
/data/user/0/org.torproject.torbrowser_alpha/files/mozilla/rb02if1q.default/extensions
 /https-everywhere-...@eff.org.xpi
 11-28 01:23:43.143  8476  8496 I Gecko   : 1543368223143addons.xpi
 INFOMapping torbut...@torproject.org to
 
/data/user/0/org.torproject.torbrowser_alpha/files/mozilla/rb02if1q.default/extensions/torbut...@torproject.org.xpi
 11-28 01:23:43.144  8476  8496 I Gecko   : 1543368223144addons.xpi
 INFOMapping {73a6fe31-595d-460b-a920-fcc0f8843232} to
 

Re: [tor-bugs] #28592 [Core Tor/Tor]: Spurious coverity memory leak error in memoize_protover_summary()

[Tor Bug Tracker & Wiki]

#28592: Spurious coverity memory leak error in memoize_protover_summary()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor, nickm   |Sponsor:
--+
Changes (by teor):

 * reviewer:  teor => teor, nickm


Comment:

 I think that asserting `protover_summary_map == NULL` is ok.

 But I'd also like nickm's opinion: maybe there is a better way?

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

Re: [tor-bugs] #28611 [Core Tor/Tor]: Add `-mstack-protector-guard=global` to CFLAGS instead of `--disable-gcc-hardening` configure option on Windows?

[Tor Bug Tracker & Wiki]

#28611: Add `-mstack-protector-guard=global` to CFLAGS instead of 
`--disable-gcc-
hardening` configure option on Windows?
-+-
 Reporter:  grj  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 033-backport|  Actual Points:
  034-backport 035-backport win32|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 MSYS2 / mingw issue:
 https://github.com/Alexpux/MINGW-packages/issues/4266

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

Re: [tor-bugs] #28611 [Core Tor/Tor]: Add `-mstack-protector-guard=global` to CFLAGS instead of `--disable-gcc-hardening` configure option on Windows?

[Tor Bug Tracker & Wiki]

#28611: Add `-mstack-protector-guard=global` to CFLAGS instead of 
`--disable-gcc-
hardening` configure option on Windows?
-+-
 Reporter:  grj  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport 033-backport|  Actual Points:
  034-backport 035-backport win32|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 `-mstack-protector-guard=global -fstack-
 protector{,-all,-strong,-explicit}` is required on gcc 8.2 on some
 targets, to work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832

 The gcc issue should be fixed in the next gcc release.

 So let's combine this ticket and #27530.

 If --enable-expensive-hardening is set:
 * AC_TRY_RUN with tor's standard hardening flags
 * if that doesn't work, use `-mstack-protector-guard=global -fstack-
 protector{,-all,-strong,-explicit}`
 * if that doesn't work, disable hardening
 * if that doesn't work, fail configure

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

Re: [tor-bugs] #27530 [Core Tor/Tor]: Configure: Use AC_TRY_RUN() to check that --enable-gcc-hardening works

[Tor Bug Tracker & Wiki]

#27530: Configure: Use AC_TRY_RUN() to check that --enable-gcc-hardening works
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  fast-fix  |  Actual Points:
Parent ID:  #28611| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #28611


Comment:

 We will probably deal with this in #28611.

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

Re: [tor-bugs] #25601 [Obfuscation/Snowflake]: Multiplex - one snowflake proxy should be able to support multiple clients

[Tor Bug Tracker & Wiki]

#25601: Multiplex - one snowflake proxy should be able to support multiple 
clients
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by arma):

 Dcf points out that this ticket isn't as urgent as it might seem, (a)
 because the headless proxy-go can already handle multiple clients at once,
 and (b) because the vision is that we'll have way way more snowflakes than
 clients, so most snowflakes will be idle most of the time, so the chances
 of a collision (more than one client sent to the same snowflake) are low.

 I buy this logic in the short term, but it still seems to me that the
 broker design will get cleaner if the browser snowflakes can handle
 whichever clients try to use them, even if two show up together.

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

Re: [tor-bugs] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Seems fine to me: if the installed version works, let's use 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] #26360 [Core Tor/Tor]: Transport plugins deadlock if they write too much to stderr

[Tor Bug Tracker & Wiki]

#26360: Transport plugins deadlock if they write too much to stderr
---+--
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  pt, sponsor19  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 I posted a reproduction recipe for this bug at comment:16:ticket:28179.

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

Re: [tor-bugs] #28179 [Core Tor/Tor]: Handle output from PT processes with the event loop

[Tor Bug Tracker & Wiki]

#28179: Handle output from PT processes with the event loop
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:  dgoulet  |Sponsor:  Sponsor8
-+-

Comment (by dcf):

 This program may be useful for testing: attachment:bug28179-client.go

 It's a modified version of dummy-client from goptlib. The differences are
 that after PT initialization, it starts writing to stdout and stderr at 4
 KB/s. Also, in its core proxying loop, it tries to write a line to
 stdout/stderr every time it downloads a chunk of data. Eventually the
 stdout and stderr buffers fill up, and the proxy loop halts because it
 cannot write its line. The program copies everything it writes to
 stdout/stderr to a file called mirror.log, so you can see how much was
 written before it deadlocks.

 1. Download and put in a directory called bug28179-client.
 2. `go get` and `go build`.
 3. Put in torrc:\\
 {{{
 DataDirectory datadir
 UseBridges 1
 ClientTransportPlugin dummy exec bug28179-client
 Bridge dummy 128.31.0.61:443
 }}}
 4. `tor -f torrc SOCKSPort 1`
 5. In another terminal, `tail -F mirror.log`. You will see a mixture of
 `hello tor world` and `received XXX bytes` lines.
 6. For me, the system deadlocks after 8 seconds; apparently the
 stdout/stderr buffers are 64 KB.\\
{{{
 $ ls -l mirror.log
 -rw-r--r-- 1 david david 65425 Nov 27 14:09 mirror.log
}}}
If tor was in the middle of bootstrapping, it will stop here. If tor
 finished bootstrapping, you can verify that it stopped working with `curl
 -x socks5h://127.0.0.1:1/ https://example.com/`.

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

Re: [tor-bugs] #28543 [Applications/Tor Browser]: Tor Browser's about:tor has horizontal scroll bar between widths 900px and 1000px

[Tor Bug Tracker & Wiki]

#28543: Tor Browser's about:tor has horizontal scroll bar between widths 900px 
and
1000px
--+--
 Reporter:  pospeselr |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201811R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 I've never seen this behavior before to be honest. If that's not related
 to this ticket (even though without your patch I did not see it on my
 Windows 7 testing system), even better. :) So, I merged your branch to
 `master` (commit 9ae78d32be280bcf58819676f700994544049ae8), 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] #28179 [Core Tor/Tor]: Handle output from PT processes with the event loop

[Tor Bug Tracker & Wiki]

#28179: Handle output from PT processes with the event loop
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:  dgoulet  |Sponsor:  Sponsor8
-+-
Changes (by dcf):

 * Attachment "bug28179-client.go" added.

 Client PT program that demonstrates a deadlock when writing too much to
 stdout/stderr.

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

Re: [tor-bugs] #28494 [Core Tor/Stem]: Please provide an equivalent for UnparseableDescriptor from metrics-lib

[Tor Bug Tracker & Wiki]

#28494: Please provide an equivalent for UnparseableDescriptor from metrics-lib
---+
 Reporter:  irl|  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Great! Glad to hear you're not using the DescriptorReader.

 If you're using parse_file() then I'm unsure if there's anything to do
 with this. If you include 'validate = True' invalid content will raise
 ValueErrors, and if not it should pretty much always return a Descriptor
 object. TypeErrors only arise when unable to determine the descriptor type
 (which is caller error).

 Am I missing anything or can this be closed?

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

Re: [tor-bugs] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
+
 Reporter:  Vort|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.5.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  windows nt-service  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by Vort):

 Tried to insert some code at `cpuworker.c:501` to catch the bug -> no
 result. Reverted my changes -> no assertion anymore.
 But here is what says gdb now. Maybe it is more related than `cpuworker.c`
 problem:
 {{{
 Attaching to process 17568
 [New Thread 17568.0x7884]
 [New Thread 17568.0x7518]
 [New Thread 17568.0x8b90]
 [New Thread 17568.0xccb0]
 [New Thread 17568.0x8b4c]
 [New Thread 17568.0xd754]
 Reading symbols from D:\Tor\tor.exe...done.
 Continuing.
 [Thread 17568.0xd754 exited with code 0]

 Thread 4 received signal SIGFPE, Arithmetic exception.
 [Switching to Thread 17568.0xccb0]
 0x00527af1 in token_bucket_raw_refill_steps (elapsed=54536462,
 cfg=0x658800 , bucket=0x658808 )
 at src/lib/evloop/token_bucket.c:90
 90if (elapsed > gap / cfg->rate) {
 (gdb) bt
 #0  0x00527af1 in token_bucket_raw_refill_steps (elapsed=54536462,
 cfg=0x658800 , bucket=0x658808 )
 at src/lib/evloop/token_bucket.c:90
 #1  token_bucket_rw_refill (bucket=0x658800 ,
 now_ts=now_ts@entry=872583402) at src/lib/evloop/token_bucket.c:206
 #2  0x0040650f in connection_bucket_refill_single (conn=0x1552f60,
 now_ts=872583402) at src/core/mainloop/connection.c:3436
 #3  0x0040df78 in connection_handle_read_impl (conn=0x1552f60)
 at src/core/mainloop/connection.c:3539
 #4  connection_handle_read (conn=conn@entry=0x1552f60)
 at src/core/mainloop/connection.c:3647
 #5  0x00413b10 in conn_read_callback (fd=,
 event=, _conn=0x1552f60)
 at src/core/mainloop/mainloop.c:870
 #6  0x621d4999 in ?? () from D:\Tor\libevent-2-1-6.dll
 #7  0x621d5504 in ?? () from D:\Tor\libevent-2-1-6.dll
 #8  0x0041496f in run_main_loop_once ()
 at src/core/mainloop/mainloop.c:2926
 #9  run_main_loop_until_done () at src/core/mainloop/mainloop.c:2988
 #10 do_main_loop () at src/core/mainloop/mainloop.c:2883
 #11 0x004f4886 in nt_service_body (argc=,
 argv=) at src/app/main/ntmain.c:301
 #12 0x07fefdb1a82d in SECHOST!RegisterServiceCtrlHandlerExA ()
from C:\Windows\SYSTEM32\sechost.dll
 #13 0x778759cd in KERNEL32!BaseThreadInitThunk ()
from C:\Windows\system32\kernel32.dll
 #14 0x779d385d in ntdll!RtlUserThreadStart ()
from C:\Windows\SYSTEM32\ntdll.dll
 #15 0x in ?? ()
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 (gdb)
 }}}

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+--
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a2  |  Actual Points:
Parent ID:  #28051   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * Attachment "mockups-1.1.2.png" added.


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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+--
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a2  |  Actual Points:
Parent ID:  #28051   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * Attachment "userflow-1.1.png" added.


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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+--
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a2  |  Actual Points:
Parent ID:  #28051   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by antonela):

 By aiming for the most minimal orbot integration for this release, I:
 - updated the userflow. We are not interacting with Bridges/PT yet.

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28329/userflow-1.1.png, 700px)]]

 - made an approach for the `Connecting...` screen
 - suggested a layout for Tor Network Settings

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28329/mockups-1.1.png, 700px)]]

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+--
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a2  |  Actual Points:
Parent ID:  #28051   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * Attachment "mockups-1.1.png" added.


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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+--
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a2  |  Actual Points:
Parent ID:  #28051   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * Attachment "userflow-1.1.png" added.


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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+--
 Reporter:  sysrqb   |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a2  |  Actual Points:
Parent ID:  #28051   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * Attachment "userflow-1.1.png" added.


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

Re: [tor-bugs] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
+
 Reporter:  Vort|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.5.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  windows nt-service  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by Vort):

 With latest version (9c2b114b), it says more even at notice level:
 `Nov 27 22:05:10.000 [err] tor_assertion_failed_(): Bug: cpuworker.c:501:
 cpuworker_queue_work: Assertion threadpool failed; aborting. (on Tor
 0.4.0.0-alpha-dev )`
 `Nov 27 22:05:10.000 [err] Bug: Assertion threadpool failed in
 cpuworker_queue_work at cpuworker.c:501. (Stack trace not available) (on
 Tor 0.4.0.0-alpha-dev )`

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

Re: [tor-bugs] #28588 [Core Tor/sbws]: SBWS 'bw_torflow_scale' does not appear to honor relay MaxAdvertisedBandwidth

[Tor Bug Tracker & Wiki]

#28588: SBWS 'bw_torflow_scale' does not appear to honor relay
MaxAdvertisedBandwidth
---+-
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:  sbws: 1.0.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by nickm):

 Hi! I offered to take a look at the branch at Monday's meeting.  I've had
 a look over the python and I don't see anything objectionable there.

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

Re: [tor-bugs] #27947 [Core Tor/Chutney]: Chutney's owning controller process code compares strings with ints

[Tor Bug Tracker & Wiki]

#27947: Chutney's owning controller process code compares strings with ints
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * component:  Core Tor/Tor => Core Tor/Chutney


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

Re: [tor-bugs] #28522 [Core Tor/Tor]: [armhf] (Sandbox) Caught a bad syscall attempt

[Tor Bug Tracker & Wiki]

#28522: [armhf] (Sandbox) Caught a bad syscall attempt
-+-
 Reporter:  bundesgebaermutter   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.9
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
  sandbox,armhf,syscall,debian,stretch,  |
  035-backport 034-backport 033-backport |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  sandbox,armhf,syscall,debian,stretch =>
 sandbox,armhf,syscall,debian,stretch, 035-backport 034-backport
 033-backport 029-backport
 * milestone:   => Tor: 0.4.0.x-final


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

Re: [tor-bugs] #28525 [Core Tor/Tor]: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 Ranges

[Tor Bug Tracker & Wiki]

#28525: Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large
Scale NAT) IPv4 Ranges
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.4.0.x-final


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

Re: [tor-bugs] #28612 [Core Tor/Tor]: Tor start via Windows service fails

[Tor Bug Tracker & Wiki]

#28612: Tor start via Windows service fails
+
 Reporter:  Vort|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.5.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  windows nt-service  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * milestone:   => Tor: 0.4.0.x-final


Comment:

 Does it say any more if you log at "debug"?

 Is there any way you can get a stack trace of the crash, if it crashes?

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

Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

[Tor Bug Tracker & Wiki]

#28181: spec: Add to pt-spec.txt control messages going back to main process 
(tor)
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 040-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by dgoulet):

 I've pushed a fixup commit to mean either client or server.

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

Re: [tor-bugs] #28179 [Core Tor/Tor]: Handle output from PT processes with the event loop

[Tor Bug Tracker & Wiki]

#28179: Handle output from PT processes with the event loop
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:  dgoulet  |Sponsor:  Sponsor8
-+-

Comment (by dcf):

 Cross-referencing #9957, an older ticket about reading and logging PTs'
 stderr.

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

Re: [tor-bugs] #9957 [Core Tor/Tor]: Tor should consider stderr output of transport proxies

[Tor Bug Tracker & Wiki]

#9957: Tor should consider stderr output of transport proxies
-+-
 Reporter:  wfn  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, SponsorS-deferred, tor-  |  Actual Points:
  bridge |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 It looks like #28179 will take care of this. The current implementation in
 comment:11:ticket:28179 (https://github.com/torproject/tor/pull/537) logs
 anything that a PT process writes to stderr, in addition to logging
 special LOG messages on stdout.

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

Re: [tor-bugs] #28224 [Core Tor/sbws]: Monitor dirauth running sbws in production

[Tor Bug Tracker & Wiki]

#28224: Monitor dirauth running sbws in production
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #27107 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by juga):

 After several days, most of the circuits timeout. Opened #28639 for this.

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

[tor-bugs] #28639 [Core Tor/sbws]: After several days, most of the circuits timeout

[Tor Bug Tracker & Wiki]

#28639: After several days, most of the circuits timeout
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #25925
   Points: |   Reviewer:
  Sponsor: |
---+-
 When the scanner is restarted, circuits most of the circuits doesn't
 timeout.
 The destination is reachable.

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

Re: [tor-bugs] #28179 [Core Tor/Tor]: Handle output from PT processes with the event loop

[Tor Bug Tracker & Wiki]

#28179: Handle output from PT processes with the event loop
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:  dgoulet  |Sponsor:  Sponsor8
-+-

Comment (by dcf):

 https://github.com/torproject/tor/pull/537/files#diff-
 08bd8435ecfd8690789652091567ff47R1151
 {{{
   /* The format is 'LOG  '. We accept empty messages.
 */
 }}}
 It looks like this comment is out of date; I thought the ``
 part was removed. Also "We accept empty messages" seems to contradict the
 "Managed proxy sent us a LOG line with missing arguments" check above: I
 suppose that `LOG ` (with a space) is acceptable but `LOG` is not, not
 sure if that's what's intended.

 https://github.com/torproject/tor/pull/537/files#diff-
 6fdba7a022e591369dcf7054e5f2700aR7396
 {{{
 /** A pluggable transport called transport_name has emitted a log
  * message found in message. */
 void
 control_event_transport_log(const char *transport_name, const char
 *message)
 {
   send_control_event(EVENT_TRANSPORT_LOG,
  "650 TRANSPORT_LOG %s %s\r\n",
  transport_name,
  message);
 }
 }}}
 Where does `` come from? Is it the path the executable? In
 general, tor won't know a specific transport name corresponding to any LOG
 message. I don't see where `control_event_transport_log` is called other
 than in tests.

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

Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

[Tor Bug Tracker & Wiki]

#28181: spec: Add to pt-spec.txt control messages going back to main process 
(tor)
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 040-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by dcf):

 Replying to [comment:13 dgoulet]:
 > After implementation done in #28179, here is the updated branch:
 >
 > Branch: `ticket28181_02`

 
https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket28181_02=cf2c60e223391c2e6360c24612638b63fd1951e0

 "This message is for a ''client'' PT..." Instead of "client PT" you should
 use the term "PT Proxy". A PT Proxy may be running in either client mode
 or server mode, and I believe that LOG is meant to be used by both.

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

Re: [tor-bugs] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by akwizgran):

 If I'm reading the spec right, there are `hsdir_n_replicas = 2` replicas.
 For each replica, the HS uploads the descriptor to `hsdir_spread_store =
 4` HSDirs at consecutive positions in the hashring. Each client tries to
 fetch the descriptor from one of the first `hsdir_spread_fetch = 3`
 positions, chosen at random.

 A lookup fails when the position chosen by the client is occupied by an
 HSDir that didn't receive the descriptor, for both replicas. So failure is
 possible when ''any'' of the first 3 positions is occupied by an HSDir
 that didn't receive the descriptor, for both replicas. Churn can bring
 this about in two ways: by removing the HSDirs that received the
 descriptor, and by adding new HSDirs that push the HSDirs that received
 the descriptor out of the first 3 positions.

 How long do we expect it to take before churn makes a lookup failure
 possible? We could measure this with historical consensus data, but let's
 try a quick simulation first.

 Figure 9 of
 
[https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_winter.pdf
 this paper] shows the fraction of relays with the HSDir flag that join or
 leave between consecutive consensuses. I'd estimate 0.01 by eye, so let's
 conservatively call it 0.02. The churn rate counts both joins and leaves,
 so a churn rate of 0.02 means each HSDir from the previous consensus has
 left with probability 0.01, and new HSDirs have joined at the same rate.

 There are
 
[https://metrics.torproject.org/relayflags.html?start=2018-08-29=2018-11-27=HSDir
 about 3,000] relays with the HSDir flag.

 My code (attached) simulates each replica by creating 3,000 HSDirs, each
 at a random position on the hashring, and remembering the first 4 HSDirs
 on the hashring - these are the ones that receive copies of the
 descriptor. Churn is simulated an hour at a time. In each hour, each HSDir
 is removed with probability 0.01 and replaced with a new HSDir at a random
 position. Then the code checks whether the first 3 HSDirs on the hashring
 are all ones that received copies of the descriptor. If not, a lookup on
 this replica could fail.

 For simplicity I've simulated the two replicas independently - in reality
 they'd be based on different permutations of the same HSDirs, but
 independence seems like a reasonable approximation. The simulation runs
 until lookups on both replicas could fail.

 The mean time until both replicas could fail is 37 hours, averaged over
 10,000 runs.

 If this is roughly accurate then we should be able to keep the HS
 reachable by waking Tor from its dormant state every few hours to fetch a
 fresh consensus and upload new copies of the descriptor if necessary.

 Perhaps I should extend the simulation to consider the probability of
 lookup failure as a function of time, rather than the mean time until
 failure becomes possible.

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

Re: [tor-bugs] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by akwizgran):

 * Attachment "ChurnSim.java" 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] #28179 [Core Tor/Tor]: Handle output from PT processes with the event loop

[Tor Bug Tracker & Wiki]

#28179: Handle output from PT processes with the event loop
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:  dgoulet  |Sponsor:  Sponsor8
-+-
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Added fixup commits.

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

Re: [tor-bugs] #28211 [Applications/Tor Browser]: Torbrowser 8.0.3 Hangs, and torbutton does not show the current circuit

[Tor Bug Tracker & Wiki]

#28211: Torbrowser 8.0.3 Hangs, and torbutton does not show the current circuit
--+--
 Reporter:  justmeee  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by justmeee):

 * status:  needs_information => new


Comment:

 First, with those files triggered by the virus program, should I let it
 delete them, or restore and "trust" them?

 It might be worth looking into why that was triggered because that never
 happened before for your next builds.

 As for the install issue, even the torbrowser alpha file from the link you
 gave me that did successfully install never gave any sort of confirmation,
 the dialog box just disappeared.  So that seems like a bug too, not
 knowing if it installed, if it's done, was it successful.. It just
 disappears, no confirmation at all.  That was why I tried installing it
 twice in two different locations in the first place hence the double popup
 from virus protection on one of the files.

 I did try installing that firefox, it would not install.  I did not get
 any error messages either.  After I clicked on the exe, I get the open
 file dialog box and clicked run, which I got on those other torbrowser
 files with the error messages as well.  Then it extracted, which I think
 also happened on those other files but not too sure.  Them nothing.  The
 only difference is on the torbrowser I would see the popup at this point
 about it needing Windows 7 installed, but on the Firefox it just doesn't
 do anything at all after that, the boxes just disappear and nothing is
 installed.  I put 'firefox' in the windows search box to see if it did
 install and just didn't give me any confirmation dialogs like the
 torbrowser I mentioned before, but nothing shows up on the computer except
 the one that came with torbrowser, so firefox did not install either.

 The other question and/or item to look into, is there a way to confirm if
 you're in private browsing mode while browsing?

 Thank you very much.

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

Re: [tor-bugs] #27977 [Applications/Tor Browser]: Build Orbot with rbm/tor-browser-build

[Tor Bug Tracker & Wiki]

#27977: Build Orbot with rbm/tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 Replying to [comment:52 gk]:
 > Comparing the Gradle downloads with the things we ship in our dependency
 list gives interesting results. I followed the advice in the how-to and
 ran
 > `cat logs/firefox-android-armv7.log | grep "Download http" | sed
 "s/^.*Download //g" > download-urls.txt` which produced a `download-
 urls.txt`. It contains 365 entries which mates the 368 - 3 (header)
 entries in `gradle-dependencies-list.txt`. However, checking whether those
 entries in the former are actually in the latter (by running `grep -Ff
 dowload-urls.txt projects/firefox/gradle-dependencies-list.txt` | wc` does
 only return 363 entries. After some more cutting and sorting the diff
 (`diff download-urls_sorted.txt cuttted_sorted`) I got is:
 > {{{
 > < https://jcenter.bintray.com/com/jayway/android/robotium/robotium-
 solo/5.5.4/robotium-solo-5.5.4.jarNote: Some input files use or override a
 deprecated API.
 > ---
 > > https://jcenter.bintray.com/com/jayway/android/robotium/robotium-
 solo/5.5.4/robotium-solo-5.5.4.jar
 > 294c294
 > <
 
https://maven.google.com/com/android/support/appcompat-v7/23.4.0/appcompat-v7-23.4.0.aar/var/tmp/build
 /firefox-
 
9f40b0882072/mobile/android/thirdparty/ch/boye/httpclientandroidlib/conn/HttpHostConnectException.java:56:
 warning: non-varargs call of varargs method with inexact argument type for
 last parameter;
 > ---
 > >
 
https://maven.google.com/com/android/support/appcompat-v7/23.4.0/appcompat-v7-23.4.0.aar
 > }}}
 > I wonder what a fix for out how-to would be here? Making sure only the
 parts up to and including either ".pom", ".jar" or ".aar" would get
 included in `download-urls.txt`?

 In this case, we will need to manually cut off the extra junk at the end
 of the URL. We can do this through manual inspection. If we don't clean
 this up, the build will fail during artifact download. I'll document this.

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

Re: [tor-bugs] #27977 [Applications/Tor Browser]: Build Orbot with rbm/tor-browser-build

[Tor Bug Tracker & Wiki]

#27977: Build Orbot with rbm/tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 Replying to [comment:51 gk]:


 > Replying to [comment:50 sisbell]:
 >
 > > Changes (android-1126)
 > >
 > > * Added latest patches for Orbot
 > > * Updated gradle-dependencies list
 > >
 > > I verified that this configuration has 189 Downloads in the (original)
 log files and 189 artifacts in the gradle-dependencies-list
 > >
 > > For testing firefox config:
 > >
 > > {{{
 > > git_hash: 28051_5
 > > git_url: https://git.torproject.org/user/sysrqb/tor-browser.git
 > > }}}
 > >
 >
 > Okay, some more comments. I think it's less cluttering to just use a
 squashed patch for all of the Orbot changes. However, it might be worth
 keeping the patches as-is to modify some of them, but not others, later on
 if needed. So, feel free to go with the approach you took (including the
 updated patches for #28015 once they are ready).
 > {{{
 > +cp -r $gradle_repo/guardianproject/gpmaven/master/* $gradle_repo
 > +cp -r $gradle_repo/dl/android/maven2/* $gradle_repo
 > }}}
 > Why do we need to copy around things here? If it is really necessary
 could you add a comment explaining the reasoning behind it?

 I'll add a comment, but the base reasoning here is that the download
 script assumes that the everything in the artifact URL path is part of the
 package name but this isn't always the case. In those cases, we need to do
 a copy of artifacts.

 > {{{
 > +mv libs/armeabi/pdnsd libs/armeabi/pdnsd.so
 > +mv libs/armeabi-v7a/pdnsd libs/armeabi-v7a/pdnsd.so
 > +mv libs/x86/pdnsd libs/x86/pdnsd.so
 > }}}
 > Do we need all three of them even though we only build for aremabi-v7a?
 >
 You are right, we only need armv7 libraries. I'll make this change.

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

Re: [tor-bugs] #28634 [Core Tor/Tor]: Design a useful padding machine that we can enable

[Tor Bug Tracker & Wiki]

#28634: Design a useful padding machine that we can enable
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28632   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 IMO it doesn't need to be a useful padding machine if we can't get a
 useful one done in time.  If the best we can do is "cheap and harmless"
 instead of "useful", that would still give us a testbed.

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

Re: [tor-bugs] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.4.0.x-final => Tor: 0.3.4.x-final


Comment:

 Okay, lgtm. Merged to 0.3.4 and forward.

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

Re: [tor-bugs] #28353 [Metrics/Website]: Use Guard & Exit, Guard only, Exit only, and Middle only on all bandwidth by flag graphs

[Tor Bug Tracker & Wiki]

#28353: Use Guard & Exit, Guard only, Exit only, and Middle only on all 
bandwidth
by flag graphs
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28328   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by antonela):

 Hi! The contrast between the pink and the red colors are not strong
 enough. I would suggest having a shade of green (aroundish #12bc00).

 I think that would be useful for you to have a suggestion on how to render
 this kind of graphs. I filed #28629 to have a Graphs section at the
 styleguide.

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

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * points:   => 2
 * milestone:   => Tor: 0.4.0.x-final


Comment:

 Thanks for opening this: I've been thinking about it since I saw this
 email:

 https://lists.torproject.org/pipermail/tor-dev/2018-November/013561.html

 I've been thinking of the following interface:

 {{{
DormantOnStart 1|0|auto

If DormantOnStart is set to 1, then Tor starts up in dormant mode.

If DormantOnStart is 0 (the default), then Tor starts up in active
(non-dormant) mode.

If DormantOnStart is "auto", then Tor starts up in dormant mode UNLESS
it was active when it last saved its state file, AND it saved its state
file no more than DormantClientTimeout seconds ago.
 }}}

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

Re: [tor-bugs] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

#28142: Merge original WTF-PAD branch
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 OK, the current state of things can be found here:
 https://github.com/torproject/tor/pull/547

 It's basically the `PR#461` branch, rebased to latest master, plus
 Riastradh's probability distribution work, plus the other tests I wrote.

 Here are the remaining tasks that we should address to close this:

 - Continue hammering at the unittests to increase coverage and confidence.
 My next targets are:
 {{{
   - Test histogram spacing for larger length histograms
   - Test all types of token removal
 }}}

 - Go through the remaining GH review comments.

 - Disable the current machine so that we don't merge it as on-by-default.

 After this we can give it back to Nick for another round of 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] #28636 [Core Tor/Tor]: Address comments by Nick (2018-11-27 over IRC)

[Tor Bug Tracker & Wiki]

#28636: Address comments by Nick (2018-11-27 over IRC)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28632   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by asn:

Old description:

> Nick expressed the following concerns/comments about the branch:
>
> - We should be careful about using `monotime_*` functions in the branch
> because of performance issues:
> {{{
> 15:19 <+nickm> ... it is too slow for a fast path.
> 15:19 <+nickm> and lots of the ways to use it can be too slow for a fast
> path
> 15:21 <+nickm> hrm.  So there are two things that can make it slow.
> 15:22 <+nickm> there are two things that can make this function slow
> 15:22 <+nickm> first, it tries to get the most precise monotonic time,
> not the fastest one
> 15:22 <+nickm> so it might have to go to the kernel and do a context
> switch and take some time there
> 15:22 <+nickm> the "coarse" variants of monotime_* don't have that
> problem.
> 15:23 <+nickm> The second issue is that using the "usec" variant requires
> 64-bit division on some platforms, which is noticeably expensive on
> 32-bit hardware.
> }}}
>
> - Figure out how dormant mode interacts with the padding code.
> {{{
> 15:27 <+nickm> okay.  short version is that tor can enter a "dormant"
> state when it is inactive for a really long time, or when the controller
> tells it to do so.
> 15:28 <+nickm> we should probably figure out whether being dormant
> prevents you from sendig padding and vice versa...
> 15:28 <+nickm> ... and whether it should prevent you from sending padding
> (and vice versa)...
> }}}
>
> - Do type checking when downcasting the vcarious probability
> distributions.
>
> - `<+nickm> Also there are all these generic dist_ops functions that you
> could use ... but the API seems to encourage you not to use them.  having
> wrapper functions instead that call dist->dist_ops.func(dist, ...) would
> be neat`

New description:

 Nick expressed the following concerns/comments about the branch:

 - We should be careful about using `monotime_*` functions in the branch
 because of performance issues:
 {{{
 15:19 <+nickm> ... it is too slow for a fast path.
 15:19 <+nickm> and lots of the ways to use it can be too slow for a fast
 path
 15:21 <+nickm> hrm.  So there are two things that can make it slow.
 15:22 <+nickm> there are two things that can make this function slow
 15:22 <+nickm> first, it tries to get the most precise monotonic time, not
 the fastest one
 15:22 <+nickm> so it might have to go to the kernel and do a context
 switch and take some time there
 15:22 <+nickm> the "coarse" variants of monotime_* don't have that
 problem.
 15:23 <+nickm> The second issue is that using the "usec" variant requires
 64-bit division on some platforms, which is noticeably expensive on 32-bit
 hardware.
 }}}

 - Figure out how dormant mode interacts with the padding code.
 {{{
 15:27 <+nickm> okay.  short version is that tor can enter a "dormant"
 state when it is inactive for a really long time, or when the controller
 tells it to do so.
 15:28 <+nickm> we should probably figure out whether being dormant
 prevents you from sendig padding and vice versa...
 15:28 <+nickm> ... and whether it should prevent you from sending padding
 (and vice versa)...
 }}}

 - Do type checking when downcasting the vcarious probability
 distributions.

 - `<+nickm> Also there are all these generic dist_ops functions that you
 could use ... but the API seems to encourage you not to use them.  having
 wrapper functions instead that call dist->dist_ops.func(dist, ...) would
 be neat`

 - `<+nickm> oh, one list thing: I think src/lib/math is not allowed to
 include lib/crypt_ops, since that would introduce a circularity.  Better
 make sure that it doesn't`

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28638 [Core Tor/Tor]: Serialize state machines in the torrc and consensus

[Tor Bug Tracker & Wiki]

#28638: Serialize state machines in the torrc and consensus
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Figure out how to serialize state machines in the torrc and consensus to
 make it easire to specify state machines for researchers (and for common
 users).

 Perhaps it's fine to do this after 0.4.0 since the WTF-PAD code in 0.4.0
 is mainly for research purposes and not inteded to be used by a wide
 audience. The researchers can perhaps write code of their own that
 instantiates the padding machines if we write a good enough doc to do so.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28637 [Core Tor/Tor]: Improve general WTF-PAD code quality and maintainability

[Tor Bug Tracker & Wiki]

#28637: Improve general WTF-PAD code quality and maintainability
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28631
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This is a master ticket for tasks that can be done after WTF-PAD gets
 merged, and maybe even after 0.4.0 gets released. They represent tasks
 that increase code quality and reduce tech debt.

 Example:

 - Improve the probability distribution API. Instead of using nameless dist
 params, instead have the caller instantiate a struct with the right params
 for each distribution.

 - The above will also allow callers to specify a genpareto distribution
 with configurable `mu` parameter.

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

Re: [tor-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Also, note to self, seeing this in the logs. Maybe related to #28507, but
 should investigate.

 {{{
 11-27 14:47:48.676 20747 20768 I Gecko   : *
 11-27 14:47:48.676 20747 20768 I Gecko   : A coding exception was thrown
 and uncaught in a Task.
 11-27 14:47:48.676 20747 20768 I Gecko   :
 11-27 14:47:48.676 20747 20768 I Gecko   : Full message: TypeError:
 Cc['@mozilla.org/push/Service;1'] is undefined
 11-27 14:47:48.676 20747 20768 I Gecko   : Full stack:
 
Sanitizer.prototype.items.siteSettings.clearhttps://trac.torproject.org/projects/tor/ticket/28051#comment:39>
Tor Bug Tracker & Wiki 
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] #28636 [Core Tor/Tor]: Address comments by Nick (2018-11-27 over IRC)

[Tor Bug Tracker & Wiki]

#28636: Address comments by Nick (2018-11-27 over IRC)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Nick expressed the following concerns/comments about the branch:

 - We should be careful about using `monotime_*` functions in the branch
 because of performance issues:
 {{{
 15:19 <+nickm> ... it is too slow for a fast path.
 15:19 <+nickm> and lots of the ways to use it can be too slow for a fast
 path
 15:21 <+nickm> hrm.  So there are two things that can make it slow.
 15:22 <+nickm> there are two things that can make this function slow
 15:22 <+nickm> first, it tries to get the most precise monotonic time, not
 the fastest one
 15:22 <+nickm> so it might have to go to the kernel and do a context
 switch and take some time there
 15:22 <+nickm> the "coarse" variants of monotime_* don't have that
 problem.
 15:23 <+nickm> The second issue is that using the "usec" variant requires
 64-bit division on some platforms, which is noticeably expensive on 32-bit
 hardware.
 }}}

 - Figure out how dormant mode interacts with the padding code.
 {{{
 15:27 <+nickm> okay.  short version is that tor can enter a "dormant"
 state when it is inactive for a really long time, or when the controller
 tells it to do so.
 15:28 <+nickm> we should probably figure out whether being dormant
 prevents you from sendig padding and vice versa...
 15:28 <+nickm> ... and whether it should prevent you from sending padding
 (and vice versa)...
 }}}

 - Do type checking when downcasting the vcarious probability
 distributions.

 - `<+nickm> Also there are all these generic dist_ops functions that you
 could use ... but the API seems to encourage you not to use them.  having
 wrapper functions instead that call dist->dist_ops.func(dist, ...) would
 be neat`

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

Re: [tor-bugs] #28631 [Core Tor/Tor]: Release a useful WTF-PAD to the world (master ticket)

[Tor Bug Tracker & Wiki]

#28631: Release a useful WTF-PAD to the world (master ticket)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

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


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

Re: [tor-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:36 gk]:
 > Okay, I gave the whole thing some testing and it works, nice! The two
 main points I have so far:
 >
 > 1) I start the app and it says it's Tor Browser but I still need to
 start that Orbot thing which might confuse users ("Hey, I want to run Tor
 Browser and I already started it!1! What do I need to do now with that
 Orbot piece?). But I think that's okay for the alpha.
 >
 > 2) More worriesome, though: I start Orbot and after it has bootstrapped
 nothing happens. It's essentially sitting there and no browser window pops
 up. In fact, it's not even clear how one could manually open one. I
 pressed by accident the button I usually press if I want to go back a
 website in my history and suddenly the window is open an I can use Tor
 Browser. Pressing that "going back one website"-button "works" as well if
 one has not started the Orbot part yet. The huge downside to that scenario
 is that it's not obvious how to go back to start Orbot now and the user is
 just receiving proxy connection errors (so far I needed to get rid of the
 current Tor Browser instance and start over to work around that).

 Indeed, I agree with these concerns. They should be taken care of in
 #28329

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

Re: [tor-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by sysrqb):

 * status:  needs_revision => needs_review


Comment:

 Okay. I have two new branches, one for tor-browser and another for orbot.

 The orbot branch (`28051_orbot_4`) includes the changes in comment:31. It
 also includes a new proguard rule for keeping
 `org.torproject.android.settings.Languages.setup(Class,int)` that it was
 stipping due to it not being used. Unfortunately, this method is called by
 the Application when the app starts, so I added it in GeckoApplication in
 Fennec.

 I have mixed feelings about adding this, because on the one hand this is
 needed for opening Orbot's Settings menu - otherwise Orbot crashes and
 we're left with Tor Browser without Tor. However, on the other hand, we'll
 likely never use Orbot's settings menu. But, we're already renaming the
 preferences layout xml so it doesn't conflict with Fennec, so if we do
 that then I think it makes sense that we prevent this crash.

 The new tor-browser branch adds the necessary initialization calls -
 `28051_6`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28635 [Core Tor/Tor]: Clean up PADDING_TODO.txt

[Tor Bug Tracker & Wiki]

#28635: Clean up PADDING_TODO.txt
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 PADDING_TODO.txt contains various tasks that should be done. We should
 figure out which ones should be done before 0.4.0 gets released and which
 ones are good-to-have features/fixes for later.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28634 [Core Tor/Tor]: Design a useful padding machine that we can enable

[Tor Bug Tracker & Wiki]

#28634: Design a useful padding machine that we can enable
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 #28142 will get merged with no active padding machine. This ticket is
 about designing a useful padding machine that can act as a decent testbed
 for the WTF-PAD project.

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

[tor-bugs] #28633 [Core Tor/Tor]: Pad on specific circuit purposes + ltups

[Tor Bug Tracker & Wiki]

#28633: Pad on specific circuit purposes + ltups
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28632
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We want to add another criterion to the circuit padding machines so that
 they don't just pad blindly any circuit, and instead they only pad
 circuits with specific purposes and ltups (?).

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

Re: [tor-bugs] #26634 [Core Tor/Tor]: Enumerate unresolved issues that will need to be solved for a WTF-pad deployment

[Tor Bug Tracker & Wiki]

#26634: Enumerate unresolved issues that will need to be solved for a WTF-pad
deployment
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

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


Comment:

 Closing this as DONE since we have investigated open issues and opened
 #28632 to track them

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

Re: [tor-bugs] #26633 [Core Tor/Tor]: Solve histogram issues for WTF-Pad

[Tor Bug Tracker & Wiki]

#26633: Solve histogram issues for WTF-Pad
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #28632   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * parent:   => #28632


Comment:

 Is there anything else to do here?

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

[tor-bugs] #28632 [Core Tor/Tor]: Make the original WTF-PAD branch actually useful for us (submaster ticket)

[Tor Bug Tracker & Wiki]

#28632: Make the original WTF-PAD branch actually useful for us (submaster 
ticket)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:  #28631
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In ticket #28142 we are implementing the basic WTF-PAD system, but with no
 actual machine running, and with a few features missing.

 This ticket will track the remaining work to make #28142 actually useful.

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

Re: [tor-bugs] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

#28142: Merge original WTF-PAD branch
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * parent:   => #28631


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28631 [Core Tor/Tor]: Release a useful WTF-PAD to the world (master ticket)

[Tor Bug Tracker & Wiki]

#28631: Release a useful WTF-PAD to the world (master ticket)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  wtf-pad, tor-relay, tor-cell,
 Severity:  Normal   |  padding
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 This is a master ticket tracking WTF-PAD work.

 The plan is to start by merging #28142 early in the 0.4 timeframe, and
 then start building on top of it useful stuff.

 Subtickets of this ticket should track this work.

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

Re: [tor-bugs] #26690 [Applications/Tor Browser]: TBA: Port padlock states for .onion services to mobile

[Tor Bug Tracker & Wiki]

#26690: TBA: Port padlock states for .onion services to mobile
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #5709| Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by antonela):

 * Attachment "assets.zip" added.

 TBA Alpha - Onion padlock assets

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

Re: [tor-bugs] #26690 [Applications/Tor Browser]: TBA: Port padlock states for .onion services to mobile

[Tor Bug Tracker & Wiki]

#26690: TBA: Port padlock states for .onion services to mobile
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #5709| Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by antonela):

 The original assets have a white space around the icon, this is why it
 looks smaller.
 Already provided assets with that white space to igt0 for implementation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28630 [Core Tor/Tor]: Resolve TROVE-2018-006

[Tor Bug Tracker & Wiki]

#28630: Resolve TROVE-2018-006
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #28616 [Core Tor/Tor]: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)

[Tor Bug Tracker & Wiki]

#28616: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.4.0.x-final


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

Re: [tor-bugs] #28613 [Core Tor/Tor]: Log is filled with OpenSSL errors

[Tor Bug Tracker & Wiki]

#28613: Log is filled with OpenSSL errors
--+
 Reporter:  Vort  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.5-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:  ssl 035-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Closing as a duplicate of #28616, which has a diagnosis for the issue.  It
 appears to be a regression in openssl 1.1.1a.

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

Re: [tor-bugs] #28616 [Core Tor/Tor]: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)

[Tor Bug Tracker & Wiki]

#28616: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)
--+--
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Found it!  This is an issue with this change in openssl 1.1a from commit
 ec0c5f5693e39c5:
 {{{
 +/*
 + * RFC 8446, 7.1 Key Schedule, says:
 + * Note: With common hash functions, any label longer than 12 characters
 + * requires an additional iteration of the hash function to compute.
 + * The labels in this specification have all been chosen to fit within
 + * this limit.
 + */
 +#define TLS13_MAX_LABEL_LEN 12
 }}}

 I've opened an OpenSSL issue at
 https://github.com/openssl/openssl/issues/7712 .  This does not seem like
 something we can work around ourselves.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28629 [Webpages/Styleguide]: Add Graphs section to the Styleguide

[Tor Bug Tracker & Wiki]

#28629: Add Graphs section to the Styleguide
-+--
 Reporter:  antonela |  Owner:  hiro
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Normal   |   Keywords:  ux-team
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 We want to have a trusted source for styling (colors and fonts) for teams
 who need to have data visualization.

 Metrics is using this library https://ggplot2.tidyverse.org/.

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

Re: [tor-bugs] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Looks like the bots are green. Requesting another review here.

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

Re: [tor-bugs] #28180 [Core Tor/Tor]: Signal mechanism from PT processes to Tor

[Tor Bug Tracker & Wiki]

#28180: Signal mechanism from PT processes to Tor
-+-
 Reporter:  ahf  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-
Changes (by dgoulet):

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


Comment:

 This is implemented in #28179.

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

Re: [tor-bugs] #28543 [Applications/Tor Browser]: Tor Browser's about:tor has horizontal scroll bar between widths 900px and 1000px

[Tor Bug Tracker & Wiki]

#28543: Tor Browser's about:tor has horizontal scroll bar between widths 900px 
and
1000px
--+---
 Reporter:  pospeselr |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201811R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:2 gk]:
 > Looks reasonable in principle. However, that results in our question
 link etc. laid over the onions
 > [[Image(questions_on_onions.png)]]
 > while before that the text was between the search field and the onions
 (which looks cleaner). Do we want that change?

 Hmm. Is this behavior new? Kathy and I see this even without the change
 proposed in this ticket. Since the onions are anchored to the bottom of
 the window, when the window is very short the onions will appear behind
 the content (which seems OK to Kathy and 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

[tor-bugs] #28628 [Applications/Tor Browser]: Introduce New Security Settings to users

[Tor Bug Tracker & Wiki]

#28628: Introduce New Security Settings to users
-+-
 Reporter:  antonela |  Owner:  antonela
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ux-team,
 Severity:  Normal   |  TorBrowserTeam201811
Actual Points:   |  Parent ID:  #25658
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The proposal includes a section 3. which contemplates the way we are
 informing users about the new behavior.

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

Re: [tor-bugs] #28182 [Core Tor/Tor]: spec: Add to control-spec.txt some pluggable transport events

[Tor Bug Tracker & Wiki]

#28182: spec: Add to control-spec.txt some pluggable transport events
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 040-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 After implementation done in #28179, here is the updated branch:

 Branch: `ticket28182_02`

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

Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

[Tor Bug Tracker & Wiki]

#28181: spec: Add to pt-spec.txt control messages going back to main process 
(tor)
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, tor-pt, 040-roadmap-   |  Actual Points:
  subtask|
Parent ID:  #28180   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 After implementation done in #28179, here is the updated branch:

 Branch: `ticket28181_02`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28627 [Core Tor/Torsocks]: [torsocks] AAAA replies from tor not handled

[Tor Bug Tracker & Wiki]

#28627: [torsocks]  replies from tor not handled
+---
 Reporter:  u   |  Owner:  dgoulet
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Torsocks
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
 As reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895903:

 ''Tor now returns IPv6 addresses when hostnames are resolved, but torsocks
 cannot handle this case.''

 To reproduce:

 {{{
 torsocks -d nc v6.ipv6-test.com 80
 }}}

 ''
 This makes it tricky to use torsocks on domains that will resolve to an
  only causing the program to abort with no error message.''

 Indeed, in

 {{{
 int socks5_send_resolve_request(const char *hostname, struct connection
 *conn)
 }}}
 I see:

 {{{
 /* By default we use IPv4 address. */
 msg.atyp = SOCKS5_ATYP_DOMAIN;
 }}}

 (I've tested it from the command line with torsocks 2.3.0, and it does not
 work, while using TBB it works fine.)

 I'm not sure if this issue is also related to this bug:
 https://trac.torproject.org/projects/tor/ticket/25295

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

Re: [tor-bugs] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 Let's see what the bots say: branch against maint-0.3.4 here:
 https://github.com/torproject/tor/pull/549

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

Re: [tor-bugs] #28626 [UX/Research]: Usability Research: Circuit Display - Uganda (was: Usability Research: Circuit Display Uganda)

[Tor Bug Tracker & Wiki]

#28626: Usability Research: Circuit Display - Uganda
-+--
 Reporter:  nyinz|  Owner:  nyinz
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * owner:  antonela => nyinz
 * status:  new => assigned


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

Re: [tor-bugs] #26844 [Applications/Tor Browser]: TBA: Investigate/Setup Fastlane

[Tor Bug Tracker & Wiki]

#26844: TBA: Investigate/Setup Fastlane
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #26782| Points:
 Reviewer:|Sponsor:
--+--

Comment (by eighthave):

 From a short discussion on IRC with antonela, emmapeel, and pili:
 regarding localized screenshots for android apps, I recommend using
 Fastlane Supply.  The upside is that it can completely automate the
 procedure for taking screenshots.  Adding a new language is just adding
 the locale name, and running it again.  The downside is that it requires
 an Android dev to set it up by writing espresso tests.
 But once setup, I think it should be relatively stable.

 Also, if the screenshots are then commited to the project's git in the
 fastlane location, then F-Droid will automatically include them.

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

Re: [tor-bugs] #28626 [UX/Research]: Usability Research: Circuit Display Uganda

[Tor Bug Tracker & Wiki]

#28626: Usability Research: Circuit Display Uganda
-+--
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  UX/Research  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by nyinz):

 
https://docs.google.com/document/d/1J0lcawNyFBYjmqp9_fQWL6LilmcaeGmKGl70sAroUO8/edit

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

Re: [tor-bugs] #26844 [Applications/Tor Browser]: TBA: Investigate/Setup Fastlane

[Tor Bug Tracker & Wiki]

#26844: TBA: Investigate/Setup Fastlane
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #26782| Points:
 Reviewer:|Sponsor:
--+--
Changes (by eighthave):

 * cc: eighthave (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] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 1. Will do.
 2. Looks like the last change was in
 4c3d61b5f2450ff8bf81f02bbaa2a42baa7af372 for bug #28399.

 Maybe Tim have something to say here too? Looks like they have been fixing
 issues like this is a couple of times before.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28626 [UX/Research]: Usability Research: Circuit Display Uganda

[Tor Bug Tracker & Wiki]

#28626: Usability Research: Circuit Display Uganda
-+-
 Reporter:  nyinz|  Owner:  antonela
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  UX/Research
  Version:   |   Severity:  Normal
 Keywords:  ux-team  |  Actual Points:
Parent ID:  #27010   | Points:
 Reviewer:   |Sponsor:
-+-
 **Methodology**
 See file attached
 Where: Tor Training in Kampala, Uganda
 Participants: Seven (7)
 **Results**
 1.Summary of demographics
 2.What users said
 3.Conclusion
 4.Recommendations

 **1.**
 The group consisted of 6 male users and 1 female user aged 20-50
 Most users are technologists day to day tech users who use Tor on specific
 situations only

 **2.**
 Q1 Can you tell me what “Guard” means?
 Most users don’t know what the this question means although they relate
 this word it with ‘protecting’ or something ‘safe’ No user in this group
 is knowledgeable about the of different kinds of node roles and Guard node
 roles

 Q2 Can you identify which node is your Guard?
 -It is unclear to all the users what ‘node’ means
 -The user’s hesitate for more than 3 seconds before responding

 Q3 Did you need a new circuit before? Why? Can you ask for a New Circuit
 now? Do you know what it means?
 -Most users responded with a “No”
 -Users do not understand this and what UI helps on it

 Q4 Do you need more information about Guards? If yes, can you tell me how
 to find it?

 Most users do not know where to find this information
 Quote: “I don’t know”
 Users did not discover the Guard link and did not speak about Tor Browser
 User Manual explanation about how guards selection works

 Q5 Can you identify if you are connected by a bridge?
 Most users said they could identify this however their tone suggests that
 they are having trouble finding it

 **3.**
 The majority of users were confused by the terms used in this
 questionnaire like Guard/node/circuit
 The group responses reveal that knowledge about circuit and bridge
 settings is severely limited. In addition, users are having a hard time
 locating information on the circuit display

 ** 4.**
 -Users may be able to interact with the browser more easily if they could
 see how the different parts (guard/node/circuit/bridge) come together to
 provide secure internet access. Terminology could be revised for this
 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] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Looks okay to me.  Request:

 * Could you please backport this to whichever version first supported
 appveyor?  I think it was 0.3.4.

 Question:

 * Did you look over the history of this file?  I know there have been
 other changes there recently, especially wrt the version of openssl, and I
 wonder if we've undoing anything important here.

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

Re: [tor-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Okay, I gave the whole thing some testing and it works, nice! The two main
 points I have so far:

 1) I start the app and it says it's Tor Browser but I still need to start
 that Orbot thing which might confuse users ("Hey, I want to run Tor
 Browser and I already started it!1! What do I need to do now with that
 Orbot piece?). But I think that's okay for the alpha.

 2) More worriesome, though: I start Orbot and after it has bootstrapped
 nothing happens. It's essentially sitting there and no browser window pops
 up. In fact, it's not even clear how one could manually open one. I
 pressed by accident the button I usually press if I want to go back a
 website in my history and suddenly the window is open an I can use Tor
 Browser. Pressing that "going back one website"-button "works" as well if
 one has not started the Orbot part yet. The huge downside to that scenario
 is that it's not obvious how to go back to start Orbot now and the user is
 just receiving proxy connection errors (so far I needed to get rid of the
 current Tor Browser instance and start over to work around 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] #28574 [Core Tor/Tor]: Appveyor: OpenSSL unit test fails with header and library version mismatch

[Tor Bug Tracker & Wiki]

#28574: Appveyor: OpenSSL unit test fails with header and library version 
mismatch
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, tor-ci, windows,   |  Actual Points:
  appveyor, regression, openssl-1.1, |
  035-backport, 034-backport, 033-backport,  |
  029-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 Build log at https://ci.appveyor.com/project/ahf/tor/builds/20574608

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

Re: [tor-bugs] #28494 [Core Tor/Stem]: Please provide an equivalent for UnparseableDescriptor from metrics-lib

[Tor Bug Tracker & Wiki]

#28494: Please provide an equivalent for UnparseableDescriptor from metrics-lib
---+
 Reporter:  irl|  Owner:  atagar
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by irl):

 I'm using parse_file() at the moment. If we turn this prototype into a
 full CollecTor replacement then we might need something that looks like
 DescriptorReader, but we also might not. We could always move this
 functionality into bushel and just use parse_file() from stem.

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