Re: [tor-bugs] #23664 [Applications/Tor Browser]: Deal with UUID for content sandbox temp folder on Windows and Mac

[Tor Bug Tracker & Wiki]

#23664: Deal with UUID for content sandbox temp folder on Windows and Mac
-+--
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-disk-leak  |  Actual Points:
Parent ID:  #23658   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

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

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

Re: [tor-bugs] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Zakhar):

 Replying to [comment:2 arma]:
 > Zakhar: yeah, your self-built tor binary will look at
 /usr/local/etc/tor/torrc.
 >
 > If you want it to use /etc/tor/torrc, you'll need to build it with the
 various build options that the deb uses. (The simpler answer is to just
 use the deb.)

 I am doing so because I need to patch for ipv6 link-local reasons (see my
 other ticket).

 Since I saw this strange behavior after patching, I compiled it without my
 patch to check if this strange thing is stills there and eliminate a side
 effect due to my patching.

 Unfortunately, I am observing the same strange behavior with an "unpatched
 fresh compile".

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

Re: [tor-bugs] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Zakhar):

 Yes '''I have the right config file''', since it is started with systemd
 as show with this ps:

 {{{
 $ ps aux | grep /usr/bin/tor
 debian-+  3729  0.1  0.0  59224 30516 ?Ss   08:08   0:00
 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f
 /etc/tor/torrc --RunAsDaemon 0
 $ /usr/bin/tor --version
 Tor version 0.3.1.8 (git-ad5027f7dc790624).
 $ grep 'MaxCir' /etc/tor/torrc
 MaxCircuitDirtiness 1800
 }}}

 You see here it is tor version 0.3.1.8 which is not supposed to be in the
 repository of Ubuntu 16.04, so it is indeed my compiled version that is
 running, and since the service files of systemd force the configuration
 file to /etc/tor/torrc, the configuration file seems correct too.

 And by the way, if I hadn't the right config file, I guess I should have
 an IP changing every 10 minutes since it is the defaut, and not every 5
 minutes!

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

Re: [tor-bugs] #24352 [Metrics]: Bad exits inject port 82 into HTTP redirects??

[Tor Bug Tracker & Wiki]

#24352: Bad exits inject port 82 into HTTP redirects??
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics  |Version:
 Severity:  Critical | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 sorry, copy & paste mistake:

 1.​http://www.crimeflare.com/cfssl.html
 2.​http://crimeflare.net:82/cfssl.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24352 [Metrics]: Bad exits inject port 82 into HTTP redirects??

[Tor Bug Tracker & Wiki]

#24352: Bad exits inject port 82 into HTTP redirects??
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics  |Version:
 Severity:  Critical |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 1. http://www.crimeflare.com/cfgrowth.html
 2. http://crimeflare.net:82/cfssl.html


 1 is being redirected to 2. Can anyone investigate exit nodes again?



 --
 related incident: https://trac.torproject.org/projects/tor/ticket/17303

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 https://github.com/mozilla-mobile/focus-android/issues/1743

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

Re: [tor-bugs] #22582 [Applications/Tor Browser]: www.nexusmods.com not working properly in TOR

[Tor Bug Tracker & Wiki]

#22582: www.nexusmods.com not working properly in TOR
---+---
 Reporter:  WalrusInAnus   |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords:  tbb-usability-website, cloudflare  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by cypherpunks):

 * status:  assigned => closed
 * resolution:   => not a bug


Comment:

 This kind of discussion is OFF-TOR. They are blocking Tor. See
 #ListOfServiceBlockingTor.

 --


 One more step
 Please complete the security check to access www.nexusmods.com
 Why do I have to complete a CAPTCHA?

 Completing the CAPTCHA proves you are a human and gives you temporary
 access to the web property.
 What can I do to prevent this in the future?

 If you are on a personal connection, like at home, you can run an anti-
 virus scan on your device to make sure it is not infected with malware.

 If you are at an office or shared network, you can ask the network
 administrator to run a scan across the network looking for misconfigured
 or infected devices.

 Another way to prevent getting this page in the future is to use Privacy
 Pass. Check out the browser extension in the Firefox Add-ons Store.

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > User will decide what to do - go back, "try a cache", or ignore.

 Oops. Here's an update of design. Sorry for multiple post!

 =
 Your connection is not secure

 The owner of CloudflareMustDie.com is using Cloudflare on their website.
 To protect your privacy from being attacked, Tor Browser has not connected
 to this website.

 (Learn More)
 [Go Back] [Try alternative cache] [Connect anyway]
 =

 [Try alternative cache] button will redirect you to Archive.Org.

 e.g.


 https://searx.ch/
 ==cache version===> https://web.archive.org/web/https://searx.ch/

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 P.P.S.

 http://blog.archive.is/post/150457886131/re-your-blog-post-of-
 september-14-2016-143

 Eh... I actually tried to contact them at that time.
 If you're angry like me, try to contact the website owner. Convince him to
 include "T1". If they don't respond, I always just leave that website.

 Anyway, Cloudflare should be blocked by TBB, the privacy browser of the
 world. XO

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 I'm the person who created "madness" ticket, and you, sir, well writen!

 Yes, please block Cloudflare once and for all. I'm expecting some kind of
 "Isecure connection" errorpage
 to block further connection without user consent.

 For example, when I visit "CloudflareMustDie.com",
 1. TBB will show "Insecure connection" errorpage.
 2. User will decide what to do - go back, try a cache, or ignore.

 Here's my idea of errorpage design:
 =
 Your connection is not secure

 The owner of CloudflareMustDie.com is using Cloudflare on their website.
 To protect your privacy from being attacked, Tor Browser has not connected
 to this website.

 (Learn More)
 [Go Back] [Connect anyway]
 =

 (Learn More) is a link, to Tor documentation or wiki, to explain the
 cloudflare's MITM activity.
 [Connect anyway] is a button. If the user click it, Show warning dialogue
 with 3 seconds timelock:

 =
 This connection is MITMed. Are you sure you want to do this?

 [No] [Yes(3)]
 =


 And,

 > response header should immediately terminate, with an error message
 given to the user

 Yes, the connection to CF site *should* be terminate. We should treat them
 like self-signed non-onion website
 which is completely insecure.

 > This can be done by detecting the non-standard CF-Ray: HTTP header.

 You could also look at SSL certificate's CN.
 Most of them are "^sni(.*)\.cloudflaressl\.com".

 for sample:
 https://www.unspam.com/ <--- cloudflare's before project company, ewww


 P.S.
 I use TBB everyday. I got hit by cloudflare and most of the time I go back
 and search for alternative website.
 And if can't, I'll just open up normal browser to browse cloudflare-
 infected websites 'via VPN'.
 I really hope TBB start kicking cloudflare. This will raise attention and
 the website owner MIGHT, MIGHT... add "T1" to whitelist.
 Cloudflare could add "T1" to whitelist by default. They're so mean :'(

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

Re: [tor-bugs] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Zakhar: yeah, your self-built tor binary will look at
 /usr/local/etc/tor/torrc.

 If you want it to use /etc/tor/torrc, you'll need to build it with the
 various build options that the deb uses. (The simpler answer is to just
 use the deb.)

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  None
--+--
Changes (by nullius):

 * cc: nullius@… (added)


Comment:

 I set this to the parent bug of #24321, an attempt to add third-party
 software to Tor Browser (allegedly to make it more Cloudflare-friendly).
 Compare comment:241 above.

 Note:  If any party can successfully cajole or coerce the Tor Browser team
 to add arbitrary code to Tor Browser, then that would reveal an
 adversarial threat far beyond any discussed above.  I do not expect that
 the attempt could be successful.

 See also new child bug #24351 for a proposed workaround to this bug,
 inspired by https://bugs.debian.org/831835 (thanks, Anonymous!).

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nullius):

 Related: #24351

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  security, privacy,
 Severity:  Normal   |  anonymity, mitm, cloudflare
Actual Points:   |  Parent ID:  #18361
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 #18361 and its comments adequately summarize the general problem with
 Cloudflare’s MITM attack on the Internet.  I need not repeat, save to
 emphasize that when Tor Browser alleges it has a secure (TLS) connection,
 it is '''lying to the user''' if the connection runs through a known MITM.

 A reasonable workaround is for Tor Browser to block all Cloudflare sites
 loaded through HTTPS, or ''at least'' warn the user when such a site is
 loaded.  This can be done by detecting the non-standard `CF-Ray:` HTTP
 header.

 I suggest that this security enhancement should be tied to the Security
 Slider.  On High, all HTTPS connections which receive said response header
 should immediately terminate, with an error message given to the user.  On
 Medium, the user should be warned and asked whether Tor Browser should
 proceed.  On Low, where all manner of mischief is allowed by default (even
 non-TLS-loaded Javascript!), Cloudflare page loads may be permitted
 without warning.  Users who run on the Low setting are begging to be
 pwned, anyway.

 As an ancillary benefit, this feature will also obviate the specious
 reasoning behind demands to bundle untrusted third-party software with Tor
 Browser.  See #24321.

 Perhaps most visibly from a user experience and support perspective, this
 feature will also save users much wasted time solving pointless CAPTCHAs
 to visit sites which are mostly idiotic, anyway.  This should result in
 reduced user complaints about network breakage deliberately caused by
 third parties outside the Tor Project’s control.

 See also Debian bug:  https://bugs.debian.org/831835

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #18361| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nullius):

 * parent:   => #18361


Comment:

 This is a duplicate of #18361, or at best its child bug.  See
 ticket:18361#comment:241 as proposed solution by jgrahamc
 ([ticket:18361#comment:23 Cloudflare’s CTO]) to #18361.  (Note:  Does not
 actually fix the problem.)

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nullius):

 Replying to [comment:3 cypherpunks]:
 > The funny thing is https://archive.is/ is using Cloudflare too. How the
 hell am I suppose to read that?

 Yes, sorry, I am aware of that.  And that’s not the first time this has
 come up here; compare ticket:18361#comment:190 and following.  It
 highlights the scope of the problem, really.

 archive.is [http://blog.archive.is/post/150457886131 did click a whitelist
 checkbox], which made this CAPTCHA “sporadic” rather than “always”.

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

Re: [tor-bugs] #22339 [Core Tor/Tor]: META: Implement some form of jurisdiction/geography/topology-aware routing

[Tor Bug Tracker & Wiki]

#22339: META: Implement some form of jurisdiction/geography/topology-aware 
routing
--+-
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: very long term
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meta, needs-proposal  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 That's not why they're closed.

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

Re: [tor-bugs] #22339 [Core Tor/Tor]: META: Implement some form of jurisdiction/geography/topology-aware routing

[Tor Bug Tracker & Wiki]

#22339: META: Implement some form of jurisdiction/geography/topology-aware 
routing
--+-
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: very long term
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  meta, needs-proposal  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 all child closed

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 related https://trac.torproject.org/projects/tor/ticket/23840

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Too many websites use Cloudflare for FREE SSL and Cache. No other online
 service provide this level, for FREE, zero dollars! That's why they use
 Cloudflare and they won't change that easily. Piracy site use Cloudflare
 to hide their IP too.

 Cloudflare can collect information what IP goes to what cloudflared
 website. This will bring enough information to make online profile of the
 user. With Google's captcha API combined, non-Tor users are always fucked
 up. And Tor users like us can't read cloudflared websites.

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 The funny thing is https://archive.is/ is using Cloudflare too. How the
 hell am I suppose to read that?

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

Re: [tor-bugs] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Are you sure that the "freshly compiled Tor" is actually looking for its
 configuration file in /etc/tor/torrc?  (It should say in its logs where
 it's getting its configuration from.)

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

[tor-bugs] #24350 [Core Tor/Tor]: A fresh compiled tor does not honor MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#24350: A fresh compiled tor does not honor MaxCircuitDirtiness
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I am having a strange behavior when compiling tor, it does not take into
 account the '''MaxCircuitDirtiness''' I have set in the configuration...
 nor the default value that is supposed to be 10 minutes.

 In fact, it changes identity '''every 5 minutes'''!

 I tried both the Ubuntu version (0.2.9.11) and the last official one from
 tor (0.3.1.18)

 What is even stranger it that with the Ubuntu repo binary, it works fine.

 Steps to reproduce:

  * Start a Live Ubuntu 16.04.3 (x64 in my case) [so that the behavior is
 easy to reproduce]

 Execute that script (as root... no problem we are in a Live session, all
 is gone in the end), it will install the necessary packages to compile
 (otherwise configure will complain on libevent-dev, then on libssl-dev),
 download sources and compile both versions.

 {{{
 #!/bin/sh

 cd /tmp
 echo  'deb-src http://archive.ubuntu.com/ubuntu/ xenial-updates universe'
 >>'/etc/apt/sources.list'
 apt-get update
 apt-get install -y libevent-core-2.0-5 libevent-extra-2.0-5 libevent-
 openssl-2.0-5 libevent-pthreads-2.0-5 libevent-dev libssl-doc zlib1g-dev
 libssl-dev
 gpg --keyserver keyserver.ubuntu.com --recv-keys 64792D67
 gpg --no-default-keyring -a --export 64792D67 | gpg --no-default-keyring
 --keyring ~/.gnupg/trustedkeys.gpg --import -
 apt-get source tor
 cd "tor-0.2.9.11"
 ./configure
 make

 cd /tmp
 wget https://www.torproject.org/dist/tor-0.3.1.8.tar.gz
 tar xvzf tor-0.3.1.8.tar.gz
 cd "tor-0.3.1.8"
 ./configure
 make
 }}}

 You will have some warnings like:
 {{{
 ar: `u' modifier ignored since `D' is the default (see `U')
 }}}
 I am assuming these warnings are benign looking a 'u' and 'D' options in
 the man of ar.
 You will get both versions of tor compiled as documented by the README.
 Save them before rebooting.

 Now whichever version you try, here is the output tracking the change of
 IP:

 Set '''MaxCircuitDirtiness''' to 30 minutes for example with:

 {{{
 sudo echo "MaxCircuitDirtiness 1800" >>/etc/tor/torrc
 }}}

 Then test the ip we have through tor

 {{{
 $ while :; do line="$( date +%H:%M ) == $( curl -s
 http://whatismyip.akamai.com/ )"; echo "$line"; sleep 60; done
 19:27 == 185.100.84.82
 19:28 == 185.100.84.82
 19:29 == 185.100.84.82
 19:30 == 185.100.84.82
 19:31 == 185.100.84.82
 19:32 == 204.85.191.30
 19:34 == 204.85.191.30
 19:35 == 204.85.191.30
 19:36 == 204.85.191.30
 19:37 == 204.85.191.30
 19:38 == 192.160.102.168
 19:39 == 192.160.102.168
 19:40 == 192.160.102.168
 19:41 == 192.160.102.168
 19:42 == 192.160.102.168
 19:43 == 163.172.101.137
 19:44 == 163.172.101.137
 19:45 == 163.172.101.137
 19:46 == 163.172.101.137
 19:47 == 163.172.101.137
 19:48 == 62.210.105.116
 }}}

 (This is done inside a VM with transparent proxying to Tor, see
 "middlebox").

 We can see that it is changing ip '''exactly''' every 5 minutes.

 When doing the same exit ip test with the stock binary version of Ubuntu
 that you get with:
 {{{
 sudo apt-get install tor
 }}}

 ... all works well, it changes ip every 30 minutes as the configuration
 says.


 '''Questions:'''
 So... is there a magic trick to compile so that MaxCircuitDirtiness is
 taken into account ? If so, that would be a '''documentation enhancement
 request'''. I am thinking something like a flag: compile for
 "debug"/compile for "production" -didn't find that in the documentation!

 Should I ask instead on the Ubuntu Launchpad (apparently they are clever
 enough to have figured out a way to make it work!)

 We can however notice a difference between the versions we compiled and
 the binary from Ubuntu repo: '''size'''!
 That is (I am guessing) because the tor we compiled has all the symbols.
 But if you do (which is undocumented!):
 {{{
 strip --strip-unneeded tor
 }}}
 you get about the same size of stock binary. Anyway, I don't think having
 the symbols should change behaviors -except in case you have very very
 little RAM, which is not my case!-

 MaxCircuitDirtiness is not such a big issue per se, but I am afraid that
 if we have those kind of "silent tricky bugs" (nothing in the log of tor)
 when compiling ourselves, there might be other more serious bugs that
 could compromise anonymity.

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

Re: [tor-bugs] #23518 [Metrics/Atlas]: Turn Atlas into page on Tor Metrics

[Tor Bug Tracker & Wiki]

#23518: Turn Atlas into page on Tor Metrics
---+--
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2017   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 Hi Karsten, hi irl. I'm a bit curious: what is the long term plan around
 this? Do you plan to rewrite Atlas or keep it as a frame?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24349 [Metrics/Atlas]: Shrink metrics banner

[Tor Bug Tracker & Wiki]

#24349: Shrink metrics banner
---+--
 Reporter:  atagar |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Major  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Hi Karsten. I know you're proud of the quote from Bruce but the metrics
 banner is needlessly large. I suspect Atlas gets more traffic than the
 rest of metrics combined so by folding it in we should be wary of not
 making its inclusion a step backward for its users.

 I'd suggest only including Bruce's quote on the frontpage of metrics and
 shrinking the top banner...

 https://www.atagar.com/transfer/tmp/metrics_banner.png

 Thanks!

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 So, let's always track the md fail restriction, but stop applying it when
 the number of reachable filtered guards is below some threshold?
 This will probably mean extracting the const counting part out of
 num_reachable_fultered_guards().

 Otherwise, we might end up blocking someone's only working bridge, and
 that would be worse than the original bug.

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

[tor-bugs] #24348 [Internal Services/Service - lists]: Please make tor-packagers@ list

[Tor Bug Tracker & Wiki]

#24348: Please make tor-packagers@ list
---+-
 Reporter:  atagar |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Hi Jens, just reached out to a group of packagers to see if they'd be
 interested in a list for packagers to be notified of new releases and
 subprojects that would like to be packaged. Unlike my prior request
 (#24202) this would be a list for all tor projects that need packaging
 rather than just mine. :)

 List name: tor-packag...@lists.torproject.org
 List maintainer: me
 Description: Package maintainers.

 I'll go ahead and handle filling in the membership.

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 Against.

 Of all the people that get to run code as an addon in my browser, it's
 hard to think of people I trust less than Cloudflare.

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

Re: [tor-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

[Tor Bug Tracker & Wiki]

#24256: Add a new "outdated" field to distinguish between outdated and too new 
tor
versions
-+---
 Reporter:  arma |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 I took a brief look at
 [https://gitweb.torproject.org/tor.git/tree/src/or/routerparse.c#n1132
 tor_version_is_obsolete()] today. Quite a few cases there. Before I looked
 at that code I somehow assumed that we could divide the non-recommended
 bucket into outdated and experimental and be done with it. But it seems
 like we'd also need an unknown bucket and maybe even more.

 If that's really the case we might want to avoid adding separate boolean
 fields for all possible statuses, like `"outdated_version":true`,
 `"experimental_version":false`, etc., and instead introduce a new string
 field like `"version_status":"outdated"` with pre-defined values like
 `"recommended"`, `"outdated"` (or `"obsolete"`?), `"experimental"`,
 `"unknown"`, etc.

 Does that make sense? What statuses would we need, and how would we call
 them to avoid confusing users when a client application decides to present
 version status values directly to its users?

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

Re: [tor-bugs] #23544 [Metrics/Onionoo]: Add recommended_version parameter

[Tor Bug Tracker & Wiki]

#23544: Add recommended_version parameter
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 (I worked on all currently open (recommended) version related Onionoo
 tickets including this one: #22488, #23962, #21827, and #23544.)

 After working on #23962 today I revised my branch above to also include
 bridges in the "recommended_version" parameter.

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=tasks-22488-23962-21827-23544=11e5bbd80c24bb6c11ab3450d208517d4d145780
 the fourth commit 11e5bbd in my tasks-22488-23962-21827-23544 branch]
 together with [https://gitweb.torproject.org/karsten/metrics-
 
web.git/commit/?h=tasks-22488-23962-21827-23544=b01aaf6a5efb0e7198c5d27baddd80b8b68be19b
 specification changes in commit 75c7626 in my corresponding metrics-web
 branch].

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

Re: [tor-bugs] #21827 [Metrics/Onionoo]: Add recommended_version to bridge details document

[Tor Bug Tracker & Wiki]

#21827: Add recommended_version to bridge details document
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 (I worked on all currently open (recommended) version related Onionoo
 tickets including this one: #22488, #23962, #21827, and #23544.)

 This was relatively easy to build based on #22488 and #23962.

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=tasks-22488-23962-21827-23544=edc796cd890fdc656947dd11c6832a5d99ee0ae6
 the third commit edc796c in my tasks-22488-23962-21827-23544 branch]
 together with [https://gitweb.torproject.org/karsten/metrics-
 
web.git/commit/?h=tasks-22488-23962-21827-23544=b01aaf6a5efb0e7198c5d27baddd80b8b68be19b
 specification changes in commit 75c7626 in my corresponding metrics-web
 branch].

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

Re: [tor-bugs] #23962 [Metrics/Onionoo]: Allow searching by bridges by version with the version parameter

[Tor Bug Tracker & Wiki]

#23962: Allow searching by bridges by version with the version parameter
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 (I worked on all currently open (recommended) version related Onionoo
 tickets including this one: #22488, #23962, #21827, and #23544.)

 The implementation was not as tricky anymore after doing #22488 first.

 Now, regard the question whether this requires a minor or major protocol
 version update, I'm inclined to say minor. The same query for a given
 version that previously returned only relays would now return relays and
 bridges. But I can hardly imagine that clients would rely on that and now
 be seriously confused by getting some bridges back, too. I'd say, let's
 merge all four version-related changes together and just make a minor
 version bump.

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=tasks-22488-23962-21827-23544=919d5ff967ecaa401b8a0a91885fbe7b84c9807c
 the second commit 919d5ff in my tasks-22488-23962-21827-23544 branch]
 together with [https://gitweb.torproject.org/karsten/metrics-
 
web.git/commit/?h=tasks-22488-23962-21827-23544=b01aaf6a5efb0e7198c5d27baddd80b8b68be19b
 specification changes in commit 75c7626 in my corresponding metrics-web
 branch].

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

Re: [tor-bugs] #22488 [Metrics/Onionoo]: Include relay version listed in consensus in addition to platform line from server descriptor

[Tor Bug Tracker & Wiki]

#22488: Include relay version listed in consensus in addition to platform line 
from
server descriptor
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  reopened => needs_review


Comment:

 (I worked on all currently open (recommended) version related Onionoo
 tickets including this one: #22488, #23962, #21827, and #23544.)

 I suggest we add a new "version" field in addition to the existing
 "platform" field. For relays we include the version listed in the
 consensus in that field. Then we have both versions: "platform" with the
 version from the server descriptor and "version" with the version from the
 consensus.

 And for bridges we include the version substring from the "platform" line.
 That's somewhat redundant. But in some cases it might be easier for
 clients to process that version string without the rest of the rest of the
 "platform" line around it. No harm in adding that new field to both relay
 and bridge details documents.

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=tasks-22488-23962-21827-23544=bd5b45a79cc71410c66b776c44d52f7f2e84a117
 the first commit bd5b45a in my tasks-22488-23962-21827-23544 branch]
 together with [https://gitweb.torproject.org/karsten/metrics-
 
web.git/commit/?h=tasks-22488-23962-21827-23544=b01aaf6a5efb0e7198c5d27baddd80b8b68be19b
 specification changes in commit 75c7626 in my corresponding metrics-web
 branch].

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

Re: [tor-bugs] #24321 [Applications/Tor Browser]: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare captcha madness!

[Tor Bug Tracker & Wiki]

#24321: Include Cloudflare's Official "Privacy Pass" addon to end Cloudflare
captcha madness!
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nullius):

 * cc: nullius@… (added)


Comment:

 Please ''don’t''.  All of the following reasons are valid, and any would
 be sufficient to close this bug WONTFIX:

 1. The idea that Tor users should be forced to install arbitrary software
 to comply with the wishes of Tor-blockers is wrong, wrong, WRONG in
 principle.  To do so would set a horrid precedent.  What’s next, a Tor
 Browser plugin which provides blinded signatures from a smartcard chip in
 a government-issued “Internet Driver’s License”?  Such blinding should be
 done with some scheme which can be reversed by “escrowed” keys, of course.
 Hey, if you have nothing to hide, that would not only stop net abuse, it
 would also facilitate legitimate law enforcement!  (I am scared by the
 number of people who will not detect sarcasm in that statement.)

 2. Privacy Pass is still experimental.  Well, quote-unquote “beta”,
 according to their own [https://archive.is/W2Tii FAQ]:  “we regard Privacy
 Pass and the protocol we use as being beta releases currently and still
 under active development”.  Moreover, it is their own cryptographic
 construction—“[https://archive.is/RwRat developed independently]”—and a
 subtly novel one.  There is nothing wrong with that; all good crypto
 starts that way; but it does mean, this needs to be thoroughly peer-
 reviewed.  Frankly, it needs to see some serious public attempts to attack
 it (especially its promises of unlinkability).  This is NOT ready to be
 included with Tor Browser at all, let alone enabled by default.

 3. The right way to “end Cloudflare captcha madness!”, per this ticket’s
 title, is for Cloudflare to stop being mad—or better still, for its
 customers to dump it.  Not for the Tor Browser team to jump through
 Cloudflare-defined hoops, or feel their users are being held as hostages.
 Myself, I simply ignore most sites which demand a CAPTCHA for read-only,
 no-side-effect requests.  There are plenty of other sites I can go to.
 Their loss is worse than mine.  Really.  Throwing up a Cloudflare CAPTCHA
 before you deign to let me see your site is the equivalent of a Flash-
 required splash page 20 years ago.  It makes you look stupid.  Cloudflare
 “madness” is losing quality site visitors, and sites need to be told that.

 (Any apparent ire in the foregoing is not directed at Privacy Pass itself.
 It looks like a neat idea.  It needs crypto experts to hammer on it for
 awhile.  Then, sane sites ''may'' have more options for filtering the
 limited subset of requests which have high abuse potential.  Ire ''is''
 directed at Cloudflare, the Net’s single largest MITM security hole, which
 needs to die in a fire.  “IMO.”)

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

Re: [tor-bugs] #24347 [Core Tor/Tor]: periodic network bw pattern in an exit relay

[Tor Bug Tracker & Wiki]

#24347: periodic network bw pattern in an exit relay
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by toralf):

 * Attachment "graph.svg.xz" added.

 SVG graph of sysslog-ng, compressed

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24347 [Core Tor/Tor]: periodic network bw pattern in an exit relay

[Tor Bug Tracker & Wiki]

#24347: periodic network bw pattern in an exit relay
--+
 Reporter:  toralf|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Starting around 8th or 9th of Nov I realized that pattern in the SVG
 representation of sysstat-ng gathered data (pls see attached SVG) of my
 Tor exit relay.

 IMO the words "periodic" (== predictable) and "Tor" shouldn't happen in
 the same sentence.

 The system is a stable Gentoo Linux server (with LibreSSL).

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

Re: [tor-bugs] #21366 [Metrics/Onionoo]: Support whitespace in search term (as does Onionoo)

[Tor Bug Tracker & Wiki]

#21366: Support whitespace in search term (as does Onionoo)
-+---
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  enhancement  | Status:  reopened
 Priority:  Medium   |  Milestone:  Onionoo-1.7.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Here's a possible explanation: maybe this feature worked just fine in
 Tomcat and doesn't work anymore after the Jetty switch. Or, maybe it has
 to do with Servlet API versions. I didn't start investigating yet, but
 these may be possible starting points.

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

Re: [tor-bugs] #23442 [Applications/Tor Browser]: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp

[Tor Bug Tracker & Wiki]

#23442: Error building firefox for Windows 64 in security/pkix/lib/pkixnames.cpp
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201710R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:8 tom]:
 > Replying to [comment:4 cypherpunks]:
 > > Replying to [comment:3 boklm]:
 > > > Adding an `#include ` to `pkixnames.cpp` is fixing the
 build issue:
 > > > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_20636_v5=f7826cf2476406e668b049006c154374d546ab91
 > > Not fixing. It's not even a workaround.
 > > "The proper fix needs to be consistent with the fix for bug 1189891:
 change the code to use std::equals and similar instead of mem*, and remove
 all #include ." Because of
 https://bugzilla.mozilla.org/show_bug.cgi?id=1189891#c0 and other funny
 things.
 > > > But maybe it can be fixed in the same way as
 https://bugzilla.mozilla.org/show_bug.cgi?id=1199624
 > > It should have been fixed there "for memcmp/memmove/memset functions".
 > > Also 2 occurrences of `memcpy` in https://dxr.mozilla.org/mozilla-
 esr52/source/security/manager/ssl/SSLServerCertVerification.cpp#1007
 should be fixed in the same way.
 > > > However I'm wondering why we don't have the same issue for x86
 builds.
 > > A lot of reasons why mem* were declared there, but all of them were
 bugs.
 >
 >
 > I spoke with Keeler about this. From his recollection there were no
 security concerns with the changes, it was just toolchain weirdness. He
 guesses that it was mostly a coincidence that we had to make those changes
 in security/pkix but not security/manager.
 >
 > If there's no build that failing with it now he doesn't see a strong
 reason to move to std::copy, etc., but he is very concern about our cert
 verifier failing, and asked if they have testcases or steps to reproduce.
 That's why I asked you to talk to a person with enough competence. There's
 no coincidence in this case. Did you show him a citation from my comment?
 It's from https://bugzilla.mozilla.org/show_bug.cgi?id=1199624#c1 by Brian
 Smith. And if you "remove all #include " from
 https://dxr.mozilla.org/mozilla-
 
esr52/rev/f9df5238dca13e40b8128faba317df25e2f69249/security/manager/ssl/SSLServerCertVerification.cpp#97
 first, then you "see a strong reason to move to std::copy, etc." So, now
 it's easier to fix this bug instead of doing useless testing. Thanks.

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-hs, prop224,  |  Actual Points:
  032-backport? 031-backport? spec-change|
Parent ID:  #21969   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Filtered guards aren't guaranteed to be running; for that, we would want
 to look at "usable filtered guards" as in my approach b.

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

Re: [tor-bugs] #24342 [Core Tor]: Various spec fixes to dir-spec, rend-spec-v3

[Tor Bug Tracker & Wiki]

#24342: Various spec fixes to dir-spec, rend-spec-v3
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.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] #24339 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall mprotect)

[Tor Bug Tracker & Wiki]

#24339: (Sandbox) Caught a bad syscall attempt (syscall mprotect)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Assuming it's asan-only, deferring this to 0.3.3. But please move back if
 it happens without asan.

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

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

[Tor Bug Tracker & Wiki]

#24340: (Sandbox) Caught a bad syscall attempt (syscall prctl)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox, libasan  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Since the sandbox didn't support asan before, let's call this a new
 feature for 0.3.3?

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

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

[Tor Bug Tracker & Wiki]

#24339: (Sandbox) Caught a bad syscall attempt (syscall mprotect)
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Does this only happen with asan enabled, or does it happen without?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Should we consider a backport for this, or  is it too minor and/or too
 risky?

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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
--+
 Reporter:  karsten   |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-bridge, stem  |  Actual Points:
Parent ID:| Points:  .2 remaining
 Reviewer:  isis  |Sponsor:  SponsorM
--+
Changes (by nickm):

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


Comment:

 Merged the minimal version to 0.2.5 and forward to 0.3.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] #24346 [Core Tor/Tor]: prop224: Service stops uploading one of its two descriptors

[Tor Bug Tracker & Wiki]

#24346: prop224: Service stops uploading one of its two descriptors
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.4-alpha
 Severity:  Normal|   Keywords:  prop224
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+
 My prop224 service stopped working. I did some digging and I noticed that
 it's only uploading one of its two descriptors, so it's only uploading
 `next` or `current` but not both. This has reachability consequences.

 Here are some logs (grepping for `run_upload_descriptor_event()`):
 {{{
 Nov 16 15:06:51.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 16 15:51:04.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 16 17:00:25.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 16 17:06:02.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 16 18:22:23.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 16 19:05:22.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 16 19:05:22.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 16 20:13:08.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 16 20:20:11.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 16 21:18:50.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 16 21:30:21.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 16 22:49:34.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 17 00:23:30.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service current descriptor for service onion with 3/3
 introduction points.
 Nov 17 01:08:16.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 5/3
 introduction points.
 Nov 17 01:50:14.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 03:37:20.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 04:40:29.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 05:30:14.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 06:41:39.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 08:11:41.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 09:18:45.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 10:40:24.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 12:22:55.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 13:30:14.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 14:39:14.000 [info] run_upload_descriptor_event(): Initiating
 upload for hidden service next descriptor for service onion with 3/3
 introduction points.
 Nov 17 14:40:15.000 [info] 

Re: [tor-bugs] #24345 [Core Tor/Tor]: Memory leak in config/check_bridge_distribution_setting_not_a_bridge

[Tor Bug Tracker & Wiki]

#24345: Memory leak in config/check_bridge_distribution_setting_not_a_bridge
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Fixed with a5b8b55c1c39fe

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24345 [Core Tor/Tor]: Memory leak in config/check_bridge_distribution_setting_not_a_bridge

[Tor Bug Tracker & Wiki]

#24345: Memory leak in config/check_bridge_distribution_setting_not_a_bridge
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Opening this ticket so I get a number for the bugfix.

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

Re: [tor-bugs] #23719 [Applications/Tor Browser]: Make sure WebExtensions are spared from JIT disabling in higher security settings (Medium-High)

[Tor Bug Tracker & Wiki]

#23719: Make sure WebExtensions are spared from JIT disabling in higher security
settings (Medium-High)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  ff59-esr => tbb-performance
 * severity:  Normal => Major


Comment:

 I just confirmed it, at Medium-High security setting, JIT is disabled for
 WebExtensions resulting in lower performance.

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 Can you try to run `ulimit -v` both inside and outside the container to
 see what it says?

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

Re: [tor-bugs] #24341 [Applications/rbm]: rbm windows builds failing with target arch 386 mismatch with current arch amd64

[Tor Bug Tracker & Wiki]

#24341: rbm windows builds failing with target arch 386 mismatch with current 
arch
amd64
--+---
 Reporter:  pospeselr |  Owner:  boklm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/rbm  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 Replying to [comment:5 pospeselr]:
 > nightly-windows-i686 build fails (log attached).  I suspect this is the
 relevant bit:
 >
 > {{{
 > /var/tmp/dist/mingw-w64/helpers/i686-w64-mingw32-g++ -std=gnu++11
 -mwindows -o UnifiedBindings5.o -c -I/var/tmp/build/firefox-4c66c8e30e3c
 /obj-mingw/dist/stl_wrappers  -DNDEBUG=1 -DTRIMMED=1 -DWIN32_LEAN_AND_MEAN
 -D_WIN32 -DWIN32 -D_CRT_RAND_S -DCERT_CHAIN_PARA_HAS_EXTRA_FIELDS
 -DOS_WIN=1 -D_UNICODE -DCHROMIUM_BUILD -DU_STATIC_IMPLEMENTATION -DUNICODE
 -D_WINDOWS -D_SECURE_ATL -DHAVE_SIDEBAR -DSTATIC_EXPORTABLE_JS_API
 -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/var/tmp/build
 /firefox-4c66c8e30e3c/dom/bindings -I/var/tmp/build/firefox-4c66c8e30e3c
 /obj-mingw/dom/bindings -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include/mozilla/dom -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/base -I/var/tmp/build/firefox-4c66c8e30e3c/dom/battery
 -I/var/tmp/build/firefox-4c66c8e30e3c/dom/canvas -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/geolocation -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/html -I/var/tmp/build/firefox-4c66c8e30e3c/dom/indexedDB
 -I/var/tmp/build/firefox-4c66c8e30e3c/dom/media/webaudio -I/var/tmp/build
 /firefox-4c66c8e30e3c/dom/media/webspeech/recognition -I/var/tmp/build
 /firefox-4c66c8e30e3c/dom/svg -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/workers -I/var/tmp/build/firefox-4c66c8e30e3c/dom/xbl
 -I/var/tmp/build/firefox-4c66c8e30e3c/dom/xml -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/xslt/base -I/var/tmp/build/firefox-
 4c66c8e30e3c/dom/xslt/xpath -I/var/tmp/build/firefox-4c66c8e30e3c/dom/xul
 -I/var/tmp/build/firefox-4c66c8e30e3c/js/xpconnect/src -I/var/tmp/build
 /firefox-4c66c8e30e3c/js/xpconnect/wrappers -I/var/tmp/build/firefox-
 4c66c8e30e3c/layout/generic -I/var/tmp/build/firefox-
 4c66c8e30e3c/layout/style -I/var/tmp/build/firefox-
 4c66c8e30e3c/layout/xul/tree -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/mtransport -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/webrtc -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/webrtc/signaling/src/common/time_profiling
 -I/var/tmp/build/firefox-
 4c66c8e30e3c/media/webrtc/signaling/src/peerconnection -I/var/tmp/build
 /firefox-4c66c8e30e3c/obj-mingw/ipc/ipdl/_ipdlheaders -I/var/tmp/build
 /firefox-4c66c8e30e3c/ipc/chromium/src -I/var/tmp/build/firefox-
 4c66c8e30e3c/ipc/glue -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include  -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include/nspr -I/var/tmp/build/firefox-4c66c8e30e3c/obj-
 mingw/dist/include/nss -DMOZILLA_CLIENT -include /var/tmp/build
 /firefox-4c66c8e30e3c/obj-mingw/mozilla-config.h -MD -MP -MF
 .deps/UnifiedBindings5.o.pp  -Wall -Wc++11-compat -Wempty-body -Wignored-
 qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-
 limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof
 -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-
 declarations -Wno-error=array-bounds -Wno-format -fno-lifetime-dse -fno-
 exceptions -fno-strict-aliasing -mms-bitfields -mstackrealign -fno-keep-
 inline-dllexport -fno-rtti -fno-exceptions -fno-math-errno -pipe  -g -O
 -fno-omit-frame-pointer   -Wno-error=shadow  /var/tmp/build/firefox-
 4c66c8e30e3c/obj-mingw/dom/bindings/UnifiedBindings5.cpp
 > virtual memory exhausted: Operation not permitted
 > make[5]: *** [UnifiedBindings20.o] Error 1
 > }}}

 So the patch is fixing the issue, but there is an other issue after that?

 > Looks like it's using 32-bit mingw:
 >
 > {{{
 > debug-firefox$ file i686-w64-mingw32-g++
 > i686-w64-mingw32-g++: ELF 32-bit LSB executable, Intel 80386, version 1
 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
 BuildID[sha1]=0x68147607a450ac3ec94bc7c069868e2bd952c314, not stripped
 > }}}
 >
 > despite being a 64-bit kernel:
 >
 > {{{
 > Linux runc 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC 2017
 x86_64 x86_64 x86_64 GNU/Linux
 > }}}

 The kernel cannot be changed in a container, so we are always using a
 64bit kernel, but that shouldn't be a problem for running 32bit binaries.

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

Re: [tor-bugs] #23968 [Applications/Tor Browser]: NoScript icon jumps to the right after update

[Tor Bug Tracker & Wiki]

#23968: NoScript icon jumps to the right after update
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Didn't happen for me after being lucky enough to upgrade from 5.1.6 to
 5.1.7

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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-disk-leak, tbb-proxy-bypass, |  Actual Points:
  TorBrowserTeam201711   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:70 pospeselr]:

 Thanks for the review and the very helpful comments.

 > We might be able to detour whichever root offending function is causing
 the DNS request to happen but that will require more investigation, and
 would be inherently fragile and would need to be tested on every Windows
 SKU.

 I think this is a good idea, even if it's fragile. (Of course automated
 regression tests would help.) I'd like to pursue this instead of my
 earlier patch.

 I managed to obtain a stack trace responsible for the DNS leak when I
 enter an https:// URL and click the Open button:
 {{{
 06eae9d4 731034ae davclnt!NPGetResourceInformation
 06eaea2c 731035a6 MPR!WNetEnumResourceW+0x456
 06eaea68 73103558 MPR!WNetEnumResourceW+0x54e
 06eaea74 731038c3 MPR!WNetEnumResourceW+0x500
 *** ERROR: Symbol file could not be found.  Defaulted to export symbols
 for C:\Windows\syswow64\SHELL32.dll -
 06eaeab4 76b3b8e2 MPR!WNetGetResourceInformationW+0x26
 06eaeaf8 76b3b83d SHELL32!SHQueryUserNotificationState+0x56a
 06eaeb1c 76e276b2 SHELL32!SHQueryUserNotificationState+0x4c5
 06eaef78 76e280c9 SHELL32!StgMakeUniqueName+0x78d0a
 06eaf50c 76d0d2d1 SHELL32!StgMakeUniqueName+0x79721
 06eaf75c 76bb7a03 SHELL32!Ordinal733+0x2db33
 06eaf7e0 76da48a1 SHELL32!InternalExtractIconListA+0xb06
 06eaf82c 76da4945 SHELL32!Ordinal262+0x1d5f
 06eaf874 76bb9d83 SHELL32!Ordinal262+0x1e03
 06eaf8b4 76bb804b SHELL32!Ordinal866+0x1b14
 06eaf930 76bb7a03 SHELL32!SHParseDisplayName+0x1d0
 06eaf9b4 76bb7f24 SHELL32!InternalExtractIconListA+0xb06
 *** ERROR: Symbol file could not be found.  Defaulted to export symbols
 for C:\Windows\SysWOW64\comdlg32.dll -
 06eafa00 7660c9b9 SHELL32!SHParseDisplayName+0xa9
 06eafa48 7660b14f comdlg32!PrintDlgExW+0x7e23
 06eafeb4 7660aecb comdlg32!PrintDlgExW+0x65b9
 }}}

 Then I confirmed that WNetGetResourceInformation causes a DNS leak by
 running the `CheckServer()` example at https://msdn.microsoft.com/en-
 us/library/windows/desktop/aa385369(v=vs.85).aspx .

 So next I will look into how we can use Mozilla's detour utility.

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