Re: [tor-bugs] #29196 [Core Tor/Tor]: circ: Remove p_mux and n_mux from circuit_t and or_circuit_t

[Tor Bug Tracker & Wiki]

#29196: circ: Remove p_mux and n_mux from circuit_t and or_circuit_t
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-cmux, tor-circuit  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+
Changes (by arma):

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


Comment:

 It is beautiful. I have merged 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] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by cypherpunks):

 Replying to [comment:35 gk]:
 > Why are we using 0.3.5.6-rc (which is a release candidate and no stable
 tor)?
 Because this is an alpha.
 > Are we sure we are better off security- and/or stability- and/or
 performance-wise than with 0.3.4.9?
 All of them, but mostly performance.
 > We have been testing the latter for quite a while now but not the -rc
 yet and we plan to have a stable soon for Android users...
 Then somebody should make a 0.3.5.8 one with
 https://www.openssl.org/news/secadv/20190226.txt

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

Re: [tor-bugs] #29196 [Core Tor/Tor]: circ: Remove p_mux and n_mux from circuit_t and or_circuit_t

[Tor Bug Tracker & Wiki]

#29196: circ: Remove p_mux and n_mux from circuit_t and or_circuit_t
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-cmux, tor-circuit  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:4 dgoulet]:
 > It is intended for master. No backport. At the time the branch was done,
 master was still 040.
 Thanks! Looks good to me! I made a pull request at
 https://github.com/torproject/tor/pull/797 which passes CI. There are some
 coverage reductions, but looking at the build of the base revision, that
 might be coverage flapping due to nondeterminism.

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

Re: [tor-bugs] #29733 [Applications/Tor Browser]: Disable NoSript XSS protection for now due to bug 1532530

[Tor Bug Tracker & Wiki]

#29733: Disable NoSript XSS protection for now due to bug 1532530
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  noscript, TorBrowserTeam201903  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mig5):

 Hi, mig5 from the OnionShare project here.

 Following eloquence's steps, I can confirm that OnionShare uploads are
 succeeding for me too, using that TB 8.0.7-build3 build, and 10.2.2rc3 of
 NoScript.

 I tested uploading a 62, 125 and 377 MB file, both in 'local' (no Tor) and
 Tor mode, all under Tor Browser's 'Safer' security setting, without
 experiencing any issues. Looking good, 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] #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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Okay, I have a new branch and I think I solved most of the bugs.
 `28329_17`.

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

Re: [tor-bugs] #29733 [Applications/Tor Browser]: Disable NoSript XSS protection for now due to bug 1532530

[Tor Bug Tracker & Wiki]

#29733: Disable NoSript XSS protection for now due to bug 1532530
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  noscript, TorBrowserTeam201903  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by eloquence):

 Here's the procedure I followed:

 1) Per last comment on
 https://trac.torproject.org/projects/tor/ticket/29733 , downloaded 8.0.7b3
 from https://people.torproject.org/~boklm/builds/8.0.7-build3/tor-browser-
 linux64-8.0.7_en-US.tar.xz and ran it

 2) Removed shipped version of NoScript, activated debug mode, downloaded
 Source Code ZIP from
 https://github.com/hackademix/noscript/releases/tag/10.2.2rc3 , and loaded
 its `manifest.json` in debug mode

 3) Changed NoScript settings to these ones: "Sanitize cross-site
 suspicious requests": CHECKED, "Scan uploads for potential cross-site
 attacks": NOT CHECKED, "Ask confirmation for cross-site POST requests
 which could not be scanned": CHECKED

 4) Uploaded a 271M file through source interface of my local SecureDrop
 hardware instance.

 So far so good -- two test uploads succeeded, will do some more testing
 tomorrow. I'll flag this to the OnionShare folks in case they have time to
 do additional testing, as well.

 Thanks for all the help getting this issue resolved. Fingers crossed; will
 post another update after more 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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by mcs):

 * Attachment "0001-fixup-Bug-25658-Replace-security-slider-with-
 securit.patch" added.

 fixup to relocate the Torbutton toolbar item

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Replying to [comment:98 pospeselr]:
 > Updated torbutton to handle user upgrade correctly and excises the fix
 for #27478 (will put that in a new branch and post to that ticket). Also
 rebased it against latest torbutton master. Fixed whitespace issues in
 tor-browser and torbutton with a `git rebase --whitespace=fix HEAD~1`
 >
 > torbutton:
 https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658_v2
 > torbrowser: https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_25658_v5

 Looks good to me, except I think per comment:79 we want the Torbutton icon
 to be relocated to the right side of the toolbar. I will attach a fixup
 patch.

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

Re: [tor-bugs] #28656 [Core Tor/Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
-+-
 Reporter:  meejah   |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, 035-rc-blocker?, |  Actual Points:  0.1
  035-backport, postfreeze-ok, 040-must  |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me! Coverage went down by a couple of lines, possibly
 because the removed `BUG()` was previously marking unreachable code.

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

Re: [tor-bugs] #29787 [Metrics/Onionperf]: Enumerate possible failure cases and include failure information in .tpf output

[Tor Bug Tracker & Wiki]

#29787: Enumerate possible failure cases and include failure information in .tpf
output
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 Worth noting that the OnionPerf json output records the following error
 codes when a transfer fails, which come directly form TGen:

 shd-tgen-transfer.c:case TGEN_XFER_ERR_NONE
 shd-tgen-transfer.c:case TGEN_XFER_ERR_AUTH
 shd-tgen-transfer.c:case TGEN_XFER_ERR_READ
 shd-tgen-transfer.c:case TGEN_XFER_ERR_WRITE
 shd-tgen-transfer.c:case TGEN_XFER_ERR_TIMEOUT
 shd-tgen-transfer.c:case TGEN_XFER_ERR_STALLOUT
 shd-tgen-transfer.c:case TGEN_XFER_ERR_PROXY
 shd-tgen-transfer.c:case TGEN_XFER_ERR_MISC

 We should consider making OnionPerf include the code (NONE, AUTH, READ
 etc) in .tpf output.
 I can also work towards analyzing archived data to see how these codes map
 to the examples above and classify them. For now, these are my initial
 thoughts:
 * A 'NONE' error corresponds to a successful transfer
 * A 'TIMEOUT' error is recorded by OP if the TGen client fails to complete
 a transfer in a certain amount of time (defined in the TGen model graph)
 * A 'STALLOUT' error is recorded by OP if the TGen client fails to
 transfer any bytes in a certain amount of time (defined in the TGen model
 graph)
 * However, OP records a 'READ' error if the TGen server times out of a
 transfer, and possibly due to other failures
 * Streams being destroyed usually result in a 'PROXY' error, these can be
 further correlated with the torctl logs to define subcases

 Will update after digging some more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29789 [Core Tor/Tor]: practracker.py codec exception in some locales

[Tor Bug Tracker & Wiki]

#29789: practracker.py codec exception in some locales
---+--
 Reporter:  catalyst   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+--
 practracker.py, implemented in #29221, seems to have a locale dependency
 when python3 is being used.  If the locale isn't a UTF-8 locale, UTF-8
 characters in sources can result in an exception:

 {{{
 $ LANG=en_US.US-ASCII make check-best-practices PYTHON=python
 python ../scripts/maint/practracker/practracker.py ..
 mirkwood:build-norust tlyu$ LANG=en_US.US-ASCII make check-best-practices
 python3 ../scripts/maint/practracker/practracker.py ..
 Traceback (most recent call last):
   File "../scripts/maint/practracker/practracker.py", line 151, in
 
 main()
   File "../scripts/maint/practracker/practracker.py", line 134, in main
 found_new_issues = consider_all_metrics(files_list)
   File "../scripts/maint/practracker/practracker.py", line 89, in
 consider_all_metrics
 found_new_issues |= consider_metrics_for_file(fname, f)
   File "../scripts/maint/practracker/practracker.py", line 104, in
 consider_metrics_for_file
 found_new_issues |= consider_file_size(fname, f)
   File "../scripts/maint/practracker/practracker.py", line 51, in
 consider_file_size
 file_size = metrics.get_file_len(f)
   File "/Users/tlyu/src/tor/scripts/maint/practracker/metrics.py", line
 11, in get_file_len
 for i, l in enumerate(f):
   File
 
"/Users/tlyu/src/brew/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/encodings/ascii.py",
 line 26, in decode
 return codecs.ascii_decode(input, self.errors)[0]
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 14:
 ordinal not in range(128)
 make: *** [check-best-practices] Error 1
 }}}

 I'm also seeing this on gitlab.com CI, but I don't know offhand what its
 locale environment variables are.

 We might want to use the `encoding=` keyword parameter to `open()`, but I
 think that would no longer be python2 compatible.

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

Re: [tor-bugs] #27478 [Applications/Tor Browser]: Torbutton in Tor Browser 8 difficult to see in dark theme

[Tor Bug Tracker & Wiki]

#27478: Torbutton in Tor Browser 8 difficult to see in dark theme
-+-
 Reporter:  nsuchy   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-8.0-issues, |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201903R, tbb-8.5  |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * keywords:  ux-team, tbb-8.0-issues, tbb-8.0.1-can, TorBrowserTeam201903,
 tbb-8.5 => ux-team, tbb-8.0-issues, tbb-8.0.1-can,
 TorBrowserTeam201903R, tbb-8.5
 * status:  assigned => needs_review


Comment:

 Excised the torbutton svg changes from #25658 into this branch :
 https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_27478

 Torbutton icon now takes on appropriate fill and opacity values from the
 current theme.

 Light Theme:
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/27478/light_theme.png)]]
 Default Theme:
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/27478/default_theme.png)]]
 Dark Theme;
 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/27478/dark_theme.png)]]

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

Re: [tor-bugs] #27478 [Applications/Tor Browser]: Torbutton in Tor Browser 8 difficult to see in dark theme

[Tor Bug Tracker & Wiki]

#27478: Torbutton in Tor Browser 8 difficult to see in dark theme
-+-
 Reporter:  nsuchy   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-8.0-issues, |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201903, tbb-8.5   |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "dark_theme.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] #27478 [Applications/Tor Browser]: Torbutton in Tor Browser 8 difficult to see in dark theme

[Tor Bug Tracker & Wiki]

#27478: Torbutton in Tor Browser 8 difficult to see in dark theme
-+-
 Reporter:  nsuchy   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-8.0-issues, |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201903, tbb-8.5   |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "default_theme.2.png" removed.


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

Re: [tor-bugs] #27478 [Applications/Tor Browser]: Torbutton in Tor Browser 8 difficult to see in dark theme

[Tor Bug Tracker & Wiki]

#27478: Torbutton in Tor Browser 8 difficult to see in dark theme
-+-
 Reporter:  nsuchy   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-8.0-issues, |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201903, tbb-8.5   |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "default_theme.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] #27478 [Applications/Tor Browser]: Torbutton in Tor Browser 8 difficult to see in dark theme

[Tor Bug Tracker & Wiki]

#27478: Torbutton in Tor Browser 8 difficult to see in dark theme
-+-
 Reporter:  nsuchy   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-8.0-issues, |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201903, tbb-8.5   |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "default_theme.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] #27478 [Applications/Tor Browser]: Torbutton in Tor Browser 8 difficult to see in dark theme

[Tor Bug Tracker & Wiki]

#27478: Torbutton in Tor Browser 8 difficult to see in dark theme
-+-
 Reporter:  nsuchy   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-8.0-issues, |  Actual Points:
  tbb-8.0.1-can, TorBrowserTeam201903, tbb-8.5   |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "light_theme.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] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by pospeselr):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #29765 [Applications/Tor Browser]: TorBrowser ignores proxy settings

[Tor Bug Tracker & Wiki]

#29765: TorBrowser ignores proxy settings
--+---
 Reporter:  DNied |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by DNied):

 @mcs: yes, that works. The setting can't be toggled in the Preferences
 when "No Proxy" is selected, but it can be toggled in about:config. That
 setting is a bit of a misnomer though, since I'm no longer using SOCKS
 when I pick "No Proxy".

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by pospeselr):

 updated torbutton patch that handles user upgrade correctly and excises
 the fix for #27478 (will put that in a new branch and post to that
 ticket):

 https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658_v2

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

[tor-bugs] #29788 [Internal Services/Tor Sysadmin Team]: Create email alias to core contributor Vinícius Zavam (egypcio)

[Tor Bug Tracker & Wiki]

#29788: Create email alias to core contributor Vinícius Zavam (egypcio)
-+-
 Reporter:  ggus |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hello, please create the email alias for our core contributor Vinicius
 Zavam (egypcio):

 egypcio@tpo to egyp...@riseup.net

 thanks!
 Gus

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

Re: [tor-bugs] #25430 [Obfuscation/BridgeDB]: Turkey bridges.torproject.org cant access

[Tor Bug Tracker & Wiki]

#25430: Turkey bridges.torproject.org cant access
--+---
 Reporter:  fromturkey|  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  censorship block tr   |  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:  Sponsor19
--+---

Comment (by ahf):

 @fromturkey is this still a problem after the arrival of the domain-
 fronted "moat" feature for requesting bridges via bridgedb directly in
 TorBrowser?

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

Re: [tor-bugs] #29297 [Obfuscation/Obfsproxy]: Write reachability tests to verify if obfs4 is working or not

[Tor Bug Tracker & Wiki]

#29297: Write reachability tests to verify if obfs4 is working or not
-+-
 Reporter:  chelseakomlo |  Owner:  cohosh
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Obfsproxy|Version:
 Severity:  Normal   | Resolution:
 Keywords:  obfs4, network-team- |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #29279   | Points:  2
 Reviewer:  dcf, ahf |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

 * reviewer:   => dcf, ahf


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

Re: [tor-bugs] #29201 [Core Tor/Tor]: Tor bootstrap hangs when offline

[Tor Bug Tracker & Wiki]

#29201: Tor bootstrap hangs when offline
---+---
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  040-deferred-20190220  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by atagar):

 Thanks teor. We've been changing our bootstrap behavior quite a bit of
 late (first message format in #28731, and now our offline behavior). This
 is fine, and I'd be happy to work with the network team on the long term
 bootstrapping behavior we want but this feels a bit ad-hoc. Why did we
 change this, and are there more bootstrapping changes coming down the
 pipe?

 Nick added a DROPOWNERSHIP command so in tor versions going forward I can
 avoid parsing stdout logs (#28843). Taking advantage of that is pretty
 high on my todo list, and will let us change bootstrap log formatting at
 will. However, behavioral changes like this will still impact Stem.

 In this particular case I do not mind the behavior change. Stem's tests
 already intend to run when we're 0% bootstrapped so I need to investigate
 this more on my side...

 https://gitweb.torproject.org/stem.git/tree/test/runner.py#n629
 https://gitweb.torproject.org/stem.git/tree/stem/process.py#n170

 Stepping back, maybe we should rethink bootstrapping more fundamentally?
 In particular...

 1. Bootstrap behavior is undocumented. Traditionally this has been fine
 because it never changed.

Stem and Txtorcon use bootstrapping to determine "Is my tor process
 ready to do X?" where X are things like "make a circuit" or "run a hidden
 service". We don't care about the bootstrap percentage (see below), but we
 use their implication that tor has become ready to do things.

Our usage is causing you friction. We should use another mechanism or
 formalize this by documenting tor's bootstrapping behavior including what
 the various percentages (or messages) mean.

 2. If we're going to rethink bootstrapping maybe we should go further? Why
 do we even present bootstrapping as percentages? Does this make sense?

Said another way, if "tor is 13% boostrapped" what does that mean? It
 isn't a time estimate (we're not saying that we're 13% done). It's also
 not saying that tor is capable of 13% of its capabilities.

I suspect bootstrap percentages might be a holdover from Vidalia's
 progress bar, which from a user perspective always stunk (descriptor
 downloads usually dominate bootstrapping so the bar jumped to ~55%, hangs
 for a minute, then jumps to 100%).

Obligatory video: https://www.youtube.com/watch?v=1V2SHW6Qx_E

 Just spitballing, but how about the following?

 1. Drop the bootstrap percentage.
 2. Define bootstrap logging as purely informational (ie. controllers like
 Stem should not use it).
 3. Add GETINFO commands that answer any "Is tor ready to do X?" inquiries.

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

Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 Replying to [comment:36 sysrqb]:
 > Replying to [comment:35 gk]:
 > > `orbot-uber.patch` is tricky to review
 > On this note, did you combine all the patches for a reason? The separate
 patches make reviewing changes much easier and they provide logical
 separation. A single patch is a little overwhelming.

 I'm going to break apart between uber and tor-android-service/TOPL related
 changes. The uber patch should only contain changes to orbot app module.
 We dump it completely once this branch is merged with your new UI/app
 changes, keeping only the tor-android-service/TOPL related patches.

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

Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 Replying to [comment:35 gk]:

 > Okay, I looked over all the patches for #29312, #29313, #29574, and
 #29575. Nice work! It feels we are pretty close here. We can use the
 parent ticket to address all comments/review requests in one place. Here
 are my 2cents:
 >
 > e38175545f4de75030fcf48b9950b65118228688 (#29312)
 >
 > Why are we using 0.3.5.6-rc (which is a release candidate and no stable
 tor)? Are we sure we are better off security- and/or stability- and/or
 performance-wise than with 0.3.4.9? We have been testing the latter for
 quite a while now but not the -rc yet and we plan to have a stable soon
 for Android users...

 Good point. I'm moving this back to 0.3.4.9. I'll do this within tor-
 android-service project.

 >
 > d79c8ef41190cc37c16c7b90cfe65f083d6a3b95 (#29313)
 > {{{
 > ++ndk {
 > ++abiFilters "armeabi-v7a"
 > ++}
 > }}}
 > How does that work for x86 builds which we have now as well? Do we need
 a similar entry for them as well? If so, what is supposed to happen if we
 omitted both entries?

 This is no longer needed. We don't use VPN so don't need any native
 builds. I'll remove this from the patch.

 >
 > 8e3d539f76e3bd45a809dc1b14277d2b1a2fa3c4 (#29574)
 >
 > I assume "tor-0.3.4.9" is just part of the filename of the .aar file but
 there is no tor 0.3.4.9 or 0.3.4.9 related code in it? (Especially as you
 are using 0.3.5.6-rc) Otherwise I'd be worried about possible bad
 interactions with code belonging to different tor versions.

 We are just pulling in the android-binary library for the project. I'll
 align the versions to 0.3.4.9

 >
 > `orbot-uber.patch` is tricky to review, the diff to the older patchset
 is
 > {{{
 > diff --git a/app/build.gradle b/app/build.gradle
 > index 3051dd5c..4e33472c 100644
 > --- a/app/build.gradle
 > +++ b/app/build.gradle
 > @@ -76,12 +76,16 @@ android {
 > dependencies {
 > //implementation 'com.github.delight-im:Android-Languages:v1.0.1'
 > implementation 'com.android.support.constraint:constraint-layout:1.1.3'
 > -implementation project(':orbotservice')
 > // Match Fennec's ANDROID_SUPPORT_LIBRARY_VERSION
 > implementation 'com.android.support:design:23.4.0'
 > implementation 'pl.bclogic:pulsator4droid:1.0.3'
 > // These require higher versions of ANDROID_SUPPORT_LIBRARY_VERSION
 > //implementation 'com.github.apl-devs:appintro:v4.2.2'
 > //implementation 'com.github.javiersantos:AppUpdater:2.6.4'
 > -
 > +implementation fileTree(dir: 'libs', include: ['*.jar', '*.aar'])
 > +implementation 'com.android.support:appcompat-v7:26.1.0'
 > +implementation 'net.freehaven.tor.control:jtorctl:0.2'
 > +implementation 'org.torproject:tor-android-binary:0.3.5.6-rc'
 > +implementation 'org.slf4j:slf4j-api:1.7.25'
 > +implementation 'org.slf4j:slf4j-android:1.7.25'
 > }
 > diff --git a/build.gradle b/build.gradle
 > index edcfc84f..ce06f082 100644
 > --- a/build.gradle
 > +++ b/build.gradle
 > @@ -3,7 +3,6 @@ buildscript {
 > repositories {
 > jcenter()
 > google()
 > -maven { url System.getenv("GRADLE_MAVEN_REPO") }
 > }
 > dependencies {
 > // Match Fennec
 > @@ -17,6 +16,5 @@ allprojects {
 > maven { url
 "https://raw.githubusercontent.com/guardianproject/gpmaven/master"; }
 > google()
 > maven { url 'https://jitpack.io' }
 > -maven { url System.getenv("GRADLE_MAVEN_REPO") }
 > }
 > }
 > diff --git a/settings.gradle b/settings.gradle
 > index 9984a03e..e7b4def4 100644
 > --- a/settings.gradle
 > +++ b/settings.gradle
 > @@ -1,2 +1 @@
 > -include ':jsocksAndroid', ':orbotservice'
 > include ':app'
 > }}}

 I just have the uber patch for convenience. My expectation is that when we
 merge with the new UI there will be a bunch of new patches we apply and
 then can remove the uber patch. What I'll do is move the tor-android-
 service parts into a new patch(es) so its easier to track and migrate.
 This patch involves

  * Remove the building of orbotservice and jsocksAndroid
  * Add in gradle dependencies so

[tor-bugs] #29787 [Metrics/Onionperf]: Enumerate possible failure cases and include failure information in .tpf output

[Tor Bug Tracker & Wiki]

#29787: Enumerate possible failure cases and include failure information in .tpf
output
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Our current model for distinguishing failures, timeouts, and successes is
 rather simple/arbitrary/confusing:

  - Timeout: We count any measurement with `DIDTIMEOUT=1` and/or with
 `DATACOMPLETE<1` as timeout.
  - Failure: We count any measurement that doesn't have `DIDTIMEOUT=1` and
 that has `DATACOMPLETE>=1` and `READBYTEShttps://metrics.torproject.org
 /torperf-failures.html here]. This is not as useful as it could be.

 It would be so much better to enumerate all possible failure cases and
 include failure information in .tpf output files. Examples:

  - Turns out that long-running tor instances sometimes fail to keep up-to-
 date directory information (#29743), and as a result OnionPerf cannot make
 measurements.
  - Sometimes streams are closed with reason TIMEOUT or DESTROY (pages 1
 and 2 of the first attachment on #29744), and I bet there are several
 subcases in each of these.
  - Regarding timeouts, it does happen that streams are closed by OnionPerf
 (pages 3 and 4 of that same attachment on #29744).
  - There are likely more failure cases that might be less frequent that I
 either did not include them in the #29744 graphs or did not even run into
 them at all in the logs I looked at.

 Can we enumerate all or at least the most typical failure cases and define
 criteria for clearly distinguishing them from each other and from timeouts
 and from successes?

 Can we also try to unambiguously identify these failure cases in existing
 tor/torctl/tgen logs that we process for .tpf files, so that we could
 include failure case IDs for them in the .tpf files?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by antonela):

 Replying to [comment:46 gk]:
 > 1) Say you want to use custom bridges. BridgeDB gives usually three of
 those out. So, the natural thing to do is to select, copy and paste those
 three lines. However, they are pasted into the _one_ line we have on the
 custom bridge view. The hint that one needs to have one bridge per line is
 a good one. But there is no way to get there with the three bridges copied
 and pasted. What we need to have here is a multiline textbox instead, I
 think.
 >

 Do you expect something like this?

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28329/TBA%20Settings%20Network%20-%20Bridge%20-%20known.png,
 400px)]]

 On MD docs, the multi-line text field gets expanded right after the user
 writes/copypaste.

 https://material.io/design/components/text-fields.html#input-types

 Maybe It can get solved by changing the text field type, not the height.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by antonela):

 * Attachment "TBA Settings Network - Bridge - known.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] #29677 [Internal Services/Tor Sysadmin Team]: evaluate password management options

[Tor Bug Tracker & Wiki]

#29677: evaluate password management options
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:
 |  assigned
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 there's also a KeePassXC instance somewhere used by jon, sue and
 sstevenson at least.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by antonela):

 Replying to [comment:46 gk]:
 > 2) Assuming you are running with the one custom bridge you configured
 during 1) and select the gear icon on the start view you'll get informed
 that you are running Tor Browser with a custom bridge with the link to
 change that. That's good. However, that does not help me if I want to fall
 back to a built-in bridge because clicking the change-link only gets me to
 the custom bridge input field. So, if I want to use a built-in bridge
 instead I have to first disable using bridges altogether just to reenable
 them later on and change the custom bridge type I want. That's a bit
 cumbersome...


 I see. Also there is not any clue at the `Select Bridge` screen that allow
 users to know that that the known bridge provided was successfully saved.

 We can fix both issues having a toggle menu at that list.
 https://marvelapp.com/4fcjj0e/screen/54462993

 So:

 - when users tap on `Select a Bridge`, the bridge options get displayed.
 - when users tap on `Provide a Bridge I Know`, we move users to the second
 screen. When they back to `Select Bridge` screen, they can see the
 description updated like:

 https://marvelapp.com/4fcjj0e/screen/54462995

 Then, when users got back to the `Network Settings` screen, we maintain
 the current description 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

Re: [tor-bugs] #29784 [Webpages/Website]: Validate website for Keybase account

[Tor Bug Tracker & Wiki]

#29784: Validate website for Keybase account
--+-
 Reporter:  sstevenson|  Owner:  anarcat
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by anarcat):

 * status:  assigned => closed
 * component:  - Select a component => Webpages/Website
 * resolution:   => wontfix


Comment:

 looks like we can close or at least postpone this for now.

 {{{
 13:32:46 <+ahf> anarcat, weasel, ln5: just looked at the emails sarah
 forwarded me, it sounds like the foundraiser team can use another wallet
 than keybase.io
 }}}

 the concerns raised over IRC were:

 {{{
 12:56:33 <+weasel> sstevenson: who owns the private key to
 ASAdoHonWIY_yoguQsjRVMQEvO7JGgroMAbSFrlvBdQ58wo?
 12:56:55 <+weasel> sstevenson: what does "I am an admin of
 https://torproject.org"; mean and imply?
 12:57:17  ln5 also asked if the secrets to access keybase.io were
 shared with more than one person and i am not sure we had a clear answer
 on that either
 12:57:56 <+weasel> and where do the other magic numbers in the document
 from #29784 come from
 }}}

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

Re: [tor-bugs] #29733 [Applications/Tor Browser]: Disable NoSript XSS protection for now due to bug 1532530

[Tor Bug Tracker & Wiki]

#29733: Disable NoSript XSS protection for now due to bug 1532530
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_information
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  noscript, TorBrowserTeam201903  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:11 eloquence]:
 > > What if I provide an option to just disable XSS injection checks on
 POST parameters (which would prevent the requestBody listener from being
 registered), and possibly another option to ask user confirmation for POST
 requests from JavaScript-disabled sites to TRUSTED ones, in order to
 mitigate the loss of protection?
 >
 > What will the default behavior in Tor be if, say, the user is attempting
 to upload to SecureDrop with JavaScript disabled? Would they get a scary
 confirmation dialog? It would be really good to avoid scary confirmation
 messages that make the user think that there is a security issue, when
 there really is not.
 >
 > (I realize this is now a NoScript issue again, feel free to point me to
 a corresponding issue if that's a better place to discuss. :)

 Could you test whether the Tor Browser release candidate
 (https://people.torproject.org/~boklm/builds/8.0.7-build3/ has bundles) +
 the NoScript release candidate solve the issue for you?

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

Re: [tor-bugs] #22132 [Core Tor/Chutney]: Chutney should avoid waiting for set times: wait for conditions instead

[Tor Bug Tracker & Wiki]

#22132: Chutney should avoid waiting for set times: wait for conditions instead
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Chutney|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:  1.2
Parent ID:  #20647  | Points:  2
 Reviewer:  |Sponsor:  Sponsor19
+--
Changes (by nickm):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #22132 [Core Tor/Chutney]: Chutney should avoid waiting for set times: wait for conditions instead

[Tor Bug Tracker & Wiki]

#22132: Chutney should avoid waiting for set times: wait for conditions instead
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Chutney|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:  1.2
Parent ID:  #20647  | Points:  2
 Reviewer:  |Sponsor:  Sponsor19
+--

Comment (by nickm):

 I've made the requested changes in wait_for_bootstrap_better. PR still at
 ​https://github.com/torproject/chutney/pull/12

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

Re: [tor-bugs] #29537 [Core Tor/Tor]: verify intptr_t round-trip through void *

[Tor Bug Tracker & Wiki]

#29537: verify intptr_t round-trip through void *
+--
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  portability technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst, teor  |Sponsor:
+--

Comment (by rl1987):

 Are we doing the right thing here though? Intuitively, if we're writing
 code that a compiler might very reasonably optimize away, aren't we on a
 wrong path?

 Perhaps we should create tickets to fix parts of tor codebase that rely on
 putting integers into `void *` one by one?

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

[tor-bugs] #29786 [Core Tor/Tor]: Path bias circuits can still have cells pending

[Tor Bug Tracker & Wiki]

#29786: Path bias circuits can still have cells pending
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #25773, we realized that half-closed connections need to be checked for
 extra cells when the circuit has been switched to path bias testing. The
 checks were added to the top of circuit_receive_relay_cell(), by calling
 pathbias_check_probe_response() to check if the path bias probe was
 correct, and if not, we call pathbias_count_valid_cells() to check if the
 cell is from a previous half-closed connection.

 In https://github.com/mikeperry-tor/vanguards/issues/37, we learned that
 path bias circuits can still have a pending cell for onion services. In
 particular, there can be outstanding cells for
 RELAY_COMMAND_INTRO_ESTABLISHED, RELAY_COMMAND_RENDEZVOUS_ESTABLISHED, and
 RELAY_COMMAND_INTRODUCE_ACK, depending on circuit type.

 There's sloppy ways to fix this, which are easy (just hack
 pathbias_count_valid_cells() to allow 1 cell for those circuit types) and
 precise ways (actually track if the pending cell has been received or not
 before and after path bias transition).

 We should probably fix this the precise way, and just implement the hacky
 workaround in vanguards for now.

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

Re: [tor-bugs] #29784 [- Select a component]: Validate website for Keybase account

[Tor Bug Tracker & Wiki]

#29784: Validate website for Keybase account
--+--
 Reporter:  sstevenson|  Owner:  anarcat
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Old description:

> Please serve the text below exactly as it appears at one of these URL's.
> torproject.org/keybase.txt
> torproject.org/.well-known/keybase.txt
>
> ==
> https://keybase.io/torproject
> 
>
> I hereby claim:
>
>   * I am an admin of https://torproject.org
>   * I am torproject (https://keybase.io/torproject) on keybase.
>   * I have a public key ASAdoHonWIY_yoguQsjRVMQEvO7JGgroMAbSFrlvBdQ58wo
>
> To do so, I am signing this object:
>
> {
>   "body": {
> "key": {
>   "eldest_kid":
> "01201da07a2758863fca882e42c8d154c404bceec91a0ae83006d216b96f05d439f30a",
>   "host": "keybase.io",
>   "kid":
> "01201da07a2758863fca882e42c8d154c404bceec91a0ae83006d216b96f05d439f30a",
>   "uid": "f718105e715c0285072c34b7a3242f19",
>   "username": "torproject"
> },
> "merkle_root": {
>   "ctime": 1552569712,
>   "hash":
> "5a37a30fd64d01fe5327606b4e3b9ab4d2e3bedf47ab1879d82beedb9b90fd50fcef8c25fc1ab8656f2f470fc86681a91704313d110364403cb166605b8a04b7",
>   "hash_meta":
> "42b865fe5e57eaa2ce8ab03393f4dc130d974e60e3c73c07cda81feced9684db",
>   "seqno": 4947688
> },
> "service": {
>   "entropy": "s+Bu6CaZHogKL7QgLZnmbjuE",
>   "hostname": "torproject.org",
>   "protocol": "https:"
> },
> "type": "web_service_binding",
> "version": 2
>   },
>   "client": {
> "name": "keybase.io go client",
> "version": "3.1.2"
>   },
>   "ctime": 1552569741,
>   "expire_in": 504576000,
>   "prev":
> "5bba9330c977c2edca30b07efd196e8f4ca1b19474679719c8ccfd39aef01a34",
>   "seqno": 7,
>   "tag": "signature"
> }
>
> which yields the signature:
>
> hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgHaB6J1iGP8qILkLI0VTEBLzuyRoK6DAG0ha5bwXUOfMKp3BheWxvYWTESpcCB8QgW7qTMMl3wu3KMLB+/Rluj0yhsZR0Z5cZyMz9Oa7wGjTEINHjiOT4Q+HQ87/Mi57OJcnAsgedgnUIzxgdbgu0SB1zAgHCo3NpZ8RAItd5mHtrKuA4ab5GBGRZMBK/7aNV8Sehc3SX4CuHRYnQlwDSiIJoCNn2uUWHSgAHBEKy8uSgKqxyrRh+FuoKD6hzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIPML0trTWzef+kJXRUjnquKkYpEV98+cIXrIp67hOAT1o3RhZ80CAqd2ZXJzaW9uAQ==
>
> And finally, I am proving ownership of this host by posting or
> appending to this document.
>
> View my publicly-auditable identity here: https://keybase.io/torproject
>
> ==

New description:

 Please serve the text below exactly as it appears at one of these URL's.
 torproject.org/keybase.txt
 torproject.org/.well-known/keybase.txt

 {{{
 ==
 https://keybase.io/torproject
 

 I hereby claim:

   * I am an admin of https://torproject.org
   * I am torproject (https://keybase.io/torproject) on keybase.
   * I have a public key ASAdoHonWIY_yoguQsjRVMQEvO7JGgroMAbSFrlvBdQ58wo

 To do so, I am signing this object:

 {
   "body": {
 "key": {
   "eldest_kid":
 "01201da07a2758863fca882e42c8d154c404bceec91a0ae83006d216b96f05d439f30a",
   "host": "keybase.io",
   "kid":
 "01201da07a2758863fca882e42c8d154c404bceec91a0ae83006d216b96f05d439f30a",
   "uid": "f718105e715c0285072c34b7a3242f19",
   "username": "torproject"
 },
 "merkle_root": {
   "ctime": 1552569712,
   "hash":
 
"5a37a30fd64d01fe5327606b4e3b9ab4d2e3bedf47ab1879d82beedb9b90fd50fcef8c25fc1ab8656f2f470fc86681a91704313d110364403cb166605b8a04b7",
   "hash_meta":
 "42b865fe5e57eaa2ce8ab03393f4dc130d974e60e3c73c07cda81feced9684db",
   "seqno": 4947688
 },
 "service": {
   "entropy": "s+Bu6CaZHogKL7QgLZnmbjuE",
   "hostname": "torproject.org",
   "protocol": "https:"
 },
 "type": "web_service_binding",
 "version": 2
   },
   "client": {
 "name": "keybase.io go client",
 "version": "3.1.2"
   },
   "ctime": 1552569741,
   "expire_in": 504576000,
   "prev":
 "5bba9330c977c2edca30b07efd196e8f4ca1b19474679719c8ccfd39aef01a34",
   "seqno": 7,
   "tag": "signature"
 }

 which yields the signature:

 
hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgHaB6J1iGP8qILkLI0VTEBLzuyRoK6DAG0ha5bwXUOfMKp3BheWxvYWTESpcCB8QgW7qTMMl3wu3KMLB+/Rluj0yhsZR0Z5cZyMz9Oa7wGjTEINHjiOT4Q+HQ87/Mi57OJcnAsgedgnUIzxgdbgu0SB1zAgHCo3NpZ8RAItd5mHtrKuA4ab5GBGRZMBK/7aNV8Sehc3SX4CuHRYnQlwDSiIJoCNn

Re: [tor-bugs] #29766 [Applications/Tor Browser]: Get us closer to use release build config

[Tor Bug Tracker & Wiki]

#29766: Get us closer to use release build config
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 So, you don't want to get it fixed in TBB 8.5?

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

Re: [tor-bugs] #29785 [Community/Tor Support]: Update glossary terms to current new TB funcionality.

[Tor Bug Tracker & Wiki]

#29785: Update glossary terms to current new TB funcionality.
---+--
 Reporter:  emmapeel   |  Owner:  phoul
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29657 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by emmapeel):

 * parent:   => #29657


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

Re: [tor-bugs] #29766 [Applications/Tor Browser]: Get us closer to use release build config

[Tor Bug Tracker & Wiki]

#29766: Get us closer to use release build config
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-rbm, tbb-8.5 => tbb-rbm


Comment:

 Replying to [comment:3 cypherpunks]:
 > This is needed to make TBB 8.5 the first release-grade quality series.
 >
 > (`+ac_add_options --enable-debug-symbols=""` should fix HEASLR, btw)

 How should that fix HEASLR?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29785 [Community/Tor Support]: Update glossary terms to current new TB funcionality.

[Tor Bug Tracker & Wiki]

#29785: Update glossary terms to current new TB funcionality.
---+--
 Reporter:  emmapeel   |  Owner:  phoul
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Reported by translator @zakooch while translating the glossary, some terms
 are outdated in relation to the Tor Browser:


 == Security Slider

 Tor Browser includes a “Security Slider” that lets you increase your
 security by disabling certain web features that can be used to attack your
 security and anonymity. It is located in Torbutton’s “Privacy and Security
 Settings” menu. Increasing the level (Low, Medium-Low, Medium-High, High)
 of the Security Slider will disable or partially disable certain web
 browser features to protect against possible attacks.


 == Torbutton

 A button marked by a little green onion to the left of the URL bar. Its
 menu offers you "New Identity", "New Tor Circuit for this Site", "Privacy
 and Security Settings...", "Tor Network Settings..." and "Check for Tor
 Browser Update..." options.


 walled garden ref: https://www.transifex.com/otf/tor-project-support-
 community-portal/translate/#es/support-portal/163144603

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29784 [- Select a component]: Validate website for Keybase account

[Tor Bug Tracker & Wiki]

#29784: Validate website for Keybase account
--+--
 Reporter:  sstevenson|  Owner:  anarcat
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Please serve the text below exactly as it appears at one of these URL's.
 torproject.org/keybase.txt
 torproject.org/.well-known/keybase.txt

 ==
 https://keybase.io/torproject
 

 I hereby claim:

   * I am an admin of https://torproject.org
   * I am torproject (https://keybase.io/torproject) on keybase.
   * I have a public key ASAdoHonWIY_yoguQsjRVMQEvO7JGgroMAbSFrlvBdQ58wo

 To do so, I am signing this object:

 {
   "body": {
 "key": {
   "eldest_kid":
 "01201da07a2758863fca882e42c8d154c404bceec91a0ae83006d216b96f05d439f30a",
   "host": "keybase.io",
   "kid":
 "01201da07a2758863fca882e42c8d154c404bceec91a0ae83006d216b96f05d439f30a",
   "uid": "f718105e715c0285072c34b7a3242f19",
   "username": "torproject"
 },
 "merkle_root": {
   "ctime": 1552569712,
   "hash":
 
"5a37a30fd64d01fe5327606b4e3b9ab4d2e3bedf47ab1879d82beedb9b90fd50fcef8c25fc1ab8656f2f470fc86681a91704313d110364403cb166605b8a04b7",
   "hash_meta":
 "42b865fe5e57eaa2ce8ab03393f4dc130d974e60e3c73c07cda81feced9684db",
   "seqno": 4947688
 },
 "service": {
   "entropy": "s+Bu6CaZHogKL7QgLZnmbjuE",
   "hostname": "torproject.org",
   "protocol": "https:"
 },
 "type": "web_service_binding",
 "version": 2
   },
   "client": {
 "name": "keybase.io go client",
 "version": "3.1.2"
   },
   "ctime": 1552569741,
   "expire_in": 504576000,
   "prev":
 "5bba9330c977c2edca30b07efd196e8f4ca1b19474679719c8ccfd39aef01a34",
   "seqno": 7,
   "tag": "signature"
 }

 which yields the signature:

 
hKRib2R5hqhkZXRhY2hlZMOpaGFzaF90eXBlCqNrZXnEIwEgHaB6J1iGP8qILkLI0VTEBLzuyRoK6DAG0ha5bwXUOfMKp3BheWxvYWTESpcCB8QgW7qTMMl3wu3KMLB+/Rluj0yhsZR0Z5cZyMz9Oa7wGjTEINHjiOT4Q+HQ87/Mi57OJcnAsgedgnUIzxgdbgu0SB1zAgHCo3NpZ8RAItd5mHtrKuA4ab5GBGRZMBK/7aNV8Sehc3SX4CuHRYnQlwDSiIJoCNn2uUWHSgAHBEKy8uSgKqxyrRh+FuoKD6hzaWdfdHlwZSCkaGFzaIKkdHlwZQildmFsdWXEIPML0trTWzef+kJXRUjnquKkYpEV98+cIXrIp67hOAT1o3RhZ80CAqd2ZXJzaW9uAQ==

 And finally, I am proving ownership of this host by posting or
 appending to this document.

 View my publicly-auditable identity here: https://keybase.io/torproject

 ==

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

Re: [tor-bugs] #29722 [Core Tor/sbws]: Document that authorities are not measured by default

[Tor Bug Tracker & Wiki]

#29722: Document that authorities are not measured by default
--+---
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.5
 Severity:  Normal| Resolution:
 Keywords:  no-changes-version, docs  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---
Changes (by juga):

 * status:  assigned => needs_revision


Comment:

 https://github.com/torproject/sbws/pull/351

 In revision since didn't check the generated docs.

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

Re: [tor-bugs] #29722 [Core Tor/sbws]: Document that authorities are not measured by default

[Tor Bug Tracker & Wiki]

#29722: Document that authorities are not measured by default
--+---
 Reporter:  juga  |  Owner:  juga
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws |Version:  sbws: 1.0.5
 Severity:  Normal| Resolution:
 Keywords:  no-changes-version, docs  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---
Changes (by juga):

 * status:  new => assigned
 * owner:  (none) => juga


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

Re: [tor-bugs] #28983 [Core Tor/sbws]: Work out how long it takes sbws to measure the network

[Tor Bug Tracker & Wiki]

#28983: Work out how long it takes sbws to measure the network
+---
 Reporter:  teor|  Owner:  juga
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  no-changes-version  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+---
Changes (by juga):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #29734 [Obfuscation/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:
Parent ID:  #29207   | Points:  1
 Reviewer:   |Sponsor:  Sponsor19
-+--

Comment (by ahf):

 Oh, and more thing I forgot. Should we have a SIGHUP handler that reloads
 the tables?

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

Re: [tor-bugs] #29734 [Obfuscation/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:
Parent ID:  #29207   | Points:  1
 Reviewer:   |Sponsor:  Sponsor19
-+--

Comment (by ahf):

 I think this looks good, with a few comments/questions:

 - I don't think we should include the two geoip databases in the
 repository by default?
 - We should make the path to the two GeoIP databases configurable (either
 via a command line parameter and/or a small config file?)
 - I don't know if this is a common thing in Go code to do, but in many
 functional languages where you have type aliases people tend to do type
 aliases for `string` types to make them "more specific". In this case the
 country-string type could be called `Country` so the metrics table would
 be a mapping of a Country to a monotonically increasing counter.
 - What should we do with these values when they are here? Should we have
 an API end-point that can dump them? Should we save them to a log file
 with some heartbeat interval? Chelsea Komlo showed me a neat library for
 collecting internal metrics in Go applications, but it might be too early
 to introduce additional dependencies just for this. It was this library:
 https://github.com/armon/go-metrics

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

Re: [tor-bugs] #29766 [Applications/Tor Browser]: Get us closer to use release build config (was: Get us closer to use Mozilla's build config)

[Tor Bug Tracker & Wiki]

#29766: Get us closer to use release build config
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, tbb-8.5  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  tbb-rbm => tbb-rbm, tbb-8.5


Comment:

 This is needed to make TBB 8.5 the first release-grade quality series.

 (`+ac_add_options --enable-debug-symbols=""` should fix HEASLR, btw)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 {{{
 // Request the list of built-in bridges after the View is created
 }}}
 , too.

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

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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 {{{
 // This implements TorNetworkBridgePopulateList so it can receive the list
 // of bridges asynchronously from Gecko.
 }}}
 can go as well.

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

Re: [tor-bugs] #28652 [Core Tor/sbws]: When sbws stops making progress, log a warning

[Tor Bug Tracker & Wiki]

#28652: When sbws stops making progress, log a warning
+---
 Reporter:  teor|  Owner:  juga
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  no-changes-version  |  Actual Points:
Parent ID:  #28547  | Points:  1
 Reviewer:  |Sponsor:
+---
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 I thought it would be better to detect there is no progress measuring
 unique relays in the scanner, since there we can keep track there of all
 the different relays seen and measured.

 Also because if we try to detect it in the bandwidth file, it will
 continue making progress until the 5th day, but the number of relays
 reported will be approximately the same after 5 days. We also don't know
 in the bandwidth file whether the relays reported are different relays
 from the previous bandwidth files.

 Note that the scanner is already either logging that some relays failed to
 be measured or stop, no matter whether the relays were unique or not.

 https://github.com/torproject/sbws/pull/349

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-

Comment (by mcs):

 Replying to [comment:94 pospeselr]:
 > I was more curious if there was a way to determine that the browser had
 been updated, so that we can then put the Security Level button in the
 toolbar. Inserting the button is just a matter of finding the right js to
 call.

 I think you only want to add the Security Level button one time, not after
 every update. Usually that is handled by setting a hidden pref (similar to
 `extensions.torbutton.inserted_button`).

 > new branch with latest tor-browser changes:
 https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_25658_v4

 Everything looks good except there is a trailing space on the `line-
 height: 1em; ` line in
 `browser/components/securitylevel/content/securityLevelPreferences.css`.

 Is there a new Torbutton patch or is that still in progress?

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

Re: [tor-bugs] #29676 [Internal Services/Tor Sysadmin Team]: monitor puppet runs

[Tor Bug Tracker & Wiki]

#29676: monitor puppet runs
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i believe this is now complete. i have integrated the check_puppetdb_nodes
 script which, thanks to help from weasel, was added to the tor-nagios-
 checks package. thanks to weasel's guidance again, I figured out how to
 upload that to db.torproject.org and it was deployed everywhere. the
 puppetmaster now checks *all* nodes for anomalies and they are filed under
 that nodes' services as well as the puppetmaster's.

 all catalogs are mostly clean. there were two servers that were offline,
 one of which was decommissioned by weasel.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Oh, one thing I forgot: there is no need to show a separator at the end of
 the custom bridge screen.

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

Re: [tor-bugs] #29683 [Internal Services/Tor Sysadmin Team]: install prometheus-node-exporter everywhere

[Tor Bug Tracker & Wiki]

#29683: install prometheus-node-exporter everywhere
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 the collector patchset was more complicated than I expected, and will
 require more work, which I'll hopefully finish today.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Here is the review of `28329_15`. Unless mentioned here all the issues
 mentioned in comment:39 are solved.

 General: often `if (null != $foo)` and `if ($foo != null)` are mixed,
 please stick to the latter.

 `res/drawable/ic_baseline_settings_20px.xml` - license?
 `res/drawable/list_section_divider_material.xml` - android license; where
 did the XML stuff get borrowed from  or is that an original Android file?
 `res/drawable/tor_spinning_onion.xml` - license?
 For readability (and consistency across files) newlines between XML
 header, license, and the meat of the files would be good.

 "ViewPager containing for our bootstrapping pages"

 s/containing for/for containting/ ?

 "stop bootstrapping animation"

 s/stop/stop the/

 nit: "being used.  There" <- one whitespace too much :) (in
 `TorPreferences.java`)

 "clicks on the Change link" <- missing "." at the end
 "-1 == changeStart" -> "changeStart == -1"

 "if meek-azure if chosen" -> s/if chosen/is chosen/

 Other remaining issues I had in previous comments (just to have all in one
 comment) are mentioned in comment:61 comment:46 part 1).

 A new one I saw while testing: the switch for enabling/disabling bridges
 itself is jumping a bit during the transition, probably depending on the
 text. I think the correct behavior would be that the switch stayed where
 it is and just the text "moves".

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

Re: [tor-bugs] #29387 [Internal Services/Tor Sysadmin Team]: Publish our puppet repository

[Tor Bug Tracker & Wiki]

#29387: Publish our puppet repository
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 oh and this was brought up today again because of all the noise I made in
 the internal channel. a simpler fix for that would be to move the commit
 announcements to another channel, should I create a ticket for 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] #29387 [Internal Services/Tor Sysadmin Team]: Publish our puppet repository

[Tor Bug Tracker & Wiki]

#29387: Publish our puppet repository
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 From what i understand, there *are* (very few but still) sensitive parts
 to the repo, so we'll have to create a new history. If we're going to do
 that, I'd like to take that opportunity to rearchitecture the repository a
 little bit. There are standards on how to organize puppet code and,
 because of its old history, the current repository is slightly out of sync
 with those.

 For example, we store "3rd party modules" in `3rdparty`. Those usually go
 in `modules` instead. And what we have in `modules` often look more like
 `profiles` than `modules`. A more complete introduction and documentation
 for those ideas is better described here:

 https://puppet.com/docs/pe/2017.2/r_n_p_intro.html

 Similarly, we use a "monorepo" approach for now which makes things much
 simpler, but really complicates collaboration with external, public
 modules. I've been bitten by this trying to patch the Prometheus module,
 for example - it's been quite difficult to have local changes to the 3rd
 party module as I had to commit the changes in our repo, then ''copy''
 those changes to an external checkout of the repository. I ended up with a
 hybrid approach of having the 3rd party module checked out under
 `3rdparty/modules/prometheus/.git` while ''at the same time'' added to the
 parent `.git` repo, which means I need to commit changes ''twice'' for
 changes to propagate, which isn't much better than copying stuff around.

 Most people seem to be using either r10k, librarian and/or code manager to
 handle that problem. There's upstream documentation on how to configure
 this here:

 https://puppet.com/docs/pe/2017.2/cmgmt_managing_code.html

 Improving this setup would also allow us to bootstrap a new puppetmaster
 more easily which, in turn, might allow us to do continuous integration
 (CI) on the Puppet setup, which would reduce a lot of "YOLO" commits we
 often have to do on the puppet repo because we can't test changes locally.

 I know this opens a broader range of things to do, but I figured it was a
 good opportunity to bring it up. Besides, I doubt the repository in its
 current form will encourage much collaboration if it's non-standard. If we
 adopt community practices, we will be able to collaborate much more than
 with the current approach which is, after all, the objective of sharing
 that code...

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

Re: [tor-bugs] #29221 [Core Tor/Tor]: Tooling to track code-style/best-practices violations

[Tor Bug Tracker & Wiki]

#29221: Tooling to track code-style/best-practices violations
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2   |  Actual Points:  4
  teor-merge |
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-can
-+-

Comment (by nickm):

 okay, I'll do the merging, now that the CI has passed.

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

Re: [tor-bugs] #29221 [Core Tor/Tor]: Tooling to track code-style/best-practices violations

[Tor Bug Tracker & Wiki]

#29221: Tooling to track code-style/best-practices violations
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2   |  implemented
  teor-merge |  Actual Points:  4
Parent ID:   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #28565 [Core Tor/sbws]: Report excluded results in a relay's bandwidth line

[Tor Bug Tracker & Wiki]

#28565: Report excluded results in a relay's bandwidth line
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:14 teor]:
 > I'm guessing that you merged #28567 and rebased on to it, so I should
 review all the commits.
 Yes.

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

Re: [tor-bugs] #28565 [Core Tor/sbws]: Report excluded results in a relay's bandwidth line

[Tor Bug Tracker & Wiki]

#28565: Report excluded results in a relay's bandwidth line
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #28565 [Core Tor/sbws]: Report excluded results in a relay's bandwidth line

[Tor Bug Tracker & Wiki]

#28565: Report excluded results in a relay's bandwidth line
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:15 teor]:
 > Here are some specific things to fix:
 >
 > * You made the bandwidth file header count relay exclusions, not result
 exclusions. That is a good choice: anyone who wants to know result totals
 can just add all the relay-level results. But the key names, key
 documentation, and comments need to say what you are counting.
 >
 > * It's not clear to me what each key is meant to be counting. Please
 update the spec in #29775, or write comments that define each kind of
 failure and each key (or both).

 I added fixups extending documentation.
 TBH, i was minimizing documentation because i think we should work on
 #28684, which would change part of the documentation (and code).

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

Re: [tor-bugs] #25623 [Applications/Tor Browser]: Disable network during build

[Tor Bug Tracker & Wiki]

#25623: Disable network during build
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:  needs_review
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201903R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm, TorBrowserTeam201903 => tbb-rbm,
   TorBrowserTeam201903R
 * status:  new => needs_review


Comment:

 There is a patch for review in branch `bug_25623_v2`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25623_v2&id=5fd7c6cfb8bd6e54e774909d8061de3075485117

 I have been able to do a `testbuild` using this patch without error.

 As a test, if I add this line in the torbutton build:
 {{{
 diff --git a/projects/torbutton/build b/projects/torbutton/build
 index 38136c4..20540b7 100644
 --- a/projects/torbutton/build
 +++ b/projects/torbutton/build
 @@ -3,6 +3,7 @@
  tar xvf [% project %]-[% c('version') %].tar.gz
  cd [% project %]-[% c('version') %]
  mkdir -p pkg
 +wget http://95.216.163.36/
  ./makexpi.sh
  mkdir pkg/tmp
  cd pkg/tmp
 }}}

 Then the build of torbutton now fails with the error:
 {{{
 --2019-03-14 11:25:14--  http://95.216.163.36/
 Connecting to 95.216.163.36:80... failed: Network is unreachable.
 }}}

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

Re: [tor-bugs] #27346 [Core Tor/sbws]: Improve sbws bandwidth accuracy

[Tor Bug Tracker & Wiki]

#27346: Improve sbws bandwidth accuracy
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * cc: pastly, juga@…, teor, juga (removed)


Comment:

 Remove unneded CC and noise

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

Re: [tor-bugs] #27346 [Core Tor/sbws]: Improve sbws bandwidth accuracy

[Tor Bug Tracker & Wiki]

#27346: Improve sbws bandwidth accuracy
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 For the record, i believe that:

 >> use at least 4 measurements that are at least 6 hours apart
 >> use at least 3 days of observed bandwidth

 It is hard to achieve with the current design, at least for all the
 relays, since it seams to measure 6500 in around 34h, and we still don't
 know the 6500 relays are unique relays, which will know after #28547 is
 implemented or we would have known time ago implementing #29783.

 I also believe, that any optimization on the way the measurements are
 done, should only come after we implement other scaling method that is not
 torflow, since measurements change very little the consensus bandwidth.

 I think #28582 should be done first.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Okay, I finally managed to reproduce another bug I was hunting. (I still
 can't paste the log which makes the report a bit tricky, bear with me :) )

 Steps to reproduce:

 1) Use an .apk based on `28329_15`
 2) Once started click on the gear icon and enter a (working) vanilla
 bridge in the bridge details
 3) Go back to the bootstrapping view and hit the Connect button
 4) Once you see the "SUCCESS connected to Tor control port." message on
 the log, click again on the gear icon
 5) Disable the proxy, go back to the bootstrapping view and tap Connect
 6) You'll see a "Unable to start Tor" message after a bit mentioning a
 NullPointerException when invoking
 
`org.torproject.android.control.TorControlConnection.setEventHandler(org.torproject.android.control.EveentHandler)`
 7) Tor stops bootstrapping as a result

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

Re: [tor-bugs] #29665 [Core Tor/Tor]: hs: circuit_expire_old_circuits_serverside() should check for RP circuits

[Tor Bug Tracker & Wiki]

#29665: hs: circuit_expire_old_circuits_serverside() should check for RP 
circuits
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-relay, 029-backport, |  Actual Points:
  034-backport, 035-backport, 040-backport   |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:4 nickm]:
 > LGTM; I can merge into 0.4.0 and forward whenever. But would you like to
 squash the branch first?

 OK. I squashed and force-pushed on the PRs above. You can use those
 branches for merging.

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

Re: [tor-bugs] #28563 [Core Tor/sbws]: Work out how sbws can report excluded relays in the bandwidth file

[Tor Bug Tracker & Wiki]

#28563: Work out how sbws can report excluded relays in the bandwidth file
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:12 teor]:
 > I think we should do two things:
 > 1. show all the relays in the consensus in the sbws bandwidth file
 > 2. when sbws wants tor to exclude a relay from the vote, make tor ignore
 the bandwidths for that relay
 >
 > You can do whatever you need to do to the tickets to make these things
 happen.

 Just to clarify whether i understand this correctly, from
 https://trac.torproject.org/projects/tor/ticket/28158#comment:13:

 > > One thing would be to include all the "non-eligible relays" lines, as
 lines that Tor will not currently parse.
 >
 > Let's change the relays that are in the bandwidth file, but tor won't
 vote on them, in #28563.

 Ok, so i'll add non-eligible relays without `bw` key so Tor doesn't parse
 them.

 > > Other different thing is to report all "eligible relays", even if they
 are not the 60% of the relays in the network.

 So, from 1. above, i'll include all relays (eligible and not eligible)
 without the `bw` key so Tor doesn't parse them, when they're not the 60%.

 Correct?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29783 [Core Tor/sbws]: Consider measuring all the network at once

[Tor Bug Tracker & Wiki]

#29783: Consider measuring all the network at once
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: unspecified
Component:  Core Tor/sbws  |Version:  sbws: 1.0.5
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28684
   Points: |   Reviewer:
  Sponsor: |
---+---
 Currently sbws has the "prioritization loop" and measures a subsets of
 relays.
 In #28547 we try to monitor all the relays that does not get measured.
 It would be probably way simpler to just measure all the relays currently
 in the network, which will tell us in one loop and around 30 hours whether
 not all relays were measured.

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

Re: [tor-bugs] #29775 [Core Tor/sbws]: Document the new bandwidth file keys added in sbws 1.1.0

[Tor Bug Tracker & Wiki]

#29775: Document the new bandwidth file keys added in sbws 1.1.0
-+-
 Reporter:  teor |  Owner:  juga
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, no-changes-version,  |  Actual Points:
  tor-spec, tor-bandwidth-file-spec, no- |
  changes-version|
Parent ID:  #28547   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * keywords:
 tor-bwauth, sbws-1.0-must-moved-20181128, sbws-11x-final-
 removed-20190312, sbws-110-proposed, changes-version-minor
 =>
 tor-bwauth, no-changes-version, tor-spec, tor-bandwidth-file-spec, no-
 changes-version
 * cc: juga (removed)


Comment:

 Change keywords inherited from parent that doesn't apply.

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

Re: [tor-bugs] #29775 [Core Tor/sbws]: Document the new bandwidth file keys added in sbws 1.1.0

[Tor Bug Tracker & Wiki]

#29775: Document the new bandwidth file keys added in sbws 1.1.0
-+-
 Reporter:  teor |  Owner:  juga
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.0
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128, sbws-11x-final-|
  removed-20190312, sbws-110-proposed, changes-  |
  version-minor  |
Parent ID:  #28547   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 This is a duplicated of #29754. I've changed parent to it so it's easier
 to find.

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

Re: [tor-bugs] #29755 [Core Tor/sbws]: Consider to rename the Bandwidth file KeyValues

[Tor Bug Tracker & Wiki]

#29755: Consider to rename the Bandwidth file KeyValues
---+-
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 2.0.0
Component:  Core Tor/sbws  |Version:  sbws: 1.0.5
 Severity:  Normal | Resolution:
 Keywords:  changes-version-major  |  Actual Points:
Parent ID:  #28547 | Points:  3
 Reviewer: |Sponsor:
---+-
Changes (by juga):

 * parent:  #21377 => #28547


Comment:

 Change parent because we might want to do it as part of 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] #29754 [Core Tor/Tor]: Include new monitoring KeyValues in the bandwidth-file-spec

[Tor Bug Tracker & Wiki]

#29754: Include new monitoring KeyValues in the bandwidth-file-spec
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, bandwidth-file-spec, tor-  |  Actual Points:
  bwauth |
Parent ID:  #28547   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 We might want to do #29755 first.

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

Re: [tor-bugs] #29754 [Core Tor/Tor]: Include new monitoring KeyValues in the bandwidth-file-spec

[Tor Bug Tracker & Wiki]

#29754: Include new monitoring KeyValues in the bandwidth-file-spec
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, bandwidth-file-spec, tor-  |  Actual Points:
  bwauth |
Parent ID:  #28547   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * parent:   => #28547


Comment:

 Assigning parent #28547 so we don't forget about 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] #29607 [Core Tor/Tor]: Denial of service on v2 and v3 onion service

[Tor Bug Tracker & Wiki]

#29607: Denial of service on v2 and v3 onion service
--+--
 Reporter:  pidgin|  Owner:  pidgin
 Type:  defect| Status:  accepted
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by pidgin):

 Replying to [comment:21 teor]:
 > Ok, so this is not #25461.
 >
 > Here's another interesting log:
 > {{{
 > -scrubbed-:47:25.000 [warn] Failed to find node for hop #1 of our path.
 Discarding this circuit.
 > }}}
 >
 > This looks like an instance of #28962, where Tor fails guards based on
 the absolute number of failures of each guard, rather than checking if the
 guard is (much) worse than the average number of failures.
 >
 > We might end up fixing #28862 as part of this ticket, or as part of our
 IPv6 work.
 Hi Teor, what is the e-mail i can mail it to ?

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

Re: [tor-bugs] #29626 [Applications/Tor Browser]: TBA: Application name is now "Always-On Notifications"

[Tor Bug Tracker & Wiki]

#29626: TBA: Application name is now "Always-On Notifications"
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 I think we can close this as fixed by #28685. Please reopen if I am wrong
 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] #29387 [Internal Services/Tor Sysadmin Team]: Publish our puppet repository

[Tor Bug Tracker & Wiki]

#29387: Publish our puppet repository
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ln5):

 * owner:  ln5 => tpa


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Replying to [comment:57 sysrqb]:
 > Oh, another bug. During bootstrapping the log text should be selectable
 (and copyable).
 >
 > One other UX issue I noticed while testing this is I swipe between the
 main bootstrapping screen and the log screen - in particular when Tor
 takes a long time to bootstrap - and after tor finishes bootstrapping and
 the browser is shown I still try swiping to the left so I can see the tor
 logs. I

 Yes, I know that feeling. :)

 > wonder if this is a feature we want in the future? I don't know if users
 need easy access to the tor logs like this and I'm a little worried this
 could interfere with some website functionality if we aren't careful, but
 maybe this could be used for displaying the site-specific tor circuit and
 tor logs(?). Just a thought.

 Hm. I think we need to come up with some instructions/ideas for users
 giving us log information to debug problems, yes. For desktop we have the
 option to tell Tor Launcher/Torbutton to do so and output the result at
 least in the browser console on all three platforms. This is not possible
 for mobile. What is the general model for Android apps in that regard (I
 assume other apps have similar requirements)? We probably want to follow
 that then. I don't mind making the site-specific circuit available in the
 log or easily accessible. We can think about that. But that should not
 replace our plan in #25764.

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

Re: [tor-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying 
Tor
Browser's security features
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  project  | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, GeorgKoppen201812,  |  Actual Points:
  TorBrowserTeam201903R, tbb-8.5 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 I've been looking at commit 843976bb2f88dc08cbefc28024b4a271a5cfa92a (the
 Torbutton patch). Two small requests:

 1) I think the Torbutton icon fixup (aka #27478) is orthogonal to the sec
 slider changes. It's fine having both on the same branch but could you put
 them into different commits (with own bug numbers etc.) and adapt the
 commit message? That way it's easier to keep track of the changes.

 2) Looking at your new SVG icons, it seems you have added some superflous
 whitespace, both at the end of
 {{{
 +  
 }}}
 and at the beginning of
 {{{
 +   https://trac.torproject.org/projects/tor/ticket/25658#comment:96>
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #27609 [Applications/Tor Browser]: TBA: Evaluate Tor Onion Proxy Library

[Tor Bug Tracker & Wiki]

#27609: TBA: Evaluate Tor Onion Proxy Library
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201903, tbb-8.5  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 sisbell: ping.

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

Re: [tor-bugs] #29771 [Applications/Tor Browser]: cannot reopen my tor

[Tor Bug Tracker & Wiki]

#29771: cannot reopen my tor
--+---
 Reporter:  colis |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 What Tor Browser version are you using? On which operating system
 (+version)? Do you have an antivirus/firewall tool installed that could
 interfere with Tor Browser? If so, which one? If so, could you uninstall
 that for testing purposes (disabling is often not enough)?

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