Re: [tor-bugs] #32492 [Applications/Tor Browser]: Unexpected NoScript behavior when security level is pinned using user.js

2019-11-15 Thread Tor Bug Tracker & Wiki
#32492: Unexpected NoScript behavior when security level is pinned using user.js
--+--
 Reporter:  kj|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201912  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pili):

 * keywords:   => TorBrowserTeam201912


Comment:

 Thanks for your comments ma1 we'll try to look into this further next
 month

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

Re: [tor-bugs] #18080 [Applications/Tor Browser]: CORS header 'Access-Control-Allow-Origin' missing

2019-11-15 Thread Tor Bug Tracker & Wiki
#18080: CORS header 'Access-Control-Allow-Origin' missing
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by postcd):

 Hello, i am seeing the error in dev. console of the latest stable and
 alpha (9.5a2) Tor browser when when i submit login form at
 https://login.blockchain.com/#/login

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

Re: [tor-bugs] #32503 [Applications/Tor Browser]: With Startpage.com, Anonymous Mode does not work if Startpage.com is configured to use EU servers

2019-11-15 Thread Tor Bug Tracker & Wiki
#32503: With Startpage.com, Anonymous Mode does not work if Startpage.com is
configured to use EU servers
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by pili):

 I have managed to reproduce this and, checking the tor logs, it seems like
 we are indeed unable to resolve some domain:

 [NOTICE] Have tried resolving or connecting to address '[scrubbed]' at 3
 different places. Giving 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

[tor-bugs] #32504 [Applications/Tor Browser]: Harden our macOS builds

2019-11-15 Thread Tor Bug Tracker & Wiki
#32504: Harden our macOS builds
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security, tbb-sign,
 Severity:  Normal   |  GeorgKoppen201911
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We ship our .dmg files properly notarized since Tor Browser 9 (see:
 #30126). The Hardened Runtime allows us, however, to tighten down our
 application further in general, and with respect to what Mozilla is using
 in particular (we are currently using their production entitlements file).

 This is the parent ticket for different issues that have piled up since
 #30126 got resolved.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32505 [Applications/Tor Browser]: Tighten our rules in our entitelements file for macOS

2019-11-15 Thread Tor Bug Tracker & Wiki
#32505: Tighten our rules in our entitelements file for macOS
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security, tbb-sign,
 Severity:  Normal   |  GeorgKoppen201911
Actual Points:   |  Parent ID:  #32504
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 comment:40:ticket:30126 mentions two possible rules we could tighten in
 our entitelments file:

 com.apple.security.cs.disable-library-validation=false
 com.apple.security.automation.apple-events=false

 The former seems indeed to be a clear winner but I am not sure about the
 latter as we usually don't want to break the expected behavior for users
 installing WebExtensions (even if we don't recommend it).

 We could think about more rules to be tightened while we are at 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

[tor-bugs] #32506 [Applications/Tor Browser]: Move to different entitlements files for parent and child processes

2019-11-15 Thread Tor Bug Tracker & Wiki
#32506: Move to different entitlements files for parent and child processes
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security, tbb-sign,
 Severity:  Normal   |  GeorgKoppen201911
Actual Points:   |  Parent ID:  #32504
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Mozilla started to provide/use different entitlements files for parent and
 child processes to be able to provide a finer-grained ruleset for the
 hardening depending on process type:

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

 We should do the same for Tor Browser.

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

[tor-bugs] #32507 [Applications/Tor Browser]: Move closer to the way Mozilla is signing macOS bundles

2019-11-15 Thread Tor Bug Tracker & Wiki
#32507: Move closer to the way Mozilla is signing macOS bundles
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security, tbb-sign,
 Severity:  Normal   |  GeorgKoppen201911
Actual Points:   |  Parent ID:  #32504
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Mozilla is using a [https://searchfox.org/mozilla-
 esr68/source/security/mac/hardenedruntime/codesign.bash bash script]
 `codesign.bash` for signing macOS bundles. We should go over it and
 include the finer-grained signing (different entitlement files being used
 and sometimes entitlements are not even ready) into our setup.

 (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1593071 for important
 changes to that bash script)

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

Re: [tor-bugs] #32507 [Applications/Tor Browser]: Move closer to the way Mozilla is signing macOS bundles

2019-11-15 Thread Tor Bug Tracker & Wiki
#32507: Move closer to the way Mozilla is signing macOS bundles
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sign,  |  Actual Points:
  GeorgKoppen201911  |
Parent ID:  #32504   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I think a good process could be to do this transition step-wise: first
 using what Mozilla did for ESR68 and including our non-browser pieces (not
 sure how they fit into the place yet). Then building on top of that the
 improvements Mozilla made since then.

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

Re: [tor-bugs] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

2019-11-15 Thread Tor Bug Tracker & Wiki
#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201909  |  Actual Points:  5.5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Replying to [comment:40 ha]:
 > Are the entitlement files Tor plans to use available online somewhere to
 look at?
 >
 > If you're using the Firefox production entitlements as a starting point,
 you might be able to change some rules to be more restrictive.
 >
 > Assuming Tor only loads shared libraries signed by Tor or Apple, you
 should be able to set the disable library validation entitlement[1] to
 false. Firefox needs to load libraries signed by Adobe and Google for
 Flash and Widevine video decoding respectively.
 >
 >   com.apple.security.cs.disable-library-validation=false
 >
 > In Firefox, we had to recently set this[2] to true because some
 WebExtensions using the native message API relied on helper applications
 that use Apple Events. I suspect Tor wouldn't need this and could set the
 entitlement to false.
 >
 >   com.apple.security.automation.apple-events=false
 >
 > 1.
 https://developer.apple.com/documentation/bundleresources/entitlements
 /com_apple_security_cs_disable-library-validation
 > 2.
 https://developer.apple.com/documentation/bundleresources/entitlements
 /com_apple_security_automation_apple-events

 Thanks for those pointers. I've filed a bunch of tickets to harden our
 macOS Tor Browser. Your suggestions will be part of #32505.

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

Re: [tor-bugs] #32503 [Applications/Tor Browser]: With Startpage.com, Anonymous Mode does not work if Startpage.com is configured to use EU servers

2019-11-15 Thread Tor Bug Tracker & Wiki
#32503: With Startpage.com, Anonymous Mode does not work if Startpage.com is
configured to use EU servers
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pili):

 * status:  new => needs_information


Comment:

 Can you try reproducing this in vanilla firefox ESR 68 configured to use
 tor and let us know if you still see the same behaviour?

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

Re: [tor-bugs] #32479 [Applications/Tor Browser]: Consider publishing signatures as .sig instead of .asc

2019-11-15 Thread Tor Bug Tracker & Wiki
#32479: Consider publishing signatures as .sig instead of .asc
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeamTriaged, tbb-rbm,  |  Actual Points:
  tbb-sign   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeamTriaged, tbb-rbm => TorBrowserTeamTriaged, tbb-
 rbm, tbb-sign


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

Re: [tor-bugs] #31294 [Applications/Tor Browser]: Sign Tor Browser releases with an OpenPGP tool that includes Issuer Fingerprint subpackets

2019-11-15 Thread Tor Bug Tracker & Wiki
#31294: Sign Tor Browser releases with an OpenPGP tool that includes Issuer
Fingerprint subpackets
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sign  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-sign


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

Re: [tor-bugs] #31161 [Applications/Tor Browser]: Document usage and setup of Android signing token

2019-11-15 Thread Tor Bug Tracker & Wiki
#31161: Document usage and setup of Android signing token
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  GeorgKoppen201911,   |  Actual Points:
  TorBrowserTeam201911, tbb-sign |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  GeorgKoppen201911, TorBrowserTeam201911 => GeorgKoppen201911,
 TorBrowserTeam201911, tbb-sign


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

Re: [tor-bugs] #32173 [Applications/Tor Browser]: Update signing infrastructure to work with Apple's notarization process

2019-11-15 Thread Tor Bug Tracker & Wiki
#32173: Update signing infrastructure to work with Apple's notarization process
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  GeorgKoppen201911,   |  Actual Points:  1
  TorBrowserTeam201911, tbb-sign |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  GeorgKoppen201911, TorBrowserTeam201911 => GeorgKoppen201911,
 TorBrowserTeam201911, tbb-sign
 * actualpoints:   => 1


Comment:

 Okay, to give an update here. I updated our signing infrastructure so we
 are able to sign builds for the latest macOS as well. Everything seems to
 be working as before. We still need to figure out the proper process for
 taking the new notarization requirement into account. This will be the
 remaining bit for this ticket before updating the release process notes.

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

Re: [tor-bugs] #32471 [Internal Services/Service - lists]: Close tor-lang-es mailing list

2019-11-15 Thread Tor Bug Tracker & Wiki
#32471: Close tor-lang-es mailing list
---+-
 Reporter:  ggus   |  Owner:  qbi
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by boklm):

 * owner:  ggus => qbi
 * component:  Community => Internal Services/Service - lists


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

Re: [tor-bugs] #19407 [Core Tor/Torsocks]: Support FD passing on Unix socket

2019-11-15 Thread Tor Bug Tracker & Wiki
#19407: Support FD passing on Unix socket
---+--
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by paraadam):

 This is a wonderful article. You have given so much info in it. These type
 of articles keeps the user’s interest in the website, and keep on sharing
 more.
 https://www.subscriptionflow.com/

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

Re: [tor-bugs] #32471 [Internal Services/Service - lists]: Close tor-lang-es mailing list

2019-11-15 Thread Tor Bug Tracker & Wiki
#32471: Close tor-lang-es mailing list
---+
 Reporter:  ggus   |  Owner:  qbi
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by qbi):

 * 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

[tor-bugs] #32508 [Applications/Tor Browser]: opening about:preferences#privacy from the security toolbar button leads to adding about:preferences#tor items at the end of about:preferences#privacy

2019-11-15 Thread Tor Bug Tracker & Wiki
#32508: opening about:preferences#privacy from the security toolbar button 
leads to
adding about:preferences#tor items at the end of about:preferences#privacy
--+
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201911
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Someone reported this on the blog:
 https://blog.torproject.org/comment/285516#comment-285516

 Using the icon on the toolbar to change the security level is showing the
 "Privacy & Security" and "Tor" settings in the same pane, while they are
 in two different ones when opening them through the hamburger menu and
 selecting "Preferences".

 I am not sure if it is a bug, or if it is intentional.

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

Re: [tor-bugs] #32508 [Applications/Tor Browser]: opening about:preferences#privacy from the security toolbar button leads to adding about:preferences#tor items at the end of about:preferences#privacy

2019-11-15 Thread Tor Bug Tracker & Wiki
#32508: opening about:preferences#privacy from the security toolbar button 
leads to
adding about:preferences#tor items at the end of about:preferences#privacy
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: pospeselr (added)
 * points:   => 0.5


Comment:

 That's a bug I think.

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

Re: [tor-bugs] #29815 [Applications/Tor Browser]: Sign our macOS bundles on Linux

2019-11-15 Thread Tor Bug Tracker & Wiki
#29815: Sign our macOS bundles on Linux
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-sign  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-rbm => tbb-sign


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

Re: [tor-bugs] #31905 [Applications/Tor Browser]: Sign dmg images (not just their contents)

2019-11-15 Thread Tor Bug Tracker & Wiki
#31905: Sign dmg images (not just their contents)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security, tbb-sign|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  tbb-security, tbb-rbm => tbb-security, tbb-sign


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

Re: [tor-bugs] #31588 [Applications/Tor Browser]: Be smarter about vendoring for Rust projects (was: Be smarter about vendoring for cbindgen)

2019-11-15 Thread Tor Bug Tracker & Wiki
#31588: Be smarter about vendoring for Rust projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #32436 has similar problems. So, let's be more generic and make this
 ticket into getting to a proper vendoring process/strategy.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32509 [Applications/Tor Browser]: Add comment about how the cbindgen-vendor.tar.bz2 got created

2019-11-15 Thread Tor Bug Tracker & Wiki
#32509: Add comment about how the cbindgen-vendor.tar.bz2 got created
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should add a comment about how the cbindgen vendor .bz2 file came into
 place (I forgot to do that in #30490).

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

Re: [tor-bugs] #30320 [Applications/Tor Browser]: Adapt Tor Browser toolchains for Firefox 68 ESR

2019-11-15 Thread Tor Bug Tracker & Wiki
#30320: Adapt Tor Browser toolchains for Firefox 68 ESR
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr,   |  Actual Points:
  GeorgKoppen201908, tbb-9.0-must-alpha, |
  TorBrowserTeam201910   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * status:  reopened => 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] #30490 [Applications/Tor Browser]: Add cbindgen project for building Firefox 68 ESR

2019-11-15 Thread Tor Bug Tracker & Wiki
#30490: Add cbindgen project for building Firefox 68 ESR
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr,   |  Actual Points:
  TorBrowserTeam201908, tbb-9.0-must-nightly,|
  GeorgKoppen201908  |
Parent ID:  #30320   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:9 gk]:
 > Replying to [comment:7 boklm]:
 > > As vendor.tar.gz is pretty big, I think we should move it outside the
 git repository, with something like this:
 > > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=linux_esr68_v5&id=7fdae3db547bc44f3b157d0f23f613f65a9cd0bf
 >
 > Looks good. I cherry-picked that one and squashed the result onto
 `master` (commit a61d68dc37a39d0aca74b273ca2b444fe33a07dc)
 >
 > > I think we should also add some comment explaining how this file was
 created.
 >
 > I agree. I am leaving this ticket open for that comment and I still like
 to get the vendoring result smaller if possible...

 The latter did not happen yet (it could be part of #31588) and the former
 is #32509.

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

Re: [tor-bugs] #30320 [Applications/Tor Browser]: Adapt Tor Browser toolchains for Firefox 68 ESR

2019-11-15 Thread Tor Bug Tracker & Wiki
#30320: Adapt Tor Browser toolchains for Firefox 68 ESR
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr,   |  Actual Points:
  GeorgKoppen201908, tbb-9.0-must-alpha, |
  TorBrowserTeam201910   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

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


Comment:

 Re-opening for Trac stupidness.

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

Re: [tor-bugs] #31588 [Applications/Tor Browser]: Be smarter about vendoring for Rust projects

2019-11-15 Thread Tor Bug Tracker & Wiki
#31588: Be smarter about vendoring for Rust projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 If Mozilla is vendoring most of the rust dependencies we need, I think we
 could generate a tarball from `tor-browser.git/third_party/rust`, and
 include it in the `cbindgen` project, and in other rust projects that we
 build. That way we don't need to manually update a tarball of vendored
 projects.

 If we want to avoid generating a new tarball (which will probably involve
 generating a tarball containing all the firefox tree, extracting it, and
 generating a new tarball from the `third_party/rust` directory only), we
 can re-use the `src-firefox-$version.tar.xz` tarball which we already
 generate.

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

Re: [tor-bugs] #31588 [Applications/Tor Browser]: Be smarter about vendoring for Rust projects

2019-11-15 Thread Tor Bug Tracker & Wiki
#31588: Be smarter about vendoring for Rust projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:2 boklm]:
 > If Mozilla is vendoring most of the rust dependencies we need, I think
 we could generate a tarball from `tor-browser.git/third_party/rust`, and
 include it in the `cbindgen` project, and in other rust projects that we
 build. That way we don't need to manually update a tarball of vendored
 projects.
 >
 > If we want to avoid generating a new tarball (which will probably
 involve generating a tarball containing all the firefox tree, extracting
 it, and generating a new tarball from the `third_party/rust` directory
 only), we can re-use the `src-firefox-$version.tar.xz` tarball which we
 already generate.

 Yeah, I've thought about that. The problem here is, though, those the
 projects in question are external ones which are *not* needed to build
 Mozilla's Rust code. Thus, Mozilla has not vendored them in but has them
 rather as a build dependency. For `cbindgen` we could think about using
 Debian packages at least once we move don't have versions anymore where
 `cbindgen` is not shipped for in a sufficiently recent version. For
 `lucetc` this option is not available.

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

Re: [tor-bugs] #31588 [Applications/Tor Browser]: Be smarter about vendoring for Rust projects

2019-11-15 Thread Tor Bug Tracker & Wiki
#31588: Be smarter about vendoring for Rust projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:3 gk]:
 > Replying to [comment:2 boklm]:
 > > If Mozilla is vendoring most of the rust dependencies we need, I think
 we could generate a tarball from `tor-browser.git/third_party/rust`, and
 include it in the `cbindgen` project, and in other rust projects that we
 build. That way we don't need to manually update a tarball of vendored
 projects.
 > >
 > > If we want to avoid generating a new tarball (which will probably
 involve generating a tarball containing all the firefox tree, extracting
 it, and generating a new tarball from the `third_party/rust` directory
 only), we can re-use the `src-firefox-$version.tar.xz` tarball which we
 already generate.
 >
 > Yeah, I've thought about that. The problem here is, though, those the
 projects in question are external ones which are *not* needed to build
 Mozilla's Rust code. Thus, Mozilla has not vendored them in but has them
 rather as a build dependency. For `cbindgen` we could think about using
 Debian packages at least once we move don't have versions anymore where
 `cbindgen` is not shipped for in a sufficiently recent version. For
 `lucetc` this option is not available.

 Hmm, I don't understand what you mean here. When I look at the content of
 `cbindgen-vendor.tar.bz2`, all the directories included in it are also
 present in `tor-browser.git/third_party/rust`. Or are you talking about
 other projects than cbindgen?

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

Re: [tor-bugs] #31588 [Applications/Tor Browser]: Be smarter about vendoring for Rust projects

2019-11-15 Thread Tor Bug Tracker & Wiki
#31588: Be smarter about vendoring for Rust projects
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:4 boklm]:
 > Replying to [comment:3 gk]:
 > > Replying to [comment:2 boklm]:
 > > > If Mozilla is vendoring most of the rust dependencies we need, I
 think we could generate a tarball from `tor-browser.git/third_party/rust`,
 and include it in the `cbindgen` project, and in other rust projects that
 we build. That way we don't need to manually update a tarball of vendored
 projects.
 > > >
 > > > If we want to avoid generating a new tarball (which will probably
 involve generating a tarball containing all the firefox tree, extracting
 it, and generating a new tarball from the `third_party/rust` directory
 only), we can re-use the `src-firefox-$version.tar.xz` tarball which we
 already generate.
 > >
 > > Yeah, I've thought about that. The problem here is, though, those the
 projects in question are external ones which are *not* needed to build
 Mozilla's Rust code. Thus, Mozilla has not vendored them in but has them
 rather as a build dependency. For `cbindgen` we could think about using
 Debian packages at least once we move don't have versions anymore where
 `cbindgen` is not shipped for in a sufficiently recent version. For
 `lucetc` this option is not available.
 >
 > Hmm, I don't understand what you mean here. When I look at the content
 of `cbindgen-vendor.tar.bz2`, all the directories included in it are also
 present in `tor-browser.git/third_party/rust`. Or are you talking about
 other projects than cbindgen?

 I am talking right now about `cbindgen` and `lucetc`. But the specific
 `third_party/rust` part I had in mind is only applying to the former.

 Yes, the packages are there but not all the versions are the same as
 `cargo vendor` gives us. This, the risk is high that either compilation
 fails or some other weird behavior would happen. If the packages available
 *and* the versions they are in matched, I agree, using the code from
 `third_party/rust` would work. But, alas, that's not the case.

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

Re: [tor-bugs] #32494 [Applications/Tor Browser]: Add "Send websites a “Do Not Track” signal that you don’t want to be tracked" back to Tor Browser

2019-11-15 Thread Tor Bug Tracker & Wiki
#32494: Add "Send websites a “Do Not Track” signal that you don’t want to be
tracked" back to Tor Browser
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Why is this cypherpunk so oblivious to the fact that the DNT is one giant
 useless piece of trash? Just read the earlier bug tracker where captain
 mikeperry completely demolishes that DNT proposal like a lion eating a
 gazelle.

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

Re: [tor-bugs] #32500 [Core Tor/Tor]: consider clang -std=gnu99 in Travis for better C99 portability

2019-11-15 Thread Tor Bug Tracker & Wiki
#32500: consider clang -std=gnu99 in Travis for better C99 portability
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  portability, tor-ci, 029-backport,   |  Actual Points:  0.2
  035-backport, 040-backport, 041-backport,  |
  042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-

Comment (by nickm):

 Are we doing this with all clang builds, or only some clang builds? I vote
 for "only some", since we may build differently (eg with different
 autoconf results) if we do _not_ have std=gnu99 set.

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

Re: [tor-bugs] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

2019-11-15 Thread Tor Bug Tracker & Wiki
#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 Replying to [comment:12 cohosh]:
 > Hmm, thanks for the update! I'm going to ask a few questions so I can
 try to reproduce this:
 > - How are you measuring your throughput?
 Downloading a test file (could be Tor Browser, Debian ISO, ... doesn't
 matter).

 > - Which version of Windows are you using?
 Windows 10: 18362.476

 > - Which version of Tor Browser are you using?
 Latest alpha.

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

Re: [tor-bugs] #32498 [Applications/Tor Browser]: Consider updating MAR_CHANNEL_ID for nightly build (and maybe alpha too)

2019-11-15 Thread Tor Bug Tracker & Wiki
#32498: Consider updating MAR_CHANNEL_ID for nightly build (and maybe alpha too)
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, boklm201911, tbb-update,|  Actual Points:
  TorBrowserTeam201911   |
Parent ID:  #18867   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Using different MAR channel IDs would prevent the updater from accepting a
 mar file from a different channel (probably better from a security point
 of view). If I remember correctly, doing so would also prevent use of MAR
 tools such as `signmar` across releases. That would probably be OK, but
 might lead to some confusion for developers.

 If we do switch the MAR channel for in our alpha series we need to think
 about how to make the transition. I believe that such a transition will
 require a "watershed" update, but I have not spent a lot of time thinking
 about it.

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

Re: [tor-bugs] #32211 [Core Tor/Tor]: write description of subsystem initialization/shutdown architecture

2019-11-15 Thread Tor Bug Tracker & Wiki
#32211: write description of subsystem initialization/shutdown architecture
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  implemented
  s31-docs   |  Actual Points:  .2
Parent ID:  #29215   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-must
-+-
Changes (by nickm):

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


Comment:

 Okay. I've updated and merged this branch.  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] #32510 [Core Tor/Tor]: Rename .dox files to end with .md, and remove their /** magic **/

2019-11-15 Thread Tor Bug Tracker & Wiki
#32510: Rename .dox files to end with .md, and remove their /** magic **/
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  network-team-roadmap-november,
 Severity:  Normal   |  s31-docs
Actual Points:  0|  Parent ID:  #29214
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor31-can  |
-+-
 I thought that we had to have documentation-only doxygen files wrapped in
 /** and **/.  But we don't: we can just tell doxygen that those files are
 markdown, and it will do the right thing.

 We should make this change so that other tools (like github) that have
 special handling for markdown can pretty-print our markdown files, and so
 that we can eventually incorporate some/all of doc/HACKING into our
 doxygen.

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

Re: [tor-bugs] #32510 [Core Tor/Tor]: Rename .dox files to end with .md, and remove their /** magic **/

2019-11-15 Thread Tor Bug Tracker & Wiki
#32510: Rename .dox files to end with .md, and remove their /** magic **/
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-november,   |  Actual Points:  0
  s31-docs   |
Parent ID:  #29214   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See branch `dox_to_md` with PR at
 https://github.com/torproject/tor/pull/1542

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32511 [Core Tor/Tor]: Add features improving onion services' interaction with Tor.

2019-11-15 Thread Tor Bug Tracker & Wiki
#32511: Add features improving onion services' interaction with Tor.
-+--
 Reporter:  moonsikpark  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.2.4-rc  |   Severity:  Normal
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Tor lacks features allowing onion services' interaction with it, mainly
 because it is a tunneling protocol, not an application layer protocol. I
 think this aspect of Tor should be addressed more.

 I suggest three directives that can improve onion services' interaction
 with Tor.

  1. HiddenServiceExportRendPoint

 With HiddenServiceExportCircuitID and this directive enabled, Tor exports
 IP and port of rendezvous point, along with the circuit ID, to the onion
 service. With this, operators can easily aggregate, analyze and monitor
 their services' rendezvous point connections.

  2. HiddenServiceExportInstanceID

 With HiddenServiceExportCircuitID and this directive enabled, Tor exports
 a user-provided instance ID, along with the circuit ID, to the onion
 service. With this, operators running multiple instances of Tor can
 accurately differentiate traffics with the same circuit ID. Fixes #32428.

  3. HiddenServiceEnableClosingCircuit

 This might be controversial because this feature exclusively targets the
 HTTP application protocol, and I know there are ways to close a circuit
 using the control protocol. But it's nearly impossible and too much error-
 prone to implement it in real environments.

 With this directive enabled, when onion services' backend returns an HTTP
 status code of 447, it marks the circuit to be closed. It's lightweight,
 straightforward and easy to configure.

 I've crudely implemented them. Please feel free to leave ideas or comments
 below.

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

Re: [tor-bugs] #32509 [Applications/Tor Browser]: Add comment about how the cbindgen-vendor.tar.bz2 got created

2019-11-15 Thread Tor Bug Tracker & Wiki
#32509: Add comment about how the cbindgen-vendor.tar.bz2 got created
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201911,   |  Actual Points:
  GeorgKoppen201911  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201911, GeorgKoppen201911
 * points:   => 0.1


Comment:

 `bug_32509` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_32509&id=ead3b276006b68a7eecac3f29f09c1d4df76350c)
 in my public `tor-browser-build` repo has a patch 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

Re: [tor-bugs] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

2019-11-15 Thread Tor Bug Tracker & Wiki
#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 Replying to [comment:13 cypherpunks]:
 > Replying to [comment:12 cohosh]:
 > > Hmm, thanks for the update! I'm going to ask a few questions so I can
 try to reproduce this:
 > > - How are you measuring your throughput?
 > Downloading a test file (could be Tor Browser, Debian ISO, ... doesn't
 matter).
 Are you using Task manager or some other tool to measure the how many kbps
 you get when you download the file? Or are you timing the download
 yourself?

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

Re: [tor-bugs] #32511 [Core Tor/Tor]: Add features improving onion services' interaction with Tor.

2019-11-15 Thread Tor Bug Tracker & Wiki
#32511: Add features improving onion services' interaction with Tor.
--+-
 Reporter:  moonsikpark   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.2.4-rc
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by moonsikpark):

 I've made a pull request. https://github.com/torproject/tor/pull/1543

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

Re: [tor-bugs] #32509 [Applications/Tor Browser]: Add comment about how the cbindgen-vendor.tar.bz2 got created

2019-11-15 Thread Tor Bug Tracker & Wiki
#32509: Add comment about how the cbindgen-vendor.tar.bz2 got created
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201911,   |  Actual Points:
  GeorgKoppen201911  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This looks good to me, thanks. I merged it to master as commit
 `ead3b276006b68a7eecac3f29f09c1d4df76350c`.

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

Re: [tor-bugs] #32510 [Core Tor/Tor]: Rename .dox files to end with .md, and remove their /** magic **/

2019-11-15 Thread Tor Bug Tracker & Wiki
#32510: Rename .dox files to end with .md, and remove their /** magic **/
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-november,   |  Actual Points:  0
  s31-docs   |
Parent ID:  #29214   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
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] #19407 [Core Tor/Torsocks]: Support FD passing on Unix socket

2019-11-15 Thread Tor Bug Tracker & Wiki
#19407: Support FD passing on Unix socket
---+--
 Reporter:  dgoulet|  Owner:  (none)
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ashleymarsh):

 Great information! One should read this post and also subscribe your blog
 for all future post. i have also links of some resources where one can
 find useful information like.
 https://www.saveecoupons.com/

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

Re: [tor-bugs] #32453 [Applications/Tor Browser]: connection no longer available

2019-11-15 Thread Tor Bug Tracker & Wiki
#32453: connection no longer available
--+---
 Reporter:  aldo341   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by aldo341):

 * Attachment "Capture.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] #32453 [Applications/Tor Browser]: connection no longer available

2019-11-15 Thread Tor Bug Tracker & Wiki
#32453: connection no longer available
--+---
 Reporter:  aldo341   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by aldo341):

 * Attachment "Capture2.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] #32453 [Applications/Tor Browser]: connection no longer available

2019-11-15 Thread Tor Bug Tracker & Wiki
#32453: connection no longer available
--+---
 Reporter:  aldo341   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by aldo341):

 In fact I can't open tor at all with the now downloaded version. If I try
 by the icon (file "capture 2"), the message of file "capture" (see
 picutres) appears. I can only close..

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

Re: [tor-bugs] #31890 [Circumvention/meek]: Redeploy meek-server instances using Go 1.12.10+ / 1.13.1+

2019-11-15 Thread Tor Bug Tracker & Wiki
#31890: Redeploy meek-server instances using Go 1.12.10+ / 1.13.1+
+
 Reporter:  dcf |  Owner:  inf0
 Type:  task| Status:  closed
 Priority:  High|  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by phw):

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


Old description:

> https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
> > We have just released Go 1.13.1 and Go 1.12.10 to address a recently
> reported security issue. We recommend that all affected users update to
> one of these releases (if you’re not sure which, choose Go 1.13.1).
> >
> > net/http (through net/textproto) used to accept and normalize invalid
> HTTP/1.1 headers with a space before the colon, in violation of RFC 7230.
> If a Go server is used behind an uncommon reverse proxy that accepts and
> forwards but doesn't normalize such invalid headers, the reverse proxy
> and the server can interpret the headers differently. This can lead to
> filter bypasses or [https://portswigger.net/blog/http-desync-attacks-
> request-smuggling-reborn request smuggling], the latter if requests from
> separate clients are multiplexed onto the same upstream connection by the
> proxy. Such invalid headers are now rejected by Go servers, and passed
> without normalization to Go client applications.
> >
> > The issue is CVE-2019-16276 and Go issue
> https://golang.org/issue/34540.
>
> We need to redeploy the following servers:
>  * cymrubridge02 (backend for meek-azure, run by inf0)
>  * ~~BridgeDB Moat (run by phw)~~
>  * ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
>  * ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
>  * ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~
>
> The Moat configuration uses a reverse proxy, so this is perhaps relevant
> to us.

New description:

 https://groups.google.com/d/msg/golang-announce/cszieYyuL9Q/g4Z7pKaqAgAJ
 > We have just released Go 1.13.1 and Go 1.12.10 to address a recently
 reported security issue. We recommend that all affected users update to
 one of these releases (if you’re not sure which, choose Go 1.13.1).
 >
 > net/http (through net/textproto) used to accept and normalize invalid
 HTTP/1.1 headers with a space before the colon, in violation of RFC 7230.
 If a Go server is used behind an uncommon reverse proxy that accepts and
 forwards but doesn't normalize such invalid headers, the reverse proxy and
 the server can interpret the headers differently. This can lead to filter
 bypasses or [https://portswigger.net/blog/http-desync-attacks-request-
 smuggling-reborn request smuggling], the latter if requests from separate
 clients are multiplexed onto the same upstream connection by the proxy.
 Such invalid headers are now rejected by Go servers, and passed without
 normalization to Go client applications.
 >
 > The issue is CVE-2019-16276 and Go issue https://golang.org/issue/34540.

 We need to redeploy the following servers:
  * ~~cymrubridge02 (backend for meek-azure, run by inf0)~~
  * ~~BridgeDB Moat (run by phw)~~
  * ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
  * ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
  * ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~

 The Moat configuration uses a reverse proxy, so this is perhaps relevant
 to us.

--

Comment:

 Replying to [comment:5 sina]:
 > Redeployed meek-server with updated go:
 > go version go1.13.4 linux/amd64
 [[br]]
 Thanks, Sina! Time to close this ticket.

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

Re: [tor-bugs] #31455 [Circumvention/meek]: Redeploy meek-server instances using Go 1.11.13+ / 1.12.8+

2019-11-15 Thread Tor Bug Tracker & Wiki
#31455: Redeploy meek-server instances using Go 1.11.13+ / 1.12.8+
+
 Reporter:  dcf |  Owner:  sina
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by phw):

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


Old description:

> These versions fix a denial-of-service vulnerability in the HTTP/2 server
> code.
>
> https://groups.google.com/d/msg/golang-announce/65QixT3tcmg/DrFiG6vvCwAJ
> > We have just released Go 1.12.8 and Go 1.11.13 to address recently
> reported security issues. We recommend that all users update to one of
> these releases (if you’re not sure which, choose Go 1.12.8).
> > * net/http: Denial of Service vulnerabilities in the HTTP/2
> implementation
> >
> >   net/http and golang.org/x/net/http2 servers that accept direct
> connections from untrusted clients could be remotely made to allocate an
> unlimited amount of memory, until the program crashes. Servers will now
> close connections if the send queue accumulates too many control
> messages.
> >
> >   The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue
> [https://golang.org/issue/33606 golang.org/issue/33606].
> >
> >   This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of
> golang.org/x/net/http2.
> >
> > * net/url: parsing validation issue
> >
> >   url.Parse would accept URLs with malformed hosts, such that the Host
> field could have arbitrary suffixes that would appear in neither
> Hostname() nor Port(), allowing authorization bypasses in certain
> applications. Note that URLs with invalid, not numeric ports will now
> return an error from url.Parse.
> >
> >   The issue is CVE-2019-14809 and Go issue
> [https://golang.org/issue/29098 golang.org/issue/29098].
>
> We need to redeploy the following servers:
>  * cymrubridge02 (backend for meek-azure, run by inf0)
>  * ~~BridgeDB Moat (run by sysrqb, phw)~~
>  * ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
>  * ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
>  * ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~

New description:

 These versions fix a denial-of-service vulnerability in the HTTP/2 server
 code.

 https://groups.google.com/d/msg/golang-announce/65QixT3tcmg/DrFiG6vvCwAJ
 > We have just released Go 1.12.8 and Go 1.11.13 to address recently
 reported security issues. We recommend that all users update to one of
 these releases (if you’re not sure which, choose Go 1.12.8).
 > * net/http: Denial of Service vulnerabilities in the HTTP/2
 implementation
 >
 >   net/http and golang.org/x/net/http2 servers that accept direct
 connections from untrusted clients could be remotely made to allocate an
 unlimited amount of memory, until the program crashes. Servers will now
 close connections if the send queue accumulates too many control messages.
 >
 >   The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue
 [https://golang.org/issue/33606 golang.org/issue/33606].
 >
 >   This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of
 golang.org/x/net/http2.
 >
 > * net/url: parsing validation issue
 >
 >   url.Parse would accept URLs with malformed hosts, such that the Host
 field could have arbitrary suffixes that would appear in neither
 Hostname() nor Port(), allowing authorization bypasses in certain
 applications. Note that URLs with invalid, not numeric ports will now
 return an error from url.Parse.
 >
 >   The issue is CVE-2019-14809 and Go issue
 [https://golang.org/issue/29098 golang.org/issue/29098].

 We need to redeploy the following servers:
  * ~~cymrubridge02 (backend for meek-azure, run by inf0)~~
  * ~~BridgeDB Moat (run by sysrqb, phw)~~
  * ~~starman (throttled meek.bamsoftware.com, run by dcf)~~
  * ~~maenad (unthrottled meek.bamsoftware.com, run by dcf)~~
  * ~~GAEuploader (gaeuploader.meek.bamsoftware.com, run by dcf)~~

--

Comment:

 [https://trac.torproject.org/projects/tor/ticket/31890#comment:5 Sina
 updated to go1.13.4] so we're all 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] #31971 [Circumvention/Snowflake]: Snowflake is *consistently* extremely slow when using the Windows build

2019-11-15 Thread Tor Bug Tracker & Wiki
#31971: Snowflake is *consistently* extremely slow when using the Windows build
-+---
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:  .5
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 Replying to [comment:14 cohosh]:
 > Are you using Task manager or some other tool to measure the how many
 kbps you get when you download the file? Or are you timing the download
 yourself?
 No, just from the download speed at `about:downloads`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32512 [Applications/Tor Browser]: preference "browser.download.dir" is ignored

2019-11-15 Thread Tor Bug Tracker & Wiki
#32512: preference "browser.download.dir" is ignored
--+--
 Reporter:  Yeti  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Low   |  Component:  Applications/Tor Browser
  Version:|   Severity:  Minor
 Keywords:  download setting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Put this setting in user.js:
 {{{
 user_pref("browser.download.dir", "C:\\Tordownloads");
 }}}
 (or another directory)
 When downloading files, this folder should be selected but it isn't. The
 preference seems to be ignored completely.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32513 [Core Tor/Tor]: Remore extra whitespace in the lines_eq() if statement in consdiff_gen_diff()

2019-11-15 Thread Tor Bug Tracker & Wiki
#32513: Remore extra whitespace in the lines_eq() if statement in
consdiff_gen_diff()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This `if` statement:

 {{{
   if (! lines_eq(line1, line2) ) {
 }}}

 should be:

 {{{
   if (!lines_eq(line1, line2)) {
 }}}

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

Re: [tor-bugs] #32513 [Core Tor/Tor]: Remove the extra whitespace in the lines_eq() if statement in consdiff_gen_diff()

2019-11-15 Thread Tor Bug Tracker & Wiki
#32513: Remove the extra whitespace in the lines_eq() if statement in
consdiff_gen_diff()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #32513 [Core Tor/Tor]: Remove the extra whitespace in the lines_eq() if statement in consdiff_gen_diff() (was: Remore extra whitespace in the lines_eq() if statement in consdiff_gen_dif

2019-11-15 Thread Tor Bug Tracker & Wiki
#32513: Remove the extra whitespace in the lines_eq() if statement in
consdiff_gen_diff()
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by neel):

 PR: https://github.com/torproject/tor/pull/1544

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32514 [Core Tor/Tor]: Remove the extra whitespace around the DARWIN #defines

2019-11-15 Thread Tor Bug Tracker & Wiki
#32514: Remove the extra whitespace around the DARWIN #defines
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Keep in mind that I do not own a Mac, do Hackintosh, or use macOS.

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

Re: [tor-bugs] #32514 [Core Tor/Tor]: Remove the extra whitespace around the DARWIN #defines

2019-11-15 Thread Tor Bug Tracker & Wiki
#32514: Remove the extra whitespace around the DARWIN #defines
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PR: https://github.com/torproject/tor/pull/1545

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

Re: [tor-bugs] #31609 [Core Tor/Tor]: Make CIRCUIT_IS_ORIGIN() look at the base magic number

2019-11-15 Thread Tor Bug Tracker & Wiki
#31609: Make CIRCUIT_IS_ORIGIN() look at the base magic number
+--
 Reporter:  dgoulet |  Owner:  neel
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-circuit, 042-deferred-20190918  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+--
Changes (by neel):

 * status:  new => assigned
 * cc: neel (added)
 * owner:  (none) => neel


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

Re: [tor-bugs] #32501 [Applications/Tor Browser]: Add hasDormantCanceledByStartup to TOPL TorSettings Interface

2019-11-15 Thread Tor Bug Tracker & Wiki
#32501: Add hasDormantCanceledByStartup to TOPL TorSettings Interface
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911R  |  Actual Points:
Parent ID: | Points:  .25
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * keywords:  tbb-mobile, TorBrowserTeam201911 => tbb-mobile,
 TorBrowserTeam201911R
 * status:  new => needs_revision


Comment:

 I added in the implementation for hasDormantCanceledByStartup. The value
 is false by default (but this is overridden to true in tor-android-
 service.

 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/2426b26c9f4563bc8459844ac82a9764cc3e46ae

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

Re: [tor-bugs] #32501 [Applications/Tor Browser]: Add hasDormantCanceledByStartup to TOPL TorSettings Interface

2019-11-15 Thread Tor Bug Tracker & Wiki
#32501: Add hasDormantCanceledByStartup to TOPL TorSettings Interface
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911R  |  Actual Points:
Parent ID: | Points:  .25
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * status:  needs_revision => needs_review


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

[tor-bugs] #32515 [Webpages]: Keep Good Summaries From Reliable Sources. Example: Tor's CODEC Strategy, zlib, lzma, zstd

2019-11-15 Thread Tor Bug Tracker & Wiki
#32515: Keep Good Summaries From Reliable Sources. Example: Tor's CODEC 
Strategy,
zlib, lzma, zstd
--+--
 Reporter:  werd  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Component:  Webpages
  Version:|   Severity:  Normal
 Keywords:  zlib, lzma, zstd  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Ironically, about a week after I spent a bunch of time reading up on zlib,
 lzma, and zstd, on 2019-09-13 someone (Steve Snyder) on the tor-dev list
 asked:
  Given the multiple compression types supported (none, lzma, zlib, zstd),
 what is the order of preference for runtime use?

  Put another way, which compression method(s) should be supported to get
 optimal runtime performance from a Tor node?

 To which Nick Mathewson replied:
  For big objects like consensuses or consensus diffs that are sent over
 and over, relays prefer to use whichever compression method has the
 highest compression -- that's lzma2, then zstd, then zlib, then none.
 Lzma2 (aka xz) is more expensive to calculate, but the relays only need to
 calculate it once per compressed object, and then they can send it over
 and over.

  For smaller objects that are compressed in a stream (descriptors and
 microdescriptors), relays will not use xz, since it would be to expensive
 to recompute it for every stream. They'll prefer zstd, then zlib, then
 none.

  So if you want to save bandwidth above all, you should enable all
 compression algorithms.

  If you want to save CPU above all, you should enable all compression
 algorithms except xz.

  If you want to save bandwidth and CPU, I _think_  enabling all the
 compression algorithms will result in Tor making good choices (as
 described above).  But I'd appreciate benchmarks if anybody has tried it
 both ways to find out.

 This awesome summary, which I'd not gleaned in all my reading, should be
 preserved some place in a hierarchical structure of a builder/developer
 FAQ.

 As you know, by default Tor reports via standard output and logging, the
 compression types compiled into Tor. I wanted to know if it was worth the
 effort to add more than what the current default is.

 There didn't seem a place to put it in the existing structure. Both
 https://2019.www.torproject.org/docs/tor-doc-unix.html.en and
 https://2019.www.torproject.org/docs/tor-doc-osx.html.en are places where
 it makes sense, but best I can tell this raises a few issues: duplicating
 info is not great, those pages are official, and from other pages on
 TorProject.org I've read, those pages are output from some other software.
 And looking at the trac index page
 https://trac.torproject.org/projects/tor/wiki/TitleIndex is overwhelming,
 I'm not sure this awesome tidbit should be yet another page on that list.

 Please excuse me if I placed this under the wrong Type, and also I wasn't
 sure what Subcomponent should be chosen.

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

Re: [tor-bugs] #32512 [Applications/Tor Browser]: preference "browser.download.dir" is ignored

2019-11-15 Thread Tor Bug Tracker & Wiki
#32512: preference "browser.download.dir" is ignored
--+---
 Reporter:  Yeti  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by Thorin):

 * keywords:  download setting =>
 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Because the `.dir` pref is only used based on the value of another pref

 - `browser.download.useDownloadDir` = `false`
- Tor Browser default is false: forces user interaction by always
 asking where to download
 - `browser.download.folderList` = `2`
- 2 = use last used, 1 =  use downloads (default), 0 = use desktop
- **this is the pref you need to also change**
- **this is done for you if you use the UI to set the path**
- about:preferences general > files and application
   * untick always ask where to save
   * set your new path
   * retick always ask where to save
 - `browser.download.dir` = `X:\\what_ever_you_like`

 Worksforme: I set my path via the UI `C:\\Temp` and then rechecked always
 ask where to save, then clicked download (small zip file), and Tor Browser
 went straight to prompting me to save in the correct directory (note: you
 might get a TB prompts about automatically saving downloads, and a FF one
 about opening vs saving: both with options to always remember your
 decision)

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

Re: [tor-bugs] #32510 [Core Tor/Tor]: Rename .dox files to end with .md, and remove their /** magic **/

2019-11-15 Thread Tor Bug Tracker & Wiki
#32510: Rename .dox files to end with .md, and remove their /** magic **/
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-november,   |  implemented
  s31-docs   |  Actual Points:  0
Parent ID:  #29214   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #32209 [Core Tor/Tor]: write description of config subsystem architecture

2019-11-15 Thread Tor Bug Tracker & Wiki
#32209: write description of config subsystem architecture
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  Actual Points:
  s31-docs   |
Parent ID:  #29215   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-

Comment (by nickm):

 See branch `ticket32209`  with PR at
 https://github.com/torproject/tor/pull/1546 . It tries to point the reader
 to the other places in the code that handle configuration and state.

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

Re: [tor-bugs] #32209 [Core Tor/Tor]: write description of config subsystem architecture

2019-11-15 Thread Tor Bug Tracker & Wiki
#32209: write description of config subsystem architecture
-+-
 Reporter:  catalyst |  Owner:  nickm
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  Actual Points:  1
  s31-docs   |
Parent ID:  #29215   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-
Changes (by nickm):

 * status:  assigned => needs_review
 * actualpoints:   => 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

[tor-bugs] #32516 [Applications/Tor Browser]: Make Write Methods Clearer in TorConfigBuilder

2019-11-15 Thread Tor Bug Tracker & Wiki
#32516: Make Write Methods Clearer in TorConfigBuilder
-+-
 Reporter:  sisbell  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile,
 Severity:  Normal   |  TorBrowserTeam201911
Actual Points:   |  Parent ID:
   Points:  .25  |   Reviewer:
  Sponsor:   |
-+-
 Make Write Methods Clearer in TorConfigBuilder. We have a lot of duplicate
 buffer appends that we can cleanup to make code more readable.

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

Re: [tor-bugs] #32516 [Applications/Tor Browser]: Make Write Methods Clearer in TorConfigBuilder

2019-11-15 Thread Tor Bug Tracker & Wiki
#32516: Make Write Methods Clearer in TorConfigBuilder
--+
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911  |  Actual Points:
Parent ID:| Points:  .25
 Reviewer:|Sponsor:
--+
Changes (by sisbell):

 * status:  new => needs_review


Comment:

 Ready for Review. No breaking API changes.

 Changes
 * Added write line and write properties methods and used throughout
 property settings
 * Did a format on the code to clear up previously flag nits
 * I added a write address method. Its currently unused now but will be
 used in subsequent commits

 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/1f95271ae222839797825020a41491ac8aab0d8f

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

Re: [tor-bugs] #32508 [Applications/Tor Browser]: opening about:preferences#privacy from the security toolbar button leads to adding about:preferences#tor items at the end of about:preferences#privacy

2019-11-15 Thread Tor Bug Tracker & Wiki
#32508: opening about:preferences#privacy from the security toolbar button 
leads to
adding about:preferences#tor items at the end of about:preferences#privacy
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201911R |  Actual Points:  0.5
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * keywords:  TorBrowserTeam201911 => TorBrowserTeam201911R
 * status:  new => needs_review
 * actualpoints:   => 0.5


Comment:

 Needed to make all the immediate child elements in the tor preferences xul
 hidden by default. Pushed a fixup commit on the original 31286 patch.

 tor-browser: https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_32508

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

Re: [tor-bugs] #32514 [Core Tor/Tor]: Remove the extra whitespace around the DARWIN #defines

2019-11-15 Thread Tor Bug Tracker & Wiki
#32514: Remove the extra whitespace around the DARWIN #defines
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #32513 [Core Tor/Tor]: Remove the extra whitespace in the lines_eq() if statement in consdiff_gen_diff()

2019-11-15 Thread Tor Bug Tracker & Wiki
#32513: Remove the extra whitespace in the lines_eq() if statement in
consdiff_gen_diff()
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

[tor-bugs] #32517 [Core Tor/Tor]: make check Message After Testsuite Summary

2019-11-15 Thread Tor Bug Tracker & Wiki
#32517: make check Message After Testsuite Summary
-+--
 Reporter:  werd |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.2.4-rc  |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Ever since I started building Tor from source I've noticed something at
 the end of the {{{make check}}} command which puzzled me.

 For the time being I can't dig deeper, but the problem just got worse when
 building Tor 0.4.2.4-rc.

 Here is what I see after the Testsuite summary for tor 0.4.1.6, which
 seems nearly identical to what I've been seeing for the past few versions:
 {{{
 perl ./scripts/maint/checkSpace.pl -C \
 ./src/lib/*/*.[ch] ./src/core/*/*.[ch]
 ./src/feature/*/*.[ch] ./src/app/*/*.[ch] ./src/test/*.[ch]
 ./src/test/*/*.[ch] ./src/tools/*.[ch]
 python ./scripts/maint/checkIncludes.py
 if command -v shellcheck; then \
 find ./scripts/ -name "*.sh" -exec shellcheck {} +; \
 if [ -d "./scripts/test" ]; then \
 shellcheck ./scripts/test/cov-diff
 ./scripts/test/coverage; \
 fi; \
 fi
 }}}

 Now building Tor 0.4.2.4-rc I see this after the Testsuite summary:
 {{{
 perl ./scripts/maint/checkSpace.pl -C \
 ./src/lib/*/*.[ch] ./src/core/*/*.[ch]
 ./src/feature/*/*.[ch] ./src/app/*/*.[ch] ./src/test/*.[ch]
 ./src/test/*/*.[ch] ./src/tools/*.[ch]
 python ./scripts/maint/practracker/includes.py .
 Unusual pattern permitted.h in ./scripts/maint/practracker/testdata
 (warning) problem file-size /src/app/config/or_options_st.h 1121
 (warning) problem file-size /src/core/mainloop/connection.c 5575
 (warning) problem file-size /src/core/or/connection_edge.c 4601
 (warning) problem function-size
 /src/core/or/connection_edge.c:connection_ap_handshake_rewrite() 193
 (warning) problem file-size /src/feature/client/entrynodes.c 3825
 (warning) problem function-size
 /src/feature/control/control_cmd.c:add_onion_helper_keyarg() 117
 (warning) problem function-size
 /src/feature/dircache/dircache.c:directory_handle_command_post() 124
 (warning) problem file-size /src/feature/hs/hs_service.c 4182
 (warning) problem file-size /src/feature/relay/router.c 3524
 (warning) problem function-size
 /src/feature/rend/rendmid.c:rend_mid_establish_intro_legacy() 105
 (warning) problem file-size /src/feature/rend/rendservice.c 4522
 (warning) problem function-size
 /src/feature/rend/rendservice.c:rend_service_receive_introduction() 334
 ./scripts/maint/checkShellScripts.sh
 ./scripts/maint/checkShellScripts.sh: Install shellcheck to check shell
 scripts.
 }}}

 I'm using a Mac.

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

Re: [tor-bugs] #32281 [Internal Services/Tor Sysadmin Team]: set up new IRC box to replace iranicum

2019-11-15 Thread Tor Bug Tracker & Wiki
#32281: set up new IRC box to replace iranicum
-+-
 Reporter:  weasel   |  Owner:  weasel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i added chives to the VM spreadsheet as it was missing from the cluster
 documentation.

 this actually brings the cluster into over-provisionning already,
 unfortunately. it seems we might need a second pair of nodes in that
 cluster before the year is 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

[tor-bugs] #32518 [Applications/Tor Browser]: Fix Addresses/Ports in TorConfigBuilder

2019-11-15 Thread Tor Bug Tracker & Wiki
#32518: Fix Addresses/Ports in TorConfigBuilder
-+-
 Reporter:  sisbell  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile,
 Severity:  Normal   |  TorBrowserTeam201911
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 Port fields are inconsistent. Some are string, some are ints. Uses a
 general address type for these fields that includes: host, port (int or
 "auto").

 This fix included breaking API changes. Include changes in tor-android-
 service that uses the new API but makes it backwards compatible with
 existing android preferences that are used.

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

Re: [tor-bugs] #26878 [Community/Translations]: translation bot publishes incomplete translations on the translation_completed branches

2019-11-15 Thread Tor Bug Tracker & Wiki
#26878: translation bot publishes incomplete translations on the
translation_completed branches
+--
 Reporter:  emmapeel|  Owner:  emmapeel
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by phw):

 * cc: phw (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] #31608 [Core Tor/Tor]: circuit_state_publish() never triggers when a new origin circuit is created

2019-11-15 Thread Tor Bug Tracker & Wiki
#31608: circuit_state_publish() never triggers when a new origin circuit is 
created
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circuit, tor-pubsub, |  Actual Points:
  042-deferred-20190918  |
Parent ID:  #31609   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  new => assigned
 * cc: neel (added)
 * owner:  (none) => neel


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

Re: [tor-bugs] #32476 [Applications/Tor Browser]: Support Launching TorService Using JNI

2019-11-15 Thread Tor Bug Tracker & Wiki
#32476: Support Launching TorService Using JNI
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, |  Actual Points:
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I assume some of the native methods are custom for tor-android so that we
 can run in embedded. If we are using tor from the tor browser build, are
 there any hoops we need to go through to get this integrated?

 Are the native methods only supported on Android or all platforms? I'm
 asking this since TOPL is desktop/mobile so this good info to have for
 planning whether we can continue support across the board.

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

Re: [tor-bugs] #29607 [Core Tor/Tor]: 2019 Q1: Denial of service on v2 and v3 onion service

2019-11-15 Thread Tor Bug Tracker & Wiki
#29607: 2019 Q1: Denial of service on v2 and v3 onion service
-+-
 Reporter:  pidgin   |  Owner:  pidgin
 Type:  defect   | Status:
 |  needs_information
 Priority:  Immediate|  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:
  roadmap-2019-Q1Q2, security, 041-longterm, |
  041-deferred-20190530, 042-deferred-20190918   |
Parent ID:  #2   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by paramond):

 Replying to [comment:64 pidgin]:
 > it's a beautiful sunny day today.

 Pulled down without any notice, that's uncharacteristic.

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

Re: [tor-bugs] #30558 [Applications/Tor Browser]: Namecoin support for onion sites in Tor Browser

2019-11-15 Thread Tor Bug Tracker & Wiki
#30558: Namecoin support for onion sites in Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  JeremyRand
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTesm201911R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by JeremyRand):

 > 2 of the public ElectrumX Namecoin servers are currently down for
 maintenance. Since Namecoin connects to multiple servers simultaneously to
 improve performance, the performance of this patch will be degraded until
 those servers come back online. It still works fine and isn't particularly
 annoying, but there *will* be some higher-than-typical latency while we're
 waiting for those servers to come back online. (It would be awesome if the
 Tor community decides to set up some additional ElectrumX Namecoin
 servers.)

 1 of those 2 servers has completed maintenance and is back online as of
 yesterday, so that should yield a performance bump for anyone testing
 these patches.

 On another note: in the hypothetical event that the patches in this ticket
 pass review and are merged, my recommendation would be to time the merge
 to coincide with a blogpost, so that users of the Nightly builds are
 informed of what the changes are.  Otherwise, there might be unnecessary
 confusion by users who observe a bunch of Namecoin code being merged to
 tor-browser-build (or who observe its presence in the Nightly binaries)
 and aren't sure what the scope of it is (e.g. it's important that users
 know that the code is disabled by default, so that they don't think
 they're being exposed to new attack surface without their opt-in consent).
 I'm happy to contribute to such a blogpost if/when we reach the point
 where it's relevant.  Of course, if you strongly prefer to merge without a
 blogpost and worry about doing a blogpost later, you're welcome to do so.

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

[tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

2019-11-15 Thread Tor Bug Tracker & Wiki
#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 while working on the nextcloud project, we realized it wasn't exactly
 trivial to setup the LDAP bridge because of our specific requirements (no
 direct connexion, offline support). so we just didn't implement it yet
 (#32332). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ retire a user]
 procedure, but then i realized there are probably many other such services
 that do *not* connect with LDAP.

 On the top of my head, there's at least Trac and mailing lists, for
 example, which are managed completely separarely. Audit
 [[org/operations/services]] and see which services are manager manually
 and which aren't.

 Then make sure there's an automated way to add/remove users to services,
 either by hooking up the service with LDAP, or by creating a wrapper
 script that will manage those accesses.

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

Re: [tor-bugs] #32332 [Internal Services/Service - nextcloud]: Set up LDAP authn for nc.tpn

2019-11-15 Thread Tor Bug Tracker & Wiki
#32332: Set up LDAP authn for nc.tpn
-+-
 Reporter:  ln5  |  Owner:
 |  nextcloud-admin@…
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service -  |Version:
  nextcloud  |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #32519   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * parent:   => #32519


Comment:

 note this is a wider problem than just nextcloud, i opened #32519 to cover
 for the other cases.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32520 [Applications/Tor Browser]: Output of go project contains nonreproducible datetime values

2019-11-15 Thread Tor Bug Tracker & Wiki
#32520: Output of go project contains nonreproducible datetime values
+--
 Reporter:  JeremyRand  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Steps to reproduce:

 1. Run `./rbm/rbm build go --target release --target torbrowser-linux-
 x86_64` twice.
 2. Compare the hashes of the results.

 Expected behavior:

 The hashes should be reproducible.

 Observed behavior:

 The hashes are not reproducible.

 Other info:

 I'm attaching a diffoscope.  Most of the nonreproducibility seems to be
 due to datetime values.  I suspect, but have not verified, that these
 datetime values are being inserted by the (currently unmaintained) Go
 1.4.x compiler, and that therefore we can't expect an upstream fix.
 libfaketime seems like the most straightforward way to fix the issue.
 Would a patch be accepted that uses libfaketime to make the datetime
 values in the `go` project's output reproducible?

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

Re: [tor-bugs] #32520 [Applications/Tor Browser]: Output of go project contains nonreproducible datetime values

2019-11-15 Thread Tor Bug Tracker & Wiki
#32520: Output of go project contains nonreproducible datetime values
--+--
 Reporter:  JeremyRand|  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 JeremyRand):

 * Attachment "go-1.12.13-0189d4.tar.gz.diffoscope" 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] #31691 [Applications/Tor Browser]: Go ldflags should set static build ID

2019-11-15 Thread Tor Bug Tracker & Wiki
#31691: Go ldflags should set static build ID
--+--
 Reporter:  JeremyRand|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by JeremyRand):

 > Interesting. I wonder why we have not hit that issue yet.

 I'm not 100% sure why Tor hasn't had problems with it; I can confirm that
 Namecoin is definitely having problems with it when using Tor's rbm
 projects; see https://github.com/namecoin/ncdns-repro/issues/57 .  I can
 think of 2 plausible explanations for this:

 1. Namecoin exercises cgo-related code paths in more interesting ways than
 Tor does, so maybe the build ID happens to be reproducible in Tor's setup
 when not using cgo in the ways that Namecoin does.
 2. Namecoin uses `go install` to build the final binaries, whereas Tor
 uses `go install` only to build libraries and `go build` to build the
 final binaries, so maybe the build ID happens to be reproducible in Tor's
 setup when using `go build`, and possibly either the build ID isn't
 embedded into libraries at all, or no one has checked the libraries for
 reproducibility issues since the final executable output is still
 reproducible.

 That said, the build ID is almost definitely nonreproducible even in Tor's
 usage when comparing rbm-built binaries to non-rbm-built binaries, because
 the build ID is partially dependent on the build path, which is consistent
 inside rbm but won't be consistent elsewhere.  So, fixing this is useful
 to make it easier to audit the reproducibility of Tor's binaries via build
 platforms other than rbm (in addition to the fact that it seems to be
 needed for downstream projects like Namecoin to be reproducible at all,
 for some reason).

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

Re: [tor-bugs] #31691 [Applications/Tor Browser]: Go ldflags should set static build ID

2019-11-15 Thread Tor Bug Tracker & Wiki
#31691: Go ldflags should set static build ID
--+--
 Reporter:  JeremyRand|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by JeremyRand):

 Fixing this is blocked by #30334, as a patch for this ticket would
 probably touch the same code as what's being touched by #30334, so waiting
 for #30334 to be resolved prior to solving this one would avoid merge
 conflicts.

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

Re: [tor-bugs] #30334 [Applications/Tor Browser]: build_go_lib for executables?

2019-11-15 Thread Tor Bug Tracker & Wiki
#30334: build_go_lib for executables?
+--
 Reporter:  JeremyRand  |  Owner:  boklm
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201911R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by JeremyRand):

 I'm not certain whether the patch in this ticket exposes reproducibility
 issues, but if it does, #31691 and #31688 are the most likely culprits.

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