Re: [tor-bugs] #21257 [Obfuscation/meek]: meek-azure broken

[Tor Bug Tracker & Wiki]

#21257: meek-azure broken
--+
 Reporter:  cypherpunks   |  Owner:  dcf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dcf):

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


Comment:

 I'm going to close this because I'll bet that the migration to a new
 backend (#21342) solves 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] #21034 [Applications/Tor Browser]: Per site security settings?

[Tor Bug Tracker & Wiki]

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:15 gk]:
 > Replying to [comment:14 arthuredelstein]:

 > > When I opened this ticket, I was envisioning the former (sorry this
 wasn't clearly stated). So maybe, strictly speaking, the proposed feature
 should be called "per-first-party security settings" instead of "per-site
 security settings".
 >
 > But the user in my example clearly indicated they want to have foo.com
 in "high" mode. Like clearly, clearly, because they are scared about that
 particular domain. That wish is not dependent on any other site embedding
 foo.com nor on any other site doing so on any security level. What I am
 trying to say is: making security decisions based on the URL bar domain
 does not work. The malware from foo.com you are afraid of does not care if
 there is first-party isolation on or off. It just needs *one way* to get
 to you. I believe users are aware of that and expecting that a security
 slider that defends them against that takes this into account.

 TLDR: I think there are serious problems with the current security slider
 behavior, but I tend to agree that the proposed behavior (per-first-party
 settings) is perhaps too difficult to make clear to the user.
 ---

 I now realize that, implicit in my model is that the user should start in
 default "high" mode and then use "medium" or "low" security on specific
 sites when more usability is needed. With my proposed of a simple drop-
 down attached to the URL bar, it's impossible for the user to raise the
 security of a site before they have already visited! Very similar to
 NoScript's popup menu.

 So let's take your example, but starting in default "high" security (call
 it Example A):

 In general, users don't know, unless they inspect network requests or
 source code, that bar.com sources an evil iframe from foo.com. All they
 can see is "bar.com" in the URL bar.

 In the current Tor Browser, with a global security setting, here's what
 the user does:
 * Set security to High and visit https://foo.com/ --> protected
 * Visit https://bar.com/ and then set security to Medium --> exploited

 If we add a patch that allows per-first-party security setting, the user
 does this:
 * Set default security to high
 * Visit https://foo.com --> protected
 * Visit https://bar.com, and then set bar.com's security to Medium -->
 exploited

 So in Example A, the status quo is just as bad as a per-first-party
 security setting patch. Regardless, bar.com has an undeserved "safe"
 reputation and the user was unfortunately exploited.

 Let me now propose Example B. Suppose another site, baz.com, has a well
 deserved safe reputation. The user wants to visit baz.com and the same
 dangerous foo.com.

 In the current Tor Browser:
 * Set global security to High and visit https://foo.com/ --> protected
 * Visit https://baz.com/ in the same tab, and then lower global security
 to Medium --> safe
 * Click the Back button to return to https://foo.com  --> oops! exploited

 In a browser with proposed patch:
 * Set default security to high
 * Visit https://foo.com --> protected
 * Now visit https://baz.com in the same tab, and then lower baz.com's
 security to Medium --> safe
 * Click the Back button to return to https://foo.com --> still protected

 So in Example B, in current Tor Browser it's too easy for the user to
 forget they need to set the default setting to "High" before clicking the
 back button. And I think the potential for user opsec mistakes could get
 even worse if we implement #21153.

 But despite this argument I am inclined to agree that the semantic
 problems associated with the proposed change are pretty serious. Will the
 user really understand the distinction between per-domain and per-first-
 party-domain security settings? Perhaps not. So I'm not sure how to solve
 this 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] #21804 [Applications/Tor Browser]: Tor Browser refuses to start with : Corrupt redzone 0 bytes after 0x7f0503ede9d0 (size 80), byte=0x0

[Tor Bug Tracker & Wiki]

#21804: Tor Browser refuses to start with : Corrupt redzone 0 bytes 
after
0x7f0503ede9d0 (size 80), byte=0x0
--+--
 Reporter:  adrelanos |  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 adrelanos):

 * status:  needs_information => new


Comment:

 * 6.5a5 works for me.
 * 6.5a6 jemalloc failure with slightly different output.

 {{{
 ./start-tor-browser.desktop --debug
 Launching './Browser/start-tor-browser --detach --debug'...
 Using system Tor process.
 : Corrupt redzone 0 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 1 byte after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 2 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 3 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 4 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 5 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 6 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 : Corrupt redzone 7 bytes after 0x7fcec06de960 (size 80),
 byte=0x0
 ./Browser/start-tor-browser: line 372:  6757 Segmentation fault
 TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser"
 -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21832 [Core Tor/Stem]: test_set_process_name failed.

[Tor Bug Tracker & Wiki]

#21832: test_set_process_name failed.
---+
 Reporter:  meto   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Very Low   |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Trivial|   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Hello,

 I downloaded stem and ran the ./run_tests.py --integ on OS X 10.11.6
 and found the following failing test:

 test_set_process_name [FAILURE]

 ==
 ERROR: test_set_process_name
 --
 Traceback (most recent call last):
   File "/Users/denis/Desktop/stem/test/integ/util/system.py", line 591, in
 test_set_process_name
 stem.util.system.set_process_name('stem_integ')
   File "/Users/denis/Desktop/stem/stem/util/system.py", line 1217, in
 set_process_name
 _set_proc_title(process_name)
   File "/Users/denis/Desktop/stem/stem/util/system.py", line 1274, in
 _set_proc_title
 name_buffer.value = process_name
 TypeError: bytes expected instead of str instance

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/Users/denis/Desktop/stem/test/integ/util/system.py", line 594, in
 test_set_process_name
 stem.util.system.set_process_name(initial_name)
   File "/Users/denis/Desktop/stem/stem/util/system.py", line 1217, in
 set_process_name
 _set_proc_title(process_name)
   File "/Users/denis/Desktop/stem/stem/util/system.py", line 1274, in
 _set_proc_title
 name_buffer.value = process_name
 TypeError: bytes expected instead of str instance

 --
 Ran 29 tests in 1.040s

 FAILED (errors=1, skipped=13)

 After fixing the test, I tested to see if everything is okay with:

 Python 3.4.4
 Tor version 0.2.9.10 (git-1f6c8eda0073f464).
 mock (2.0.0)
 pbr (2.0.0)
 pip (7.1.2)
 pycodestyle (2.3.1)
 pyflakes (1.5.0)
 setuptools (18.2)
 six (1.10.0)

 Python 2.7.10
 funcsigs (1.0.2)
 mock (2.0.0)
 pbr (2.0.0)
 pip (6.1.1)
 pycodestyle (2.3.1)
 pyflakes (1.5.0)
 setuptools (15.2)
 six (1.10.0)

 Fix:
 
https://github.com/Metonimie/stem/commit/e4f6da4c5dec93b95a8173e0850471f5076cad9a

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

Re: [tor-bugs] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

[Tor Bug Tracker & Wiki]

#21830: Copying large text from web console leaks to /tmp
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 linux
 try a google image search and have javascript enabled, keep hitting page
 down for a while, then go to tools -> web developer -> inspector, go to
 the opening html element and then right click and select 'copy inner
 html', then check to see for the turds.
 and in my opinion, with the same end result, this is the same as bug #9701
 and it felt pointless to rewrite 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] #21828 [Internal Services/Service - git]: Please create user repository 'tor' for iwakeh

[Tor Bug Tracker & Wiki]

#21828: Please create user repository 'tor' for iwakeh
-+-
 Reporter:  iwakeh   |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm_mobile):

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


Comment:

 Done! (It takes a couple of minutes for gitolite to chew on its new
 configuration and add the repository.)

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

Re: [tor-bugs] #21651 [Core Tor/Tor]: prop140/compression: Refactor directory cache spooling code

[Tor Bug Tracker & Wiki]

#21651: prop140/compression: Refactor directory cache spooling code
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201703, prop140, review-  |  implemented
  group-17   |  Actual Points:  2
Parent ID:   | Points:  3
 Reviewer:  ahf  |Sponsor:
 |  Sponsor4
-+-
Changes (by nickm_mobile):

 * status:  merge_ready => closed
 * resolution:   => implemented
 * actualpoints:  1 => 2


Comment:

 Squashed, merged, pushed.  Thanks for reviewing, ahf and asn!

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

Re: [tor-bugs] #21034 [Applications/Tor Browser]: Per site security settings?

[Tor Bug Tracker & Wiki]

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--

Comment (by jonathanfemideer):

 Replying to [comment:13 gk]:


 > So, I am inclined to resolve this as `WONTFIX` due to the UX nightmare
 at least.

 Please don't close this as `WONTFIX`. Let us instead use this bug report
 (or feature request) to figure out how best to meet the desired security
 improvements.

 Your question below is a great start. Thank you for asing it!

 > But for now let's assume we implement this indeed how is the
 implementation supposed to behave in the following scenario:
 >
 > 0) By default the user is in "medium" mode.
 > 1) In tab 1 one has foo.com open. A user does not like to have "medium"
 mode here but says: "For this site I want to have high security because I
 am scared" and adapts that accordingly.
 > 2) In tab 2 bar.com is open which is per default (see 0)) above in
 "medium" mode. But bar.com includes an iframe pointing to foo.com.
 >
 > Now the question is: what are the security settings for stuff loaded in
 the iframe? Is it "medium" because it is embedded in bar.com and bar.com
 is the site you are in contact with?

 The answer here is, "No," because of the false premise, "''bar.com is
 '''the''' site you are in contact with''". This premise is false because
 the user in your example is viewing, within one tab, content from ''both''
 sites.

 > Is it "high" because one said in 1) for foo.com the rule is "high"?

 Again, the answer here is, "No," and again this is because the user is
 viewing, within one tab, content from ''both'' sites.

 > If the latter how does one cope with broken sites and the problem that
 one is actually dealing with *sites* and not particular elements embedded
 in it? If the former why do we have per site security settings at all?

 I believe that this feature request is, strictly speaking, wanting Tor
 Browser to have ''per-subdomain'' security settings. The term "site" is
 not well-defined, but subdomain is. (I should have been clearer about this
 in my comment above. Mea culpa.)

 Once that is understood, the rest starts to fall into place. Content
 should be treated according to:

  1. which subdomain it arrived from; and
  1. what the security slider setting is for that subdomain.

 In your example, all content from foo.com (i.e. the stuff that is coming
 into the browser via the iframe, assuming it is all from foo.com) should
 be treated with the "High" setting, meaning that e.g. no JavaScript in
 ''that'' content will be run at all. Likewise, all content from bar.com
 (i.e. the rest of the stuff in that page, assuming it is all from bar.com)
 should be treated with the "Medium" setting, meaning that e.g. any
 JavaScript in there will only be run if it arrived over HTTPS, but even
 so, it will have JavaScript performance optimizations disabled.

 ''Mutatis mutandis'' for all the other criteria that are relevant to the
 High and Medium settings, per the [https://tb-manual.torproject.org/ar
 /security-slider.html Security Slider manual].

 What I am describing here is much like the functionality provided by
 [https://en.wikipedia.org/wiki/NoScript NoScript] or by
 [https://en.wikipedia.org/wiki/UBlock_Origin uBlock Origin]. These both
 allow JavaScript to be blocked by default, and then enabled per-domain by
 the user. These settings apply globally across the browser's tabs.

 (N.B. uBlock Origin also allows the user to select per-subdomain
 ''contexts'' in which to allow a(nother) given subdomain to execute
 scripts, but this complicates the UI somewhat. E.g. I could choose to
 allow `google-analytics.com` to execute within pages from `foo.com` but
 not within pages from `bar.com`. I propose we forget about such fine-
 grained contextual rules for now, to keep the complexity low.)

 Those two add-ons could be a source of inspiration (and code) for Tor
 Browser UX/UI elements with which to implement the desired functionality.
 Probably, the Tor Browser should keep things a bit simpler than those two
 add-ons do, though, to reduce the risk of a user becoming confused and
 misconfiguring their Tor Browser in a way that undermines their security.

 I would suggest that clicking the Torbutton should show, in addition to
 the "Tor circuit for this site" pane, etc, a column of sliders, one for
 each origin subdomain that the page in the current tab is attempting to
 load content from. Using ASCII art with "@" instead of an 

Re: [tor-bugs] #21780 [Applications/Tor Browser]: macOS Sierra Finder complains that 'tor' isn't signed

[Tor Bug Tracker & Wiki]

#21780: macOS Sierra Finder complains that 'tor' isn't signed
--+--
 Reporter:  teor  |  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 mcs):

 * cc: brade, mcs (added)


Comment:

 I am not able to reproduce this problem. I do not understand everything
 about code signing on OSX, but if there is a problem shouldn't an error be
 shown for non-parental control users the first time the app is opened?

 To try to reproduce, I enabled Parental Controls for a non-admin account
 and tried to run Tor Browser there from /Applications. Do I need to change
 any of the parental control settings? (I just used the defaults.)

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

Re: [tor-bugs] #21779 [Applications/Tor Browser]: Non-admin users can't access Tor Browser on macOS

[Tor Bug Tracker & Wiki]

#21779: Non-admin users can't access Tor Browser on macOS
--+--
 Reporter:  teor  |  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 mcs):

 * cc: brade, mcs (added)


Comment:

 Kathy and I were able to reproduce this bug. As you point out, it should
 be fine to allow rx permission to "other." Doing something like:
   chmod -R o+rX TorBrowser.app
 during our packaging should fix this 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] #21747 [Applications/Tor Browser]: Requesting a new circuit for a site is not working in ESR 52 based Tor Browser

[Tor Bug Tracker & Wiki]

#21747: Requesting a new circuit for a site is not working in ESR 52 based Tor
Browser
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff52-esr, |  Actual Points:
  tbb-7.0-must, TorBrowserTeam201703R, tbb-7.0   |
  -must-nightly  |
Parent ID:  #21201   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 r=brade, r=mcs
 This patch looks okay and it seems to work. Why did you need to add the
 following code?
 {{{
   if (domain === "") {
 domain = "--unknown--";
   }
 }}}

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

Re: [tor-bugs] #18589 [Applications/Tor Browser]: Tor browser writes SiteSecurityServiceState.txt with usage history

[Tor Bug Tracker & Wiki]

#18589: Tor browser writes SiteSecurityServiceState.txt with usage history
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:12 gacar]:
 > PS: I should also note that I couldn't completely reproduce the problem
 with 6.5.1 and 7.0a2 on Linux 64. Although I visited several sites that
 send HSTS headers, only a few TPO and AMO-related domains
 (aus1.torproject.org, www.torproject.org, aus1.torproject.org) added to
 the SiteSecurityServiceState.txt  (something to do with the chrome vs
 content connections?).

 Interesting. Does the same happen with a vanilla Firefox 45.8.0esr? How
 did you test 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] #21798 [Applications/Tor Browser]: Does not display the manually added root certificats

[Tor Bug Tracker & Wiki]

#21798: Does not display the manually added root certificats
--+---
 Reporter:  bortzmeyer|  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 gk):

 * status:  new => needs_information
 * version:  Tor: unspecified =>


Comment:

 You mean the certificate got added, is still there but now can't get
 removed? How did you check that the cert did get added at all? If it is
 indeed added does the problem persist if you close the browser and
 restart?

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

Re: [tor-bugs] #21804 [Applications/Tor Browser]: Tor Browser refuses to start with : Corrupt redzone 0 bytes after 0x7f0503ede9d0 (size 80), byte=0x0

[Tor Bug Tracker & Wiki]

#21804: Tor Browser refuses to start with : Corrupt redzone 0 bytes 
after
0x7f0503ede9d0 (size 80), byte=0x0
--+---
 Reporter:  adrelanos |  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 gk):

 * status:  new => needs_information


Comment:

 Replying to [comment:2 adrelanos]:
 > No.
 >
 > 6.5.1 works for me. Any other versions I should try?

 6.5a5 and 6.5a6: https://archive.torproject.org/tor-package-
 archive/torbrowser/

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

[tor-bugs] #21831 [Applications/Tor Browser]: "Connection is Not Secure" warning.

[Tor Bug Tracker & Wiki]

#21831: "Connection is Not Secure" warning.
--+--
 Reporter:  jonathanfemideer  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Browsing to certain HTTPS-protected web pages using Tor Browser 6.5.1,
 with the Tor Browser Security Settings slider set to "High", results in a
 red diagonal bar being drawn through the padlock that sits to the left of
 the address bar. Here is a URL for such a web page:

 https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable
 /unison-manual.html

 Clicking the crossed-out padlock while visiting that web page in Tor
 Browser 6.5.1 results in a tooltip divided into three panes: top-left,
 top-right, and bottom. The top-left pane says:

 www.cis.upenn.edu
 Connection is Not Secure
 You have disabled protection on this page.

 The top-right pane has an arrow. Clicking on that arrow replaces the
 tooltip contents with this:

 This website contains content that is not secure (such as scripts) and
 your connection to it is not private.
 Information you share with this site could be viewed by others (like
 passwords, messages, credit cards, etc.).
 [https://support.mozilla.org/1/firefox/45.8.0/Linux/en-US/mixed-content
 Learn More]

 At the bottom of the new tooltip contents, there is a button marked
 "Enable protection" and another button marked "More Information".

 Clicking the "Enable protection" button appears to have no effect, except
 that it closes the tooltip and refreshes the page.

 Clicking the "More Information" button launches the Page Info dialogue
 box.

 It seems to me that, ideally:

 - The protection referred to by the "Enable protection" button should be
 enabled by default (at least when the security slider is set to "High",
 and maybe also for "Medium" and/or "Low"), thereby avoiding both the
 security risk and the corresponding warning.

 - Failing that, the protection referred to by the "Enable protection"
 button should at least take effect when that button is clicked, thereby
 avoiding both the security risk and the corresponding warning, at least
 for that website.

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

Re: [tor-bugs] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

[Tor Bug Tracker & Wiki]

#21830: Copying large text from web console leaks to /tmp
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  needs_information => assigned


Comment:

 And ideally it would be nice to have steps to reproduce.

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

Re: [tor-bugs] #21806 [Applications/Tor Browser]: webgl hangs on Tor Browser

[Tor Bug Tracker & Wiki]

#21806: webgl hangs on Tor Browser
--+---
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * keywords:   => tbb-usability-website


Comment:

 This works on Linux for me. Or at least I think it does. When does that
 hang happen? How can I reproduce 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] #21651 [Core Tor/Tor]: prop140/compression: Refactor directory cache spooling code

[Tor Bug Tracker & Wiki]

#21651: prop140/compression: Refactor directory cache spooling code
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorCoreTeam201703, prop140, review-  |  Actual Points:  1
  group-17   |
Parent ID:   | Points:  3
 Reviewer:  ahf  |Sponsor:
 |  Sponsor4
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 All fixes look good to me!

 I'll turn this to `merge_ready`.

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

Re: [tor-bugs] #21034 [Applications/Tor Browser]: Per site security settings?

[Tor Bug Tracker & Wiki]

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:14 arthuredelstein]:
 > Replying to [comment:13 gk]:
 > > So, I am inclined to resolve this as `WONTFIX` due to the UX nightmare
 at least. But for now let's assume we implement this indeed how is the
 implementation supposed to behave in the following scenario:
 > >
 > > 0) By default the user is in "medium" mode.
 > > 1) In tab 1 one has foo.com open. A user does not like to have
 "medium" mode here but says: "For this site I want to have high security
 because I am scared" and adapts that accordingly.
 > > 2) In tab 2 bar.com is open which is per default (see 0)) above in
 "medium" mode. But bar.com includes an iframe pointing to foo.com.
 > >
 > > Now the question is: what are the security settings for stuff loaded
 in the iframe? Is it "medium" because it is embedded in bar.com and
 bar.com is the site you are in contact with? Is it "high" because one said
 in 1) for foo.com the rule is "high"? If the latter how does one cope with
 broken sites and the problem that one is actually dealing with *sites* and
 not particular elements embedded in it? If the former why do we have per
 site security settings at all?
 >
 > When I opened this ticket, I was envisioning the former (sorry this
 wasn't clearly stated). So maybe, strictly speaking, the proposed feature
 should be called "per-first-party security settings" instead of "per-site
 security settings".

 But the user in my example clearly indicated they want to have foo.com in
 "high" mode. Like clearly, clearly, because they are scared about that
 particular domain. That wish is not dependent on any other site embedding
 foo.com nor on any other site doing so on any security level. What I am
 trying to say is: making security decisions based on the URL bar domain
 does not work. The malware from foo.com you are afraid of does not care if
 there is first-party isolation on or off. It just needs *one way* to get
 to you. I believe users are aware of that and expecting that a security
 slider that defends them against that takes this into account.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 [https://trac.torproject.org/projects/tor/ticket/21367#comment:18 Related
 comment from another ticket]: "The reason is that the bridge authority
 does not recommend versions, so that we'd have to take version
 recommendations from relay network status consensuses and apply that to
 bridges. There may be other issues. But I see how this would be
 potentially useful. Please open an Onionoo ticket for this if you want
 this feature to be added to Onionoo."

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

Re: [tor-bugs] #20983 [Metrics/CollecTor]: bridge ContactInfo information (less sanitization)

[Tor Bug Tracker & Wiki]

#20983: bridge ContactInfo information (less sanitization)
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Replying to [comment:5 cypherpunks]:
 > After looking at the spec
 > https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt#n55
 >
 > I noticed that the bridge descriptor does not even contain contactinfo?
 >
 > So it is not there and can not be published?

 That's not the bridge descriptor specification, it's the BridgeDB
 specification.  BridgeDB is a bridge distribution service.  Bridge
 descriptors are produced by the Tor daemon just like relay descriptors.
 They do contain contact information.

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

Re: [tor-bugs] #21034 [Applications/Tor Browser]: Per site security settings?

[Tor Bug Tracker & Wiki]

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:13 gk]:
 > So, I am inclined to resolve this as `WONTFIX` due to the UX nightmare
 at least. But for now let's assume we implement this indeed how is the
 implementation supposed to behave in the following scenario:
 >
 > 0) By default the user is in "medium" mode.
 > 1) In tab 1 one has foo.com open. A user does not like to have "medium"
 mode here but says: "For this site I want to have high security because I
 am scared" and adapts that accordingly.
 > 2) In tab 2 bar.com is open which is per default (see 0)) above in
 "medium" mode. But bar.com includes an iframe pointing to foo.com.
 >
 > Now the question is: what are the security settings for stuff loaded in
 the iframe? Is it "medium" because it is embedded in bar.com and bar.com
 is the site you are in contact with? Is it "high" because one said in 1)
 for foo.com the rule is "high"? If the latter how does one cope with
 broken sites and the problem that one is actually dealing with *sites* and
 not particular elements embedded in it? If the former why do we have per
 site security settings at all?

 When I opened this ticket, I was envisioning the former (sorry this wasn't
 clearly stated). So maybe, strictly speaking, the proposed feature should
 be called "per-first-party security settings" instead of "per-site
 security settings".

 Already, a first-party domain is ultimately responsible for everything
 loaded in a page, including third-party scripts and iframes. And some
 first-party domains are more trustworthy than others.

 For example, I sometimes keep Tor Browser on the "high security" setting
 by default. Sometimes I need to lower the security level for a particular
 HTTPS site because it is otherwise unusable. In that case, I have
 determined that I trust the site not to embed a shady third-party iframe.
 Unfortunately, currently, in order to lower the security setting of that
 site, I need to lower the security setting for all sites. This is
 obviously dangerous and also potentially risks cross-site linking.

 As far as UX is considered, my thinking would be to have security setting
 button next to the URL bar, similar to the NoScript button. The button's
 dropdown menu would have the title "Security setting for this page" with
 the three options (Low, Medium, High). In fact, it might be possible to
 hide the NoScript button altogether, because the "Temporarily allow all
 this page" menu option is more or less redundant in this situation.

 Having a separate content process for each first-party not only would make
 this possibly feasible, but it would also reduce the risk that exploits
 can link one tab to another.

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

Re: [tor-bugs] #21748 [Obfuscation/Snowflake]: Snowflake breaks nightly builds as of March 15

[Tor Bug Tracker & Wiki]

#21748: Snowflake breaks nightly builds as of March 15
---+--
 Reporter:  gk |  Owner:  arlolra
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  tbb-7.0-must-nightly   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 I'll try, but I need to get our Windows build working with ESR52 first.
 I'll let you know in this ticket when I have the alpha built hoping
 someone else does so meanwhile.

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

Re: [tor-bugs] #21795 [Applications/Tor Browser]: Tor Browser is crashing on github.com on Windows

[Tor Bug Tracker & Wiki]

#21795: Tor Browser is crashing on github.com on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  TorBrowserTeam201703  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1351278

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

Re: [tor-bugs] #21748 [Obfuscation/Snowflake]: Snowflake breaks nightly builds as of March 15

[Tor Bug Tracker & Wiki]

#21748: Snowflake breaks nightly builds as of March 15
---+--
 Reporter:  gk |  Owner:  arlolra
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  tbb-7.0-must-nightly   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arlolra):

 gk, to speed things up, could you build the alpha version of the linked
 branch above?

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

Re: [tor-bugs] #21034 [Applications/Tor Browser]: Per site security settings?

[Tor Bug Tracker & Wiki]

#21034: Per site security settings?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20843| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 So, I am inclined to resolve this as `WONTFIX` due to the UX nightmare at
 least. But for now let's assume we implement this indeed how is the
 implementation supposed to behave in the following scenario:

 0) By default the user is in "medium" mode.
 1) In tab 1 one has foo.com open. A user does not like to have "medium"
 mode here but says: "For this site I want to have high security because I
 am scared" and adapts that accordingly.
 2) In tab 2 bar.com is open which is per default (see 0)) above in
 "medium" mode. But bar.com includes an iframe pointing to foo.com.

 Now the question is: what are the security settings for stuff loaded in
 the iframe? Is it "medium" because it is embedded in bar.com and bar.com
 is the site you are in contact with? Is it "high" because one said in 1)
 for foo.com the rule is "high"? If the latter how does one cope with
 broken sites and the problem that one is actually dealing with *sites* and
 not particular elements embedded in it? If the former why do we have per
 site security settings at all?

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

Re: [tor-bugs] #20983 [Metrics/CollecTor]: bridge ContactInfo information (less sanitization)

[Tor Bug Tracker & Wiki]

#20983: bridge ContactInfo information (less sanitization)
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 After looking at the spec
 https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt#n55

 I noticed that the bridge descriptor does not even contain contactinfo?

 So it is not there and can not be published?

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

Re: [tor-bugs] #20059 [Core Tor/Tor]: Bug: Duplicate call to circuit_mark_for_close

[Tor Bug Tracker & Wiki]

#20059: Bug: Duplicate call to circuit_mark_for_close
+--
 Reporter:  cypherpunks |  Owner:  nickm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  030-backport, 029-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  dgoulet |Sponsor:
+--
Changes (by Christian):

 * cc: tor@… (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] #9701 [Applications/Tor Browser]: Prevent TorBrowser from creating clipboardcache turds

[Tor Bug Tracker & Wiki]

#9701: Prevent TorBrowser from creating clipboardcache turds
-+-
 Reporter:  cypherpunks  |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-disk-leak, interview, tbb-   |  Actual Points:
  firefox-patch, TorBrowserTeam201501|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:41 cypherpunks]:
 > i had this happen using the webconsole copying a large section of de-
 obfuscated html with torbrowser 6.5.1

 Please don't reopen tickets that got closed two years ago and open new
 ones instead, thanks. I did so for this issue: #21830 and have a question
 for you on 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] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

[Tor Bug Tracker & Wiki]

#21830: Copying large text from web console leaks to /tmp
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Which operating system are you using?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21830 [Applications/Tor Browser]: Copying large text from web console leaks to /tmp

[Tor Bug Tracker & Wiki]

#21830: Copying large text from web console leaks to /tmp
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-disk-leak
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 A user reported using the webconsole copying a large section of de-
 obfuscated html with torbrowser 6.5.1 resulted in those contents being
 available in /tmp.

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

Re: [tor-bugs] #21802 [Applications/Tor Browser]: Login failure with Tor Browser: Error loading content, try again. (was: Error loading content, try again.)

[Tor Bug Tracker & Wiki]

#21802: Login failure with Tor Browser: Error loading content, try again.
--+---
 Reporter:  CodyRo|  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * severity:  Critical => Normal
 * component:  - Select a component => Applications/Tor Browser
 * priority:  High => Medium
 * keywords:   => tbb-usability-website


Comment:

 Did older versions work? Which ones and are they still working? (see:
 https://archive.torproject.org/tor-package-archive/torbrowser/ for older
 ones)

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

Re: [tor-bugs] #21829 [Applications/Tor Browser]: Tor constantly crumbles and does not join the sites.

[Tor Bug Tracker & Wiki]

#21829: Tor constantly crumbles and does not join the sites.
--+---
 Reporter:  MrFlori   |  Owner:
 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 gk):

 * status:  new => needs_information
 * severity:  Critical => Normal
 * component:  - Select a component => Applications/Tor Browser
 * priority:  Immediate => Medium
 * version:  Tor: unspecified =>
 * milestone:  Tor: 0.3.2.x-final =>
 * keywords:  crash =>


Comment:

 Which version are you using? Did it work before? Is your time on your
 computer set correctly? Do you get some log entries if you are trying to
 use the copy to clipboard button? Do you have Antivirus or firewall
 software that could be interfering with Tor Browser? If so, could you
 uninstall it to check whether that's the problem (disabling is often not
 enough)?

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

[tor-bugs] #21829 [- Select a component]: Tor constantly crumbles and does not join the sites.

[Tor Bug Tracker & Wiki]

#21829: Tor constantly crumbles and does not join the sites.
--+
 Reporter:  MrFlori   |  Owner:
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:  Tor: 0.3.2.x-final
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Critical  |   Keywords:  crash
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Tor constantly crumbles and does not join the sites.

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

Re: [tor-bugs] #21748 [Obfuscation/Snowflake]: Snowflake breaks nightly builds as of March 15

[Tor Bug Tracker & Wiki]

#21748: Snowflake breaks nightly builds as of March 15
---+--
 Reporter:  gk |  Owner:  arlolra
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  tbb-7.0-must-nightly   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => tbb-7.0-must-nightly


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

Re: [tor-bugs] #21748 [Obfuscation/Snowflake]: Snowflake breaks nightly builds as of March 15

[Tor Bug Tracker & Wiki]

#21748: Snowflake breaks nightly builds as of March 15
---+--
 Reporter:  gk |  Owner:  arlolra
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 FWIW: We'd need that by next Monday as we want to switch the nightlies to
 use ESR52 by 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #21766, #21147, #21745, #18831, ...

[Tor Bug Tracker & Wiki]

Batch modification to #21766, #21147, #21745, #18831, #19048, #20680, #21201, 
#21239, #21240, #21328, #21546, #21629, #21747 by gk:
keywords to tbb-7.0-must-nightly

Comment:
We want those tickets for our first ESR52 nightlies.

--
Tickets URL: 

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

Re: [tor-bugs] #21328 [Applications/Tor Browser]: Move to clang 3.8.0 for Tor Browser's clang-based macOS toolchain

[Tor Bug Tracker & Wiki]

#21328: Move to clang 3.8.0 for Tor Browser's clang-based macOS toolchain
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-gitian, ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201703, GeorgKoppen201703|
Parent ID:  #21147   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * cc: boklm (added)


Comment:

 Replying to [comment:10 gk]:
 > It seems moving to the new toolchain has reproducibility problems as a
 result. :( I just bumped the Debian distro to Jessie and put clang
 together according to https://bugzilla.mozilla.org/show_bug.cgi?id=1273981
 and the resulting dmgs don't match anymore. Using the old clang compiler
 does not have the same problems.

 Okay, attached is the diff. I used https://gitweb.torproject.org/user/gk
 /tor-browser-bundle.git/log/?h=bug_21328_v3. The problematic commit is:
 https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_21328_v3&id=868433db05b3dc57926e32b79213383483f15f59.
 Testing with the ones before that one gives me matching builds on the same
 build machine. Some things we could do to find the problem:

 1) We could try to pinpoint where exactly the issue is. Is it in tor code
 or in openssl code, or...?
 2) We could test whether the update to Jessie is causing this (by taking
 https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_21328_v3&id=6ff54b812b08f3b64fb277f0541dfd9562bf3d6e
 and just bump everything to Jessie)
 3) We could just use the clang part for compiling the remaining utils and
 tor (and not include `libcxx` nor `libcxxabi` which should not be needed
 anyway) to make sure the issue is inside `clang`.
 4) Assuming this is indeed in `clang`, because the investigation done in
 1) - 3) shows that, we could do some bisecting finding the problematic
 commit.

 boklm: Can you take that one from here?

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