Re: [tor-bugs] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 Changes (android-1206)

  * Replaced touch and faketime variables

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by Vort):

 Change `at src/app/main/ntmain.c:301` is also needed.
 0.3.5.5 + patches relay is running now, I will say if something goes
 wrong.

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

Re: [tor-bugs] #28747 [Applications/Tor Browser]: Remove old NoScript related code (needed for dealing with the XPCOM version)

[Tor Bug Tracker & Wiki]

#28747: Remove old NoScript related code (needed for dealing with the XPCOM
version)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-torbutton, GeorgKoppen201812,|  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:  #28745   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks! Merged to `master` (commit
 e0b17e85b5c8924e23653d863b043509a0083bf0).

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

Re: [tor-bugs] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201812, TorBrowserTeam201812|
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:24 boklm]:
 > Replying to [comment:22 gk]:
 > > `bug_26843_v8` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_26843_v8=524a9364ead98593507f8f881cc1aa9764945324)
 has the indentation fixed up (too).
 >
 > This patch looks good to me. I did not merge it yet as the json file for
 60.4.0 is not available yet.

 We have a clear way forward (see previous comments). Thus, taking this
 patch now (commit 524a9364ead98593507f8f881cc1aa9764945324 on `master`) as
 it does not break anything until we bump the esr60 tor-browser branch.

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

Re: [tor-bugs] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201812, TorBrowserTeam201812|
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812R
 => tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812


Comment:

 Replying to [comment:26 boklm]:
 > In `bug_26843_v6`, I added a commit that will get the json file from our
 `tor-browser.git` clone:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_26843_v6=1cffd6ce018e4114fa0e814602d5793646e6b10b
 >
 > To get the json file we use the `exec()` function, which will checkout
 the `git_hash` commit and run the command from there.

 You used `cat browser/locales/l10n-changesets.json` but we should take the
 .json file for now from the mobile directory as the l10n repos and
 revisions are used for Android only at the moment. Thus, `cat
 mobile/locales/l10n-changesets.json`. Otherwise this looks reasonable. I
 still need to test it, though.

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by loskiq):

 Thank you for your answer, but unfortunately it did not help me. First I
 deleted ''/state'' and restarted bridge, then I changed
 ''DataDirectory'' to ''/tmp'', restarted bridge and wrote the necessary
 changes to torrc of client. Client still unable to connect and stuck in
 25%.

 Replying to [comment:11 dcf]:

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

Re: [tor-bugs] #28750 [Applications/Tor Browser]: TBB freezes with Script: chrome://global/content/bindings/notification.xml:74

[Tor Bug Tracker & Wiki]

#28750: TBB freezes with Script:
chrome://global/content/bindings/notification.xml:74
--+--
 Reporter:  bo0od |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bo0od):

 * Attachment "tbbfreezeerror.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

[tor-bugs] #28750 [Applications/Tor Browser]: TBB freezes with Script: chrome://global/content/bindings/notification.xml:74

[Tor Bug Tracker & Wiki]

#28750: TBB freezes with Script:
chrome://global/content/bindings/notification.xml:74
+--
 Reporter:  bo0od   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Major
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 while i was browsing the internet , i used to open multiple taps with
 allowing HTML5 + some JS.

 So while doing that a popup jumped in TBB (check the uploaded image) and
 TBB completely freezes.

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

Re: [tor-bugs] #28747 [Applications/Tor Browser]: Remove old NoScript related code (needed for dealing with the XPCOM version)

[Tor Bug Tracker & Wiki]

#28747: Remove old NoScript related code (needed for dealing with the XPCOM
version)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, GeorgKoppen201812,|  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:  #28745   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by igt0):

 The patch looks good. I tested on Desktop and Mobile and didn't see any
 regression.

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

Re: [tor-bugs] #28748 [Obfuscation/Censorship analysis]: Казахстан

[Tor Bug Tracker & Wiki]

#28748: Казахстан
-+-
 Reporter:  Ridvanz  |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20348   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Hi Ridvanz. What did you try already? Did you try using a bridge?

 https://tb-manual.torproject.org/en-US/circumvention/
 https://tb-manual.torproject.org/en-US/bridges/

 (Русский)
 https://tb-manual.torproject.org/ru/circumvention/
 https://tb-manual.torproject.org/ru/bridges/

 If these steps don't work, I will tell you some more advanced steps to
 try.

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

Re: [tor-bugs] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:9 juga]:
 > > Fix sbws' current tor option parsing code
 >
 > Do we know which possible options an operator might need the
 "extra_lines" for?.
 > We only need them to use the testing network.

 Some operators might want a fixed SOCKSPort.
 Some sbws tors might need custom options to bootstrap in their
 environment.

 We could ask the current operators if they use extra_lines.

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

Re: [tor-bugs] #28741 [Core Tor/sbws]: sbws should send scanner metadata as part of every HTTP request

[Tor Bug Tracker & Wiki]

#28741: sbws should send scanner metadata as part of every HTTP request
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:1 iang]:
 > > Non-standard HTTP headers start with "X-".
 >
 > I thought RFC 6648 deprecated that convention?

 Thanks for letting us know.

 Replying to [ticket:28741 teor]:
 > Here's some things we might want:
 > * software-name: sbws
 > * software-version

 These might be user-agent, unless requests sets its own user agent.

 > * scanner-nickname

 I'm not sure if there is a generic HTTP header for a nickname or other
 client identifier.

 > * scanner-IP-address? (pro: discover users who haven't set nickname,
 con: discover users)

 We should look for a generic HTTP header for the client IP address.
 sbws doesn't guarantee any anonymity, and discovering rogue scanners is
 more important than the risk of malicious servers using the IP address.

 > Assigning to 1.0, because this is vital debugging info.

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

Re: [tor-bugs] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:5 nickm]:
 > Teor: Hm, I don't _think_ that race is possible, but I'm not sure.  Does
 the log make you think that might be what's happening here?

 A race is one option, if both sides are behaving correctly.
 Another option is that one side could be sending the wrong data or hash.

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

Re: [tor-bugs] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:9 sisbell]:
 > On my build machine (ubuntu 18.04), I still see the difference in
 timestamps in the assets folder. So I left the touch command in. I built
 the tor-browser project twice, using the same build of dependent projects.

 You can replace `touch -t '010110'` by `[% c("var/touch") %]` (which
 will use the value from `var/timestamp` to set the timestamp).

 You can also replace `faketime '10-Jan-01 00:00'` by `[% c("var/faketime")
 %]`.

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

Re: [tor-bugs] #28749 [Applications/Tor Browser]: Tor on flash drive won't run on other computers

[Tor Bug Tracker & Wiki]

#28749: Tor on flash drive won't run on other computers
--+--
 Reporter:  pericles  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

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


Comment:

 Hi, thanks for letting us know.
 Someone from the Tor Browser team should be able to help you soon.

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

Re: [tor-bugs] #28748 [Obfuscation/Censorship analysis]: Казахстан

[Tor Bug Tracker & Wiki]

#28748: Казахстан
-+-
 Reporter:  Ridvanz  |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20348   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  (none) => dcf
 * component:  - Select a component => Obfuscation/Censorship analysis
 * parent:   => #20348


Comment:

 Hi, thanks for letting us know.

 This page might help:
 
https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki/CensorshipByCountry/Kazakhstan

 There's a lot of detail in #20348 about things we tried and failed.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mikeperry):

 Ok I did the fixup with the type clarifications. It's at
 https://github.com/mikeperry-tor/tor/tree/adaptive_padding-
 rebased_0.3.6-pr547-squashed still.

 It looks like you've been force-pushing to that PR. The head I used
 (56376125a42de88bd57240551f7a76f5219fc455) is now gone. and I have
 conflicts from my fixup (its extensive due to type renaming -- which is
 why I wanted it done before we switched). It looks like
 56376125a42de88bd57240551f7a76f5219fc455 is
 4bf714c9355254e788db886b0fd7da8cedae0822.

 Might not be able to fix the conflicts until tomorrow. In the future, try
 not to force push (tho that would not have helped the conflicts.. we just
 collided changesets).

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

Re: [tor-bugs] #28744 [Core Tor/Tor]: Update to December GeoIP2 database

[Tor Bug Tracker & Wiki]

#28744: Update to December GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-relay,   |  Actual Points:
  029-backport, 032-backport, 033-backport,  |
  035-must, 035-rc-must, 034-backport,   |
  035-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-client, tor-relay, 029-backport, 032-backport, 033-backport,
 035-must, 034-backport
 =>
 tor-client, tor-relay, 029-backport, 032-backport, 033-backport,
 035-must, 035-rc-must, 034-backport, 035-backport
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.4.0.x-final


Comment:

 New code goes in the latest release, which is now 0.4.0.
 Tagging this as 035-rc-must, but let's do the tags better, so they're less
 confusing.

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

Re: [tor-bugs] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201812, TorBrowserTeam201812R   |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812 =>
 tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812R
 * status:  needs_revision => needs_review


Comment:

 In `bug_26843_v6`, I added a commit that will get the json file from our
 `tor-browser.git` clone:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_26843_v6=1cffd6ce018e4114fa0e814602d5793646e6b10b

 To get the json file we use the `exec()` function, which will checkout the
 `git_hash` commit and run the command from there.

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

[tor-bugs] #28749 [- Select a component]: Tor on flash drive won't run on other computers

[Tor Bug Tracker & Wiki]

#28749: Tor on flash drive won't run on other computers
--+--
 Reporter:  pericles  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:|   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I downloaded tor onto a flash drive using my ACER laptop and it works
 fine. When I try to run it from the same flash drive on my HP laptop it
 won't run and keeps saying 'The proxy server is refusing connections'.

 I'm not a programming whiz so I looked online but the resolutions didn't
 help or I couldn't understand them.

 What other information do you need to help?

 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

[tor-bugs] #28748 [- Select a component]: Казахстан

[Tor Bug Tracker & Wiki]

#28748: Казахстан
-+--
 Reporter:  Ridvanz  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Всем привет. Не могу запустить Тор в Казахстане.
 Hey. I can not control the Tor in Kazakhstan.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 Looks good!

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 I think it looks good with one small detail: we write "Client" a couple of
 places. This changes work for both PT clients and servers.

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

Re: [tor-bugs] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


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

Re: [tor-bugs] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+--
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Merged and deployed to https://snowflake.torproject.org/.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_review


Comment:

 irl, unrelated to the actual colors, can you please review the last two
 commits in my [https://gitweb.torproject.org/user/karsten/metrics-
 web.git/log/?h=task-28353 task-28353 branch]? This branch does not yet
 contain a patch to remove the two obsolete graphs, and we might still want
 to tweak the colors. But it would be good to announce changes now in order
 to start the two-week countdown for making those changes by December 20.
 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] #28695 [Applications/Tor Browser]: Set BRNameMatchingPolicy to "Enforce"

[Tor Bug Tracker & Wiki]

#28695: Set BRNameMatchingPolicy to "Enforce"
-+-
 Reporter:  omg  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security,|  Actual Points:
  TorBrowserTeam201812R, tbb-backport|
Parent ID:  #28707   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => closed
 * keywords:  tbb-security, TorBrowserTeam201812R => tbb-security,
 TorBrowserTeam201812R, tbb-backport
 * resolution:   => fixed


Comment:

 Thanks. Cherry-picked to `tor-browser-60.3.0esr-8.5-1` (commit
 2199c4be11b8f1a71403754ac771c96d507dc0b5). Marking for possible backport.

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

Re: [tor-bugs] #28696 [Applications/Tor Browser]: Changing paths to Gradle dependencies are included in build

[Tor Bug Tracker & Wiki]

#28696: Changing paths to Gradle dependencies are included in build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:  #25164   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 Changes (android-1205)

  * Moved GRADLE_MAVEN_REPOSITORIES into the second IF block and removed
 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] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 Changes (android-1205)

  * No longer move keystore, use full location in jarsigner command
  * Changes to how-to-generate-keystore
  * Comment in tor-browser/config linking back to how-to-generate-
 keystore.txt

 On my build machine (ubuntu 18.04), I still see the difference in
 timestamps in the assets folder. So I left the touch command in. I built
 the tor-browser project twice, using the same build of dependent projects.

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

Re: [tor-bugs] #28747 [Applications/Tor Browser]: Remove old NoScript related code (needed for dealing with the XPCOM version)

[Tor Bug Tracker & Wiki]

#28747: Remove old NoScript related code (needed for dealing with the XPCOM
version)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, GeorgKoppen201812,|  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:  #28745   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-torbutton => tbb-torbutton, GeorgKoppen201812,
 TorBrowserTeam201812R
 * status:  new => needs_review


Comment:

 `bug_28747`
 
(https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_28747=e0b17e85b5c8924e23653d863b043509a0083bf0)
 has a patch for this bug up for review.

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

[tor-bugs] #28747 [Applications/Tor Browser]: Remove old NoScript related code (needed for dealing with the XPCOM version)

[Tor Bug Tracker & Wiki]

#28747: Remove old NoScript related code (needed for dealing with the XPCOM
version)
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-torbutton
Actual Points:|  Parent ID:  #28745
   Points:|   Reviewer:
  Sponsor:|
--+---
 After switching to the new, WebExtensions-based NoScript there is unused
 code left in Torbutton dealing with the old XPCOM version. We should
 remove 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] #27290 [Applications/Tor Browser]: WebGL is broken in Tor Browser 8

[Tor Bug Tracker & Wiki]

#27290: WebGL is broken in Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-8.0-issues, tbb-   |  Actual Points:
  regression, TorBrowserTeam201812R, tbb-|
  backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:12 omg]:
 > Obviously,
 > {{{
 >  pref("webgl.disable-fail-if-major-performance-caveat", true);
 >  pref("webgl.enable-webgl2", false);
 > }}}
 > should be added to Torbutton.

 I agree with the situation being not optimal but I think those prefs
 should not get added to Torbutton. Rather, we should rip out the
 respective Torbutton functions (both
 `torbutton_update_fingerprinting_prefs()` and
 `torbutton_update_isolation_prefs()`) as fingerprinting and linkability
 defenses are not optional. We don't expose those options in the browser UI
 either anymore. I've opened #28746 for that (and #28745 for the parent
 ticket covering the Torbutton clean-up).

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

Re: [tor-bugs] #28745 [Applications/Tor Browser]: THE Torbutton clean-up

[Tor Bug Tracker & Wiki]

#28745: THE Torbutton clean-up
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: igt0 (added)


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

[tor-bugs] #28746 [Applications/Tor Browser]: Remove torbutton_update_isolation_prefs() and torbutton_update_fingerprinting_prefs()

[Tor Bug Tracker & Wiki]

#28746: Remove torbutton_update_isolation_prefs() and
torbutton_update_fingerprinting_prefs()
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-torbutton
Actual Points:|  Parent ID:  #28745
   Points:|   Reviewer:
  Sponsor:|
--+---
 We should not mirror the isolation and fingerprinting prefs in Torbutton.
 Just set them in the browser and that's it. Those options are not exposed
 in the browser UI anymore and if a user wants to mess with them they
 should be on their own.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28745 [Applications/Tor Browser]: THE Torbutton clean-up

[Tor Bug Tracker & Wiki]

#28745: THE Torbutton clean-up
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-torbutton
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 That is the parent ticket for all things Torbutton clean-up, now that we
 included it into `tor-browser`. It's not clear yet how we'll be
 restructuring it but it's clear that a lot of old cruft has to go. This
 will be done in child tickets.

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 Replying to [ticket:28717 loskiq]:
 > {{{
 > Dec 04 10:47:39.000 [notice] Delaying directory fetches: No running
 bridges
 > }}}

 I have seen this error before while testing PTs. I think it is a tor bug.
 I don't know the exact cause, but after a few bridge failures, tor will
 cache the fact that it thinks all bridges are down, and refuse even to try
 connecting to them. See:
  * comment:3:ticket:26891
  * #11301

 My usual workaround is to delete the /state file and restart tor.
 You can also try adding a line like this to your torrc:
 {{{
 DataDirectory tmp-datadir
 }}}
 If that works, then the problem is likely the one I described.

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

Re: [tor-bugs] #28744 [Core Tor/Tor]: Update to December GeoIP2 database

[Tor Bug Tracker & Wiki]

#28744: Update to December GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-relay,   |  Actual Points:
  029-backport, 032-backport, 033-backport,  |
  035-must, 034-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  new => needs_review


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

[tor-bugs] #28744 [Core Tor/Tor]: Update to December GeoIP2 database

[Tor Bug Tracker & Wiki]

#28744: Update to December GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-client, tor-relay,
 Severity:  Normal   |  029-backport, 032-backport, 033-backport,
 |  035-must, 034-backport
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 ​[https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2018-12-05
 My geoip-2018-12-05 branch] contains the updated `geoip` and `geoip6`
 files with IPv4 and IPv6 ranges and is supposed to be merged into
 maint-0.2.9 and other branches that are still maintained.

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

Re: [tor-bugs] #27290 [Applications/Tor Browser]: WebGL is broken in Tor Browser 8

[Tor Bug Tracker & Wiki]

#27290: WebGL is broken in Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, tbb-8.0-issues, tbb-   |  Actual Points:
  regression, TorBrowserTeam201812R, tbb-|
  backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff60-esr, tbb-8.0-issues, tbb-regression,
 TorBrowserTeam201812R =>
 ff60-esr, tbb-8.0-issues, tbb-regression, TorBrowserTeam201812R, tbb-
 backport
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:11 mcs]:
 > r=mcs
 > Both patches look good to me. I also verified that setting
 `webgl.min_capability_mode` to `false` allows WebGL to begin working
 within macOS Tor Browser (I tested with 8.0.3 and 8.5a5).

 Thanks. Merged to Torbutton's `master` (commit
 7d98f3bd4348aa79efe040118763c77c84745173) and to `tor-
 browser-60.3.0esr-8.5-1` (6eadc8186a20298ed6d0469f64586d63bec1cfd1).
 Marking for possible backport.

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

Re: [tor-bugs] #28307 [Core Tor/Tor]: DisableNetwork is set

[Tor Bug Tracker & Wiki]

#28307: DisableNetwork is set
--+--
 Reporter:  Cyber 404 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by dcf):

 {{{
 [NOTICE] DisableNetwork is set.
 }}}

 This is a normal message when running Tor Browser. If everything else
 works, there is no problem.

 Tor Browser sets `DisableNetwork=1` via the control port. It doesn't set
 it in torrc, which is why you didn't see it there.
 https://gitweb.torproject.org/tor-launcher.git/tree/src/components/tl-
 process.js?id=49df74bbb79cec5c5505abe0e174117eb509c9cc#n474
 {{{
   // Start tor with networking disabled if first run or if the
   // "Use Default Bridges of Type" option is turned on.  Networking
 will
   // be enabled after initial settings are chosen or after the default
   // bridge settings have been configured.
   [...]
   if (aForceDisableNetwork ||
 TorLauncherUtil.shouldShowNetworkSettings ||
   defaultBridgeType)
   {
 args.push("DisableNetwork");
 args.push("1");
   }
 }}}

 https://gitweb.torproject.org/tor-launcher.git/tree/src/chrome/content
 /network-settings.js?id=49df74bbb79cec5c5505abe0e174117eb509c9cc#n1892
 {{{
   // Tell tor to disable use of the network; this should stop the
 bootstrap
   // process.
   const kErrorPrefix = "Setting DisableNetwork=1 failed: ";
   try
   {
 let settings = {};
 settings["DisableNetwork"] = true;
 let errObj = {};
 if (!gProtocolSvc.TorSetConfWithReply(settings, errObj))
   TorLauncherLogger.log(5, kErrorPrefix + errObj.details);
   }
   catch(e)
   {
 TorLauncherLogger.log(5, kErrorPrefix + e);
   }
 }}}

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

Re: [tor-bugs] #28521 [Obfuscation/FTE]: fte is not working using default tor browser bridges

[Tor Bug Tracker & Wiki]

#28521: fte is not working using default tor browser bridges
-+---
 Reporter:  boklm|  Owner:  kpdyer
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/FTE  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by dcf):

 Replying to [comment:7 gk]:
 > Replying to [comment:3 dcf]:
 > > I wanted to know the start dates of the outages for Metrics Timeline
 purposes, so I made a graph of OONI tcp_connect tor_bridge_reachability
 measurements.
 > >
 > > Ignore the top line for 192.240.101.106:80 -- that bridge was removed
 in #18976. Of the others,
 > >  * 131.252.210.150:8080 is online
 >
 > How is that measured actually? Because I have tried to use FTE default
 bridges in the last couple of days in Tor Browser and connecting to even
 that one is timing out all the time. Thus, there is currently none of the
 FTE bridges working we ship. Have you tested Tor Browser to reproduce the
 "online" result? Or maybe there is a bug in Tor Browser and that bridge is
 indeed working as it should...

 No, I did not test it in Tor Browser. I'm sorry for giving a misleading
 impression, the tcp_connect test only checks TCP connectivity, not
 anything at the application layer. That's all I meant by "online".

 > Maybe OONI's tcp_connect test does not say that much in this case which
 would be interesting I guess...

 I was interested in knowing how long the bridges had been offline. This
 ticket was the wrong place to do it...

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

Re: [tor-bugs] #28603 [Metrics/Statistics]: OnionPerf vantage points are not comparable

[Tor Bug Tracker & Wiki]

#28603: OnionPerf vantage points are not comparable
+--
 Reporter:  irl |  Owner:  metrics-team
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Great! Pushed and deployed the first commit that announces the change.
 Leaving this ticket in merge_ready for the next two weeks and merging the
 second commit then. 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] #28002 [Applications/Tor Browser]: The precomplete file in en-US Windows installer is incorrect

[Tor Bug Tracker & Wiki]

#28002: The precomplete file in en-US Windows installer is incorrect
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201810R,  |  Actual Points:
  tbb-backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201810R => tbb-rbm,
 TorBrowserTeam201810R, tbb-backported


Comment:

 Replying to [comment:6 boklm]:
 > Replying to [comment:4 boklm]:
 > > So this bug should have no impact.
 >
 > Actually it has no impact when all bundles are generated sequentially.
 With the changes from #27218 however, we generate the en-US bundles and
 all the other locales in parallel, which means that we modify the content
 of `${TB_STAGE_DIR}` while this directory can potentially be copied to
 start the generation of an other locale.

 Backported for `maint-8.0` (commit
 5c41fd90b0badbb79e37441bfd7a2a19ff42d0ca).

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

Re: [tor-bugs] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+--
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 Replying to [comment:2 dcf]:
 > ok?

 sure, lgtm

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

Re: [tor-bugs] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  GeorgKoppen201812, TorBrowserTeam201812|
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812R
 => tbb-mobile, TBA-a2, GeorgKoppen201812, TorBrowserTeam201812


Comment:

 Alright I got some answers back. The location where we currently get the
 JSON file from is only updated for builds that actually ship. But we can
 do better here. There seems to be in-tree JSON files we can (and should)
 use instead, e.g. https://hg.mozilla.org/releases/mozilla-esr60/raw-
 file/tip/browser/locales/l10n-changesets.json or
 https://hg.mozilla.org/releases/mozilla-esr60/raw-file/tip/mobile/locales
 /l10n-changesets.json. Or, if we want to have a particular tag we could
 use something like https://hg.mozilla.org/releases/mozilla-esr60/raw-
 file/FIREFOX_60_4_0esr_BUILD2/browser/locales/l10n-changesets.json
 instead.

 I think we don't use the specific tag but just what the branch we build
 from currently has.

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

Re: [tor-bugs] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+--
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 ok?

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

Re: [tor-bugs] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * Attachment "0001-Bug-28727-remove-broker-and-relay-query-string-
 param.patch" added.


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

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_revision


Comment:

 Hi!  I've got some requests in the branch.  I don't know if the windows
 code works or not, but if it's well-tested both manually and with
 automated tests, I'll believe it.

 I had thought that we'd be doing multiple threads here to make the windows
 code work.  I think that might be our only way around a timer.  Having
 timers that bypass the periodic timer system risks undoing a bunch of our
 work for wakeup reduction, unless we are super careful.

 For the spec: I think we need to request more structure from these log
 messages, or we won't be able to actually do anything automatic based on
 them.  Maybe we could define severity, keyword, suggested-action stuff?

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

Re: [tor-bugs] #28002 [Applications/Tor Browser]: The precomplete file in en-US Windows installer is incorrect

[Tor Bug Tracker & Wiki]

#28002: The precomplete file in en-US Windows installer is incorrect
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201810R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 Replying to [comment:4 boklm]:
 > So this bug should have no impact.

 Actually it has no impact when all bundles are generated sequentially.
 With the changes from #27218 however, we generate the en-US bundles and
 all the other locales in parallel, which means that we modify the content
 of `${TB_STAGE_DIR}` while this directory can potentially be copied to
 start the generation of an other locale.

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

Re: [tor-bugs] #28727 [Obfuscation/Snowflake]: Remove `broker` and `relay` query string parameters from Snowflake proxy

[Tor Bug Tracker & Wiki]

#28727: Remove `broker` and `relay` query string parameters from Snowflake proxy
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * keywords:   => easy


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

Re: [tor-bugs] #28697 [Applications/Tor Browser]: Our QA and testing .apks are signed with a key per build

[Tor Bug Tracker & Wiki]

#28697: Our QA and testing .apks are signed with a key per build
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201812  |  Actual Points:
Parent ID:  #25164| Points:
 Reviewer:|Sponsor:
--+

Comment (by sisbell):

 Replying to [comment:6 gk]:

 > {{{
 > -
 > +mv $rootdir/[% c('input_files_by_name/keystore') %] .
 > +
 > }}}
 > contains a trailing whitespace at the end of the last line. Please
 remove that one.
 >
 > Why do we need to touch the extensions here? There were no differences
 in that regard when looking at the 8.5a5 diff of boklm's and my .apk.
 >

 When I ran diffoscope on the apks, it was flagging the timestamp as
 different. I'll do some more testing on this

 {{{
 │ --rw 1.0 fat0 bx stor 18-Dec-04 06:21
 assets/distribution/extensions/
 │ --rw 2.0 fat   486514 bX defN 18-Dec-04 06:20
 assets/distribution/extensions/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
 │ --rw 2.0 fat  1766322 bX defN 18-Dec-04 06:20
 assets/distribution/extensions/https-everywhere-...@eff.org.xpi
 │ +-rw 1.0 fat0 bx stor 18-Dec-04 06:49
 assets/distribution/extensions/
 │ +-rw 2.0 fat   486514 bX defN 18-Dec-04 06:48
 assets/distribution/extensions/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
 │ +-rw 2.0 fat  1766322 bX defN 18-Dec-04 06:48
 assets/distribution/extensions/https-everywhere-...@eff.org.xpi

 }}}

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

Re: [tor-bugs] #28726 [Obfuscation/Snowflake]: Loosen restrictions on message sizes in WebSocket server

[Tor Bug Tracker & Wiki]

#28726: Loosen restrictions on message sizes in WebSocket server
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 I ran a browser proxy for a day and a half, with a patch to keep track of
 the size of WebSocket messages it was sending. I only got 5 or 6 sessions,
 but I didn't see any sends bigger than 32 KB. And messages that big only
 happened once the session was pretty well established, not at the
 beginning during bootstrapping. (Which makes sense, because the client
 doesn't upload much during bootstrapping.)

 So while we could probably benefit from raising the limit a little, it
 doesn't seem so constraining that it would cause bootstrapping errors most
 of the time. Maybe a faster or slower network would have different
 buffering behavior and give different results, though.

 {{{
 new max message size 3656

 new max message size 5227

 new max message size 4077

 new max message size 7283

 new max message size 11909
 new max message size 23940
 new max message size 25418
 new max message size 32768
 }}}

 Here is the patch I used (applied on top of #28732 patches):
 {{{#!patch
 --- a/proxy/proxypair.coffee
 +++ b/proxy/proxypair.coffee
 @@ -21,6 +21,7 @@ class ProxyPair
flush_timeout_id: null
onCleanup:   null
id:  null
 +  max_message_size: 0

###
Constructs a ProxyPair where:
 @@ -134,6 +135,9 @@ class ProxyPair
onClientToRelayMessage: (msg) =>
  if DEBUG
log 'WebRTC --> websocket data: ' + msg.data.byteLength + ' bytes'
 +if msg.data.byteLength > @max_message_size
 +  @max_message_size = msg.data.byteLength
 +  log 'new max message size ' + @max_message_size
  @c2rSchedule.push msg.data
  @flush()

 }}}

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

Re: [tor-bugs] #28603 [Metrics/Statistics]: OnionPerf vantage points are not comparable

[Tor Bug Tracker & Wiki]

#28603: OnionPerf vantage points are not comparable
+--
 Reporter:  irl |  Owner:  metrics-team
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 This looks good to me.

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

Re: [tor-bugs] #28663 [Core Tor/sbws]: sbws stops accumulating, silently

[Tor Bug Tracker & Wiki]

#28663: sbws stops accumulating, silently
---+---
 Reporter:  stefani|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28639 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by stefani):

 correct, last line was  resultdump.py:544 - handle_result - 
  finished ...

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

Re: [tor-bugs] #27491 [Core Tor/Tor]: Prefer IPv4 or IPv6 based on the number of failures

[Tor Bug Tracker & Wiki]

#27491: Prefer IPv4 or IPv6 based on the number of failures
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PR is here: https://github.com/torproject/tor/pull/566

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

Re: [tor-bugs] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+---

Comment (by juga):

 > Fix sbws' current tor option parsing code

 Do we know which possible options an operator might need the "extra_lines"
 for?.
 We only need them to use the testing network.

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

Re: [tor-bugs] #28417 [Community/Translations]: Translate glossary / browser manual translates 'Circuit' inconsistently

[Tor Bug Tracker & Wiki]

#28417: Translate glossary / browser manual translates 'Circuit' inconsistently
+--
 Reporter:  traumschule |  Owner:  traumschule
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by emmapeel):

 Replying to [comment:6 traumschule]:

 > https://www.transifex.com/otf/torproject/tor-misc-tor-browser-manualpot/
 > > This resource currently is not accepting translations.

 Apologies, we have moved it to https://www.transifex.com/otf/tor-project-
 support-community-portal/tbmanual-contentspot/

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

Re: [tor-bugs] #26433 [Webpages/Blog]: Fix blog lead image compression

[Tor Bug Tracker & Wiki]

#26433: Fix blog lead image compression
---+
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by hellais):

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


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

Re: [tor-bugs] #26433 [Webpages/Blog]: Fix blog lead image compression

[Tor Bug Tracker & Wiki]

#26433: Fix blog lead image compression
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hellais):

 Hiro helped me look into fixing this.

 We made the following changes to /config/media/image-styles:

 Full Width

 From:
 Scale width 500
 Image Quality 75%

 To:

 Convert PNG
 Scale width 847
 Retinafied


 Full Width (Retina)

 From:
 Scale width 500
 Image Quality 75%
 Convert PNG

 Retinafied

 To:

 Convert PNG
 Scale width 847
 Retinafied


 I don't really fully understand how and when the "Retina" style gets
 applied, but if it's not used anywhere it can maybe be dropped.

 It seems like images that were already big enough to be resampled have be
 scaled (ex. https://blog.torproject.org/strength-numbers-community-key),
 but others need to be reuploaded.

 My suggestion is that for every picture used in the lead, you upload a
 picture that is at least 1700px wide.

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

Re: [tor-bugs] #28738 [Core Tor/sbws]: Stop merging multiple torrc options with the same name

[Tor Bug Tracker & Wiki]

#28738: Stop merging multiple torrc options with the same name
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Replying to [comment:8 teor]:

 [..]
 > > Even if only stem.py uses these options, i think they should be in
 globals.py, since we might need to change them and globals.py should be
 the place where to change sbws defaults.
 >
 > Let's leave any refactoring until #28737.

 This would not change any functionality, but ok.

 [...]
 > Why write a parser, when tor will parse lines for us?

 There's not any way to pass torrc options to stem using torrc syntax, only
 dictionaries.

 > Option 4 is #28737, and it should work reasonably well. But it's a new
 feature, so it belongs in sbws 1.1.

 If i understand correctly this ticket, all the options would be in the
 form of dictionaries?

 > Here's another option:
 >
 > 5. Fix sbws' current tor option parsing code:
 >   * allow options with no argument (#28715)
 >   * stop trying to merge sbws options with the same name (#28738), until
 we refactor in sbws 1.1 (#28737)

 And not support "extra_lines" until 1.1?.
 I only need them for the test network. Do we have reasons why operators
 might need them?.

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

Re: [tor-bugs] #27402 [Core Tor/Tor]: stop reporting "internal paths" during bootstrap

[Tor Bug Tracker & Wiki]

#27402: stop reporting "internal paths" during bootstrap
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  s8-bootstrap, tor-spec,  |  Actual Points:  0.1
  035-deferred-20180930  |
Parent ID:  #28018   | Points:  0.1
 Reviewer:  nickm|Sponsor:
 |  Sponsor8-can
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 This branch LGTM; please let me know if I should merge it now or as part
 of a larger thing.

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

Re: [tor-bugs] #28104 [Applications/Tor Browser]: Backport Android security fixes for Tor Browser for Android 1.0a3

[Tor Bug Tracker & Wiki]

#28104: Backport Android security fixes for Tor Browser for Android 1.0a3
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201810R,   |  Actual Points:
  GeorgKoppen201810  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by pili):

 * sponsor:   => Sponsor8


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

Re: [tor-bugs] #28649 [Core Tor/sbws]: Provide an example destination URL

[Tor Bug Tracker & Wiki]

#28649: Provide an example destination URL
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 LGTM

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

Re: [tor-bugs] #28648 [Core Tor/sbws]: Broken links in DEPLOY.rst

[Tor Bug Tracker & Wiki]

#28648: Broken links in DEPLOY.rst
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 LGTM

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 New suggestion with light blue, green, and yellow:

 [[Image(bandwidth-flags-2018-12-05.png, 600px)]]

 Context: I usually avoid using yellow as chart color, because it works
 terribly in line charts. But I think it works okay in a stacked area plot
 when surrounded by darker colors. The three colors chosen here also
 satisfy the "two-colors-mixed-together" idea for this graph. And I think
 it works for most types of colorblindness, at least if I interpret the
 result of Coblis, the color blindness simulator, correctly.

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

Re: [tor-bugs] #28741 [Core Tor/sbws]: sbws should send scanner metadata as part of every HTTP request

[Tor Bug Tracker & Wiki]

#28741: sbws should send scanner metadata as part of every HTTP request
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iang):

 > Non-standard HTTP headers start with "X-".

 I thought RFC 6648 deprecated that convention?

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

Re: [tor-bugs] #28725 [Applications/Tor Browser]: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557

[Tor Bug Tracker & Wiki]

#28725: Upgrade go-webrtc to dcbfc825aa33471253a5da1834d499257e05d557
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake tbb-rbm,   |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 FWIW: This is reproducible on my machine.

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

Re: [tor-bugs] #28743 [Core Tor/Tor]: Tinytest library leaks out into non-test codebase

[Tor Bug Tracker & Wiki]

#28743: Tinytest library leaks out into non-test codebase
--+
 Reporter:  karalabe  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by karalabe):

 Tinytest is part of `src/ext` per
 https://gitweb.torproject.org/tor.git/tree/src/ext?h=release-0.3.5 , which
 seems odd given that it's a test utility (why not put it into `src/test`).

 The `tinytest.c` file contains defines `TINYTEST_POSTFORK` in
 
https://gitweb.torproject.org/tor.git/tree/src/ext/tinytest.c?h=release-0.3.5#n28,
 which causes it to add a link dependency for `void tinytest_prefork()` and
 `void tinytest_postfork()` per
 
https://gitweb.torproject.org/tor.git/tree/src/ext/tinytest.c?h=release-0.3.5#n122
 .

 Those methods are defined in `src/test/testing_common.c` per
 
https://gitweb.torproject.org/tor.git/tree/src/test/testing_common.c?h=release-0.3.5#n230
 .

 My annoyance is really with code organization, that a file in a library
 requires stuff defined in a test harness.

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

Re: [tor-bugs] #27102 [Core Tor/Tor]: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum values

[Tor Bug Tracker & Wiki]

#27102: decouple bootstrap progress numbers from BOOTSTRAP_STATUS enum values
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by mcs):

 Replying to [comment:9 catalyst]:
 > Could you please describe what risks you see from having the numbering
 possibly change from one run to another?

 I think it is fine for the numbering to change if the user has modified
 their configuration, e.g., if they added a PT bridge. But I don't think it
 will meet user's expectations if "50% done" means something very different
 the second time bootstrapping occurs vs. the first time. But it isn't
 clear to me what kind of decoupling you are considering, so maybe this is
 not a likely outcome.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_review


Comment:

 If that's the case, then `bug28612` should fix it.  PR at
 https://github.com/torproject/tor/pull/565

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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "bandwidth-flags-2018-12-05.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] #28733 [Core Tor/Tor]: {CONSDIFF} Refusing to apply consensus diff

[Tor Bug Tracker & Wiki]

#28733: {CONSDIFF} Refusing to apply consensus diff
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  consensus |  Actual Points:
Parent ID:  #26310| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Teor: Hm, I don't _think_ that race is possible, but I'm not sure.  Does
 the log make you think that might be what's happening 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] #28619 [Core Tor/Tor]: hs-v3: Do not close RP circuits when deleting an ephemeral service

[Tor Bug Tracker & Wiki]

#28619: hs-v3: Do not close RP circuits when deleting an ephemeral service
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 034-backport, 033-backport,  |  Actual Points:
  035-rc-blocker?|
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.4.x-final


Comment:

 Merged to 0.3.5; if nothing breaks, let's backport.

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

Re: [tor-bugs] #28743 [Core Tor/Tor]: Tinytest library leaks out into non-test codebase

[Tor Bug Tracker & Wiki]

#28743: Tinytest library leaks out into non-test codebase
--+
 Reporter:  karalabe  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Hang on though, the mocking macros aren't part of the tinytest code at
 all.  They're in lib/testsupport.

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

Re: [tor-bugs] #28743 [Core Tor/Tor]: Tinytest library leaks out into non-test codebase

[Tor Bug Tracker & Wiki]

#28743: Tinytest library leaks out into non-test codebase
--+
 Reporter:  karalabe  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * cc: nickm (added)
 * type:  enhancement => defect


Comment:

 Thanks for using Tor, and for reporting this issue.

 Tor depends on tinytest's mocking macros.
 The macros don't do anything in non-test code, but they're still a
 compile-time dependency.
 But it's weird that tinytest refers to src/test. We don't want circular
 dependencies like that.
 nickm wrote tinytest, I'll see if he has any more insight.

 Tor's in-process API is quite new, and we're still testing it.
 If you find any other bugs, please let us know.

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by loskiq):

 * Attachment "tor_bridge.log" added.

 log on bridge

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by loskiq):

 * Attachment "tor_client.log" added.

 log on client

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 The client can connect to your bridge, but your bridge has no descriptor:
 {{{
 Dec 05 17:57:29.000 [info] handle_response_fetch_desc(): Received server
 info (body size 0) from server '54.93.104.200:40635'
 Dec 05 17:57:29.000 [info] handle_response_fetch_desc(): Received http
 status code 404 ("Servers unavailable") from server '54.93.104.200:40635'
 while fetching "/tor/server/authority.z". I'll try again soon.
 }}}

 That's really strange, because your bridge has a descriptor:
 {{{
 Dec 04 09:07:05.000 [notice] Guessed our IP address as 54.93.104.200
 (source: 79.137.112.4).
 Dec 04 09:07:05.000 [notice] Self-testing indicates your ORPort is
 reachable from the outside. Excellent. Publishing server descriptor.
 }}}

 Can you please post the logs from your bridge, *after* you changed the IP
 address and restarted the bridge?

 Can you post info-level logs from your client and bridge, that contain the
 lines that your client and bridge log when the client tries to connect?

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

Re: [tor-bugs] #17962 [Core Tor/Tor]: Cannot connect to Tor

[Tor Bug Tracker & Wiki]

#17962: Cannot connect to Tor
--+---
 Reporter:  talerong  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by nickm):

 * status:  assigned => needs_information
 * milestone:   => Tor: unspecified


Comment:

 Is this still happening with a recent version of Tor?  Can anybody attach
 recent logs?

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by loskiq):

 * Attachment "tor.log" added.

 log on the client

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28743 [Core Tor/Tor]: Tinytest library leaks out into non-test codebase

[Tor Bug Tracker & Wiki]

#28743: Tinytest library leaks out into non-test codebase
-+--
 Reporter:  karalabe |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:   |   Severity:  Trivial
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 This isn't a bug per se, rather a peculiarity in the code organization
 that I've encountered, which I think is accidental. Please correct me if
 I'm wrong.

 I've been trying to wrap the 0.3.5 series of Tor in Go
 (https://github.com/ipsn/go-libtor). It's working properly as far as I can
 tell, just making my final tweaks before pushing it. To keep my wrapper
 small, I've discarded some of the sources that are not relevant for
 building the library, namely `src/tools` and `src/test`.

 To my surprise, my build failed (it worked correctly for 0.3.3), and it
 turned out that the `tinytest` library (at least half of it) is in
 `src/ext`, which refers to the `src/test` folder that I just deleted (the
 test folder refers to tinytest, circular dependency, but that's beyond the
 point here).

 Working around it wasn't too big of a deal, I just ignored the tinytest
 files, but was wondering if this was an accidental leakage of test files
 into the library part, adding a dependency to the tests? Shouldn't the 4
 tinytest files from `src/ext` be moved into `src/test`?

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

[tor-bugs] #28742 [Core Tor/Tor]: When a PT listens on IPv4 and IPv6, tor logs [::]:PORT

[Tor Bug Tracker & Wiki]

#28742: When a PT listens on IPv4 and IPv6, tor logs [::]:PORT
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28717
   Points:|   Reviewer:
  Sponsor:|
--+--
 See:
 https://trac.torproject.org/projects/tor/ticket/28717#comment:7

 This is really confusing.

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Ok, tor has a logging bug.

 And it's still not clear why your client can't connect to your bridge.
 Can you connect to the obfs4 port from your client's IP address?
 Is the bridge line correct?
 Can you collect info-level logs on the client, and post them here.
 (You can redact if you want 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

[tor-bugs] #28741 [Core Tor/sbws]: sbws should send scanner metadata as part of every HTTP request

[Tor Bug Tracker & Wiki]

#28741: sbws should send scanner metadata as part of every HTTP request
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 We can't find out which torflow instances are using a bandwidth server:
 https://lists.torproject.org/pipermail/tor-
 project/2018-December/002108.html

 As far as I can tell, sbws doesn't provide any scanner info in its HTTP
 requests.

 Here's some things we might want:
 * software-name: sbws
 * software-version
 * scanner-nickname
 * scanner-IP-address? (pro: doscover users who haven't set nickname, con:
 discover users)

 Non-standard HTTP headers start with "X-".

 Assigning to 1.0, because this is vital debugging info.

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

Re: [tor-bugs] #28266 [Core Tor/Tor]: Implement proposal 298-canonical-families.txt

[Tor Bug Tracker & Wiki]

#28266: Implement proposal 298-canonical-families.txt
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  prop298   |  Actual Points:  .3
Parent ID:| Points:  1
 Reviewer:  asn   |Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 Merged!

 Also merged the proposal into the spec and closed it as
 54c3a5f09d9634b359344f8155dd973dafe0e86e.

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

Re: [tor-bugs] #27290 [Applications/Tor Browser]: WebGL is broken in Tor Browser 8

[Tor Bug Tracker & Wiki]

#27290: WebGL is broken in Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-8.0-issues, tbb-   |  Actual Points:
  regression, TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by omg):

 Obviously,
 {{{
  pref("webgl.disable-fail-if-major-performance-caveat", true);
  pref("webgl.enable-webgl2", false);
 }}}
 should be added to Torbutton.
 #16473 is left behind the Android release.

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

Re: [tor-bugs] #28695 [Applications/Tor Browser]: Set BRNameMatchingPolicy to "Enforce"

[Tor Bug Tracker & Wiki]

#28695: Set BRNameMatchingPolicy to "Enforce"
-+-
 Reporter:  omg  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201812R  |  Actual Points:
Parent ID:  #28707   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=brade, r=mcs
 The patch looks good.

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

[tor-bugs] #28740 [Applications/Tor Browser]: Make navigator.platform return "Win32", even on Win64 OS

[Tor Bug Tracker & Wiki]

#28740: Make navigator.platform return "Win32", even on Win64 OS
+--
 Reporter:  omg |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 https://bugzilla.mozilla.org/show_bug.cgi?id=1472618

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by loskiq):

 I checked port 40635 on IPv4 via nmap, and it is open. I just changed the
 IP address of my bridge. Sorry. The correct IP address of my bridge is
 54.93.104.200, not 79.103.124.21


 {{{
 loskiq@loskiq-work:~$ nmap 54.93.104.200 -p 40635

 Starting Nmap 7.40 ( https://nmap.org ) at 2018-12-05 17:33 MSK
 Nmap scan report for ec2-54-93-104-200.eu-central-1.compute.amazonaws.com
 (54.93.104.200)
 Host is up (0.070s latency).
 PORT  STATE SERVICE
 40635/tcp open  unknown

 Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds
 }}}

 And I removed the option ''HardwareAccel''. Thanks for this.

 Replying to [comment:7 teor]:

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  prop293, prop275, 040-roadmap-proposed => prop293, prop275,
 040-roadmap-proposed, StaleDesc
 * status:  merge_ready => closed
 * resolution:   => implemented


Comment:

 #28739 is the ticket for the extra tests.

 Main branch squashed and merged.

 d14164d8b9d7bf merges the proposal's changes into dir-spec.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] #27290 [Applications/Tor Browser]: WebGL is broken in Tor Browser 8

[Tor Bug Tracker & Wiki]

#27290: WebGL is broken in Tor Browser 8
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-8.0-issues, tbb-   |  Actual Points:
  regression, TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 r=mcs
 Both patches look good to me. I also verified that setting
 `webgl.min_capability_mode` to `false` allows WebGL to begin working
 within macOS Tor Browser (I tested with 8.0.3 and 8.5a5).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28739 [Core Tor/Tor]: Add more tests for assigning voting flags in test_voting_flags.c

[Tor Bug Tracker & Wiki]

#28739: Add more tests for assigning voting flags in test_voting_flags.c
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  testing, tests, voting
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In test_voting_flags.c we add some tests to make sure that flags are
 assigned the way we want when authorities make votes.  We didn't add tests
 for every flag, though.  We should do that some time.

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

Re: [tor-bugs] #28717 [Core Tor/Tor]: Tor stuck in 25% Loading networkstatus consensus

[Tor Bug Tracker & Wiki]

#28717: Tor stuck in 25% Loading networkstatus consensus
--+--
 Reporter:  loskiq|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 It looks like your obfs4 is only listening on IPv6:
 {{{
 Dec 04 08:12:04.000 [notice] Registered server transport 'obfs4' at
 '[::]:40635'
 }}}

 But your client is configured to connect via IPv4:
 {{{
 Bridge obfs4 79.103.124.21:40635 3E0CFCEE7183970DCC70ABC2D10518BC288BF0DE
 cert=ZzN5WrKqUZCkHYlb8gh0Ew1B5tMgO+oP60jxfar1r3A8yMH/syZ0T3td4x13VbEj1+G4EQ
 iat-mode=0
 }}}

 Unless you changed the IPv4 address to an IPv6 address when you redacted
 it.
 (Please don't change logs without telling us what you changed, it makes
 debugging much harder.)

 Can you check if port 40635 is open on IPv4, IPv6, or both?
 If it's open on IPv4, tor has a logging bug.

 If it's not, you can use ServerTransportListenAddress to set the correct
 address.
 And tor has a default IP version bug.

 Also, you probably don't need this torrc option, it doesn't do anything on
 most systems:
 HardwareAccel 1

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

Re: [tor-bugs] #17065 [Core Tor/Tor]: Tor should leave its own fingerprint out of its family line

[Tor Bug Tracker & Wiki]

#17065: Tor should leave its own fingerprint out of its family line
-+--
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.2.7
 Severity:  Minor| Resolution:  wontfix
 Keywords:  regression, prop298  |  Actual Points:
Parent ID:  #28266   | Points:  small
 Reviewer:   |Sponsor:
-+--
Changes (by nickm):

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


Comment:

 Wontfix in favor of prop298.

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

Re: [tor-bugs] #28737 [Core Tor/sbws]: Redesign sbws torrc option configuration

[Tor Bug Tracker & Wiki]

#28737: Redesign sbws torrc option configuration
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 We should test the torrc options before and after this change, to make
 sure we haven't missed any.

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

Re: [tor-bugs] #28737 [Core Tor/sbws]: Redesign sbws torrc option configuration

[Tor Bug Tracker & Wiki]

#28737: Redesign sbws torrc option configuration
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 We could use defaults-torrc and torrc, but:
 * we would break backwards compatibility
 * tor can't ignore failures in torrc 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] #28692 [Core Tor/sbws]: sbws should set ConnectionPadding 0

[Tor Bug Tracker & Wiki]

#28692: sbws should set ConnectionPadding 0
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  teor   |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:6 juga]:
 > Replying to [comment:4 teor]:
 > [...]
 > > Here's a simpler design:
 > > * a list of torrc options in stem.py,
 >
 > Even if only stem.py uses these options, i think they should be in
 globals.py, since we might need to change them and globals.py should be
 the place where to change sbws defaults.

 Let's leave any refactoring until #28737.

 > > containing 1., 2. and 4., with a flag saying when the option should be
 applied to tor (1. and 2. on launch, 4. after launch)
 > > * a custom list of torrc options that the user can configure for
 launch (same as 3.)
 > >
 > > (There's an even simpler design in #28712 that makes 3. into a torrc
 file, but it's a breaking change.)
 >
 > There isn't a stem torrc syntax parser. This code
 (https://github.com/torproject/sbws/blob/master/sbws/util/stem.py#L157)
 was implementing part of it, it's not complete but was working with well-
 formatted torrc lines.
 > I found that the parser for stem configuration
 (https://stem.torproject.org/api/util/conf.html) is very close to what a
 torrc parser would need, yet might not support all the cases
 (https://github.com/torproject/tor/blob/master/doc/torrc_format.txt).

 Why write a parser, when tor will parse lines for us?

 > Options:
 > 1. we use stem.util.conf, let tor launch fail when options can't be
 parsed and inform the operator
 > 2. we extend stem.util.conf to become a torrc parser
 > 3. we implement a full torrc parser
 > 4. we accept torrc options only in the form of an INI file, which would
 be parsed by ConfigParser and converted to the stem's torrc dictionary
 (i'm not sure which cases might fail here either)

 Option 4 is #28737, and it should work reasonably well. But it's a new
 feature, so it belongs in sbws 1.1.

 Here's another option:

 5. Fix sbws' current tor option parsing code:
   * allow options with no argument (#28715)
   * stop trying to merge sbws options with the same name (#28738), until
 we refactor in sbws 1.1 (#28737)
 Then tell the operator if tor doesn't like the options.

 Now the option bugs are dealt with in other tickets, let's talk about this
 ticket.

 Here's a simple algorithm for ignoring failing options:
 1. sbws has OPTIONS, a hard-coded list of options and values, and
 CAN_FAIL, a hard-coded, ordered list of options that are allowed to fail
 2. Try launching tor with OPTIONS
 3. If tor fails to launch:
   * if CAN_FAIL is not empty, remove the first option in CAN_FAIL from
 OPTIONS, and go to step 2
   * otherwise, edit sbws with an error
 4. Log a message with the Tor version, and the CAN_FAIL options that were
 removed from OPTIONS

 Let's put this new code in a new function. launch_tor is already almost
 100 lines long.

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

Re: [tor-bugs] #28012 [Core Tor/Tor]: shellcheck: updateRustDependencies.sh issues

[Tor Bug Tracker & Wiki]

#28012: shellcheck: updateRustDependencies.sh issues
+
 Reporter:  rl1987  |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+
Changes (by nickm):

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


Comment:

 merged to master

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

[tor-bugs] #28738 [Core Tor/sbws]: Stop merging multiple torrc options with the same name

[Tor Bug Tracker & Wiki]

#28738: Stop merging multiple torrc options with the same name
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 If sbws is configured with a default torrc option and an extra torrc
 option with the same name, then it merges the arguments in both options:
 https://gitweb.torproject.org/sbws.git/tree/sbws/util/stem.py#n175

 This is wrong in different ways, depending on the option
 1. "SocksPort auto 9050" is not a valid torrc option, the correct syntax
 is "SocksPort auto\nSocksPort 9050"
 2. "ExitPolicy accept *:80 accept *:443" is not a valid torrc option, the
 correct syntax is "ExitPolicy accept *:80,accept *:443" or "ExitPolicy
 accept *:80\nExitPolicy accept *:443"

 Instead of trying to understand torrc options, sbws should just set them
 all at once, and let Tor sort out the details.
 The stem.control.set_options() function takes a list of options, and
 applies them all at the same time.

 There are a few issues with this approach:
 1. Operators can't override some of sbws' default torrc options (we can
 fix this in #28737)
 2. Some torrc options need to be set after tor has bootstrapped:
   * DisablePredictedCircuits, but we might remove it in #28701
   * LeaveStreamsUnattached, but I think it can be set on the command-line
 3. Some torrc options aren't supported by all tor versions (#28646,
 #28692), so they need to be set at runtime, and allowed to fail

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28737 [Core Tor/sbws]: Redesign sbws torrc option configuration

[Tor Bug Tracker & Wiki]

#28737: Redesign sbws torrc option configuration
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 sbws' torrc option handling is broken.

 Here's a better scheme:
 1. sbws config.default.ini and config.ini contain the following sections:
   * tor.launch_options: a minimal set of options that must be configured
 when tor is launched. The minimal set contains the data directory config,
 control config, and log config. The network is disabled at launch. The
 initial options are:
 {{{
 'DataDirectory': conf.getpath('tor', 'datadir'),
 'PidFile': conf.getpath('tor', 'pid'),
 # Because we need things from full server descriptors (namely for now:
 the
 # bandwidth line)
 'UseMicrodescriptors': '0',

 'ControlSocket': conf.getpath('tor', 'control_socket'),
 # Easier than password authentication
 'CookieAuthentication': '1',

 'Log': [
 'NOTICE file {}'.format(os.path.join(conf.getpath('tor', 'log'),
  'notice.log')),
 ],
 # useful logging options for clients that don't care about anonymity
 'SafeLogging': '0',
 'LogTimeGranularity': '1',
 'ProtocolWarnings': '1',

 'DisableNetwork': '1',
 }}}
   * tor.runtime_options: any other tor options that can be set at runtime.
 The network is enabled at runtime. The initial options are:
 {{{
 # We will find out via the ControlPort and not setting something
 static
 # means a lower chance of conflict
 'SocksPort': 'auto',

 # To avoid path bias warnings
 'UseEntryGuards': '0',

 c.set_conf('__LeaveStreamsUnattached', '1')

 # Things needed to make circuits fail a little faster. We get the
 # circuit_timeout as a string instead of an int on purpose: stem only
 # accepts strings.
 'LearnCircuitBuildTimeout': '0',
 'CircuitBuildTimeout': conf['general']['circuit_timeout'],

 'DisableNetwork': '0',
 }}}
   * Zero or more tor.ignore_failure_options.(group name): tor options that
 are set in groups at runtime, but ignored if they fail. #28692 and #28694
 will add options to this list.

 Options in config.ini override options with the same name in
 sbws.default.ini, with + and / having the same meaning as in a torrc file
 (+ appends, / removes). Tor will make ignore failure options replace
 runtime options, and both replace launch options.

 2. sbws gets its control socket from the launch_options ControlSocket
 option(s)
 3. sbws gets its data directory, pid, log(s), and circuit build timeout
 using GETCONF

 4. For backwards compatibility:
   * if tor.extra_lines is present, it should be applied at launch. sbws'
 option merging code never worked, so we can just append extra_lines to
 launch_options. This shouldn't cause any more issues than the existing
 code.
   * if these sbws options are present in an old config file, synthesise
 the corresponding torrc options. If launch_options is also present, it
 overrides the synthetic options. (sbws' option merging never worked for
 these options.)
 {{{
 'DataDirectory': conf.getpath('tor', 'datadir'),
 'PidFile': conf.getpath('tor', 'pid'),
 'ControlSocket': conf.getpath('tor', 'control_socket'),
 'Log': [
 'NOTICE file {}'.format(os.path.join(conf.getpath('tor',
 'log'),
  'notice.log')),
 ],
 # Things needed to make circuits fail a little faster. We get the
 # circuit_timeout as a string instead of an int on purpose: stem
 only
 # accepts strings.
 'CircuitBuildTimeout': conf['general']['circuit_timeout'],
 }}}

 The final option order is:
 * sbws merges launch_options:
   * synthetic legacy config options from config.default.ini
   * launch_options + extra_lines from config.default.ini
   * synthetic legacy config options from config.ini
   * launch_options + extra_lines from config.ini
 * sbws merges runtime_options from:
   * config.default.ini
   * config.ini
 * sbws merges each group of ignore_failure_options from:
   * config.default.ini
   * config.ini

 sbws launches tor with launch_options, then applies runtime_options, then
 applies each group of ignore_failure_options.

 This is a new feature, so it should go in sbws 1.1.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org