Re: [tor-bugs] #20382 [Metrics/Atlas]: atlas doesn't check if a relay's family members also list that relay in their family (was: atlas doesn't check if all family members list themselves)

[Tor Bug Tracker & Wiki]

#20382: atlas doesn't check if a relay's family members also list that relay in
their family
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  family |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * keywords:  atlas family members => family


Comment:

 Clarified bug title.

 By the way, nick3 is wrong: the attack is to steer traffic towards
 particular nodes by listing a very large family. And it doesn't work on
 recent versions of Tor, because it checks for mutual family relationships.

 OnionOO has effective_family and alleged_family, I suggest they are
 coloured differently in the Atlas family list, like we currently colour
 missing relays differently.

 https://onionoo.torproject.org/protocol.html#details

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

Re: [tor-bugs] #20373 [Applications/Tor Browser]: Privacy and Security Settings window opens twice

[Tor Bug Tracker & Wiki]

#20373: Privacy and Security Settings window opens twice
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 I know this is a late comment (and the patch looks OK to me), but rather
 than tracking open windows inside Torbutton I would have used
 nsIWindowMediator.getMostRecentWindow() to find the dialog if it is open
 (we would need to add a unique type attribute to the dialog XUL). Or maybe
 there is a reason why that approach would not work in this situation.

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

Re: [tor-bugs] #20364 [Metrics/Ooni]: Update debian/ubuntu packages of ooniprobe to 2.0.0

[Tor Bug Tracker & Wiki]

#20364: Update debian/ubuntu packages of ooniprobe to 2.0.0
--+--
 Reporter:  hellais   |  Owner:  irl
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Ooni  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hellais):

 Thanks for accepting this!

 > Should the systemd service be installed disabled by default then? Or
 does it do a check on startup that it was wanted by looking at a conf
 file?

 I am not sure what would be the "least surprising" way to go about this.
 What does tor do when it's installed? Does it configure the service to run
 by default?

 When it's started the first time it is setup so that it's actually not
 running any tests so the user actually has to go through the informed
 consent procedure (by either running ooniprobe -z from the command line or
 by visiting http://127.0.0.1:8842/) to make it run any measurement.

 I see two options for going about this:

 1) We make the startup of the system service an option that the user can
 opt in via an interactive step of the setup process (like it is now for
 the configuration of the cronjob)

 2) We make it startup by default, but inform in some way (maybe with a
 dialog or just printing a line on post install) that they will have to
 login to http://127.0.0.1:8842/ to agree to the informed consent before it
 will do anything.

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 Sure; just add it in a separate commit?

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by chelseakomlo):

 Sounds great. I can make the change to use a switch statement here if you
 don't want to open a separate 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] #20306 [Core Tor/Tor]: "Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in th

[Tor Bug Tracker & Wiki]

#20306: "Tor cannot connect to the Internet if ReachableAddresses,
ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please
accept some addresses in these options." when "FascistFirewall 1" is set
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.9.3-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression nickm-deferred-20161017  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 It looks like this check confuses `reject *:80` and `reject *:*`. This may
 mean that we need to revise the is_reject_star code, or the code that uses
 it.

--
Ticket URL: <https://troodi.torproject.org/projects/tor/ticket/20306#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20247 [Core Tor/Tor]: crash after closing and opening ipv6 DirPort + OrPort

[Tor Bug Tracker & Wiki]

#20247: crash after closing and opening ipv6 DirPort + OrPort
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.8
 Severity:  Normal   | Resolution:
 Keywords:  crash 028-backport ipv6 nickm-   |  Actual Points:
  deferred-20161017  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Yes, I don't know whether the issue is a sandbox issue, or a capability
 issue.
 One way of telling the difference is to re-try using ports > 1024.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20247#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, 030-proposed, |  Actual Points:
  prop224, TorCoreTeam201609 |
Parent ID:  #17238   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 Whatever we call it, here's what I think it means:

 The service is a single onion service. It may make direct connections to
 introduction and rendezvous points. Clients should make 3-hop connections
 to introduction and rendezvous points, to avoid having their connections
 blocked by upcoming relay defenses against one-hop hidden service proxies.

 I am happy to use single-onion-service, as I think it's unlikely we'll
 implement prop 252-style services (services that extend to an ORPort), and
 if we do, they will have their own link specifier type and semantics,
 distinct from single onion services as now implemented.

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

[tor-bugs] #20389 [Core Tor/Tor]: Say 'Invalid argument' instead of unclear 'Unrecognized' in HSFETCH

[Tor Bug Tracker & Wiki]

#20389: Say 'Invalid argument' instead of unclear 'Unrecognized' in HSFETCH
--+-
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


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

Re: [tor-bugs] #20388 [Applications/Tor Browser]: Consolidate prefs usage in torbutton.js

[Tor Bug Tracker & Wiki]

#20388: Consolidate prefs usage in torbutton.js
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-code-cleanup,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-code-cleanup => tbb-code-cleanup, TorBrowserTeam201610R
 * status:  new => needs_review


Comment:

 Here's a patch for review:
 https://github.com/arthuredelstein/torbutton/commit/20388

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20388 [Applications/Tor Browser]: Consolidate prefs usage in torbutton.js

[Tor Bug Tracker & Wiki]

#20388: Consolidate prefs usage in torbutton.js
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor |   Keywords:  tbb-code-cleanup
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 In torbutton.js, we call
 {{{
 var pref_service = Components.classes["@mozilla.org/preferences-
 service;1"]
 .getService(Components.interfaces.nsIPrefBranch);
 }}}
 or
 {{{
 m_tb_prefs =  Components.classes["@mozilla.org/preferences-service;1"]
 .getService(Components.interfaces.nsIPrefBranch);
 }}}
 7 times when that functionality is already available in `Services.prefs`.
 So I am proposing to consolidate this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20387 [Internal Services/Service - git]: Please create a tor-messenger.git repo

[Tor Bug Tracker & Wiki]

#20387: Please create a tor-messenger.git repo
-+
 Reporter:  arlolra  |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 To maintain a fork of https://hg.mozilla.org/releases/comm-esr45/ similar
 to tor-browser.git

 We've got a number of patches which are becoming unwieldy,
 https://gitweb.torproject.org/tor-messenger-
 build.git/tree/projects/instantbird

 Most likely, Mozilla will handle the hg => git sync in,
 https://bugzilla.mozilla.org/show_bug.cgi?id=1309045

 but otherwise, I'll do it.  Thanks!

 Oh, and please grants access to the `tormessenger` group.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20386 [Internal Services/Service - git]: Please remove 686 and updater branches from tor-messenger-build

[Tor Bug Tracker & Wiki]

#20386: Please remove 686 and updater branches from tor-messenger-build
-+
 Reporter:  arlolra  |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 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] #20231 [Applications/Tor Messenger]: Cannot configure OTR anymore on Tor Messenger 0.2.0b2

[Tor Bug Tracker & Wiki]

#20231: Cannot configure OTR anymore on Tor Messenger 0.2.0b2
+--
 Reporter:  PZajda  |  Owner:
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:  Tor: unspecified
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by arlolra):

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


Comment:

 Incomplete translations were removed in https://gitweb.torproject.org/tor-
 messenger-build.git/commit/?id=28b57bb120af499ebf6d17b64f0e335ed94c29c3

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

Re: [tor-bugs] #20289 [Core Tor]: HS_DESC event while waiting for upload

[Tor Bug Tracker & Wiki]

#20289: HS_DESC event while waiting for upload
-+
 Reporter:  meejah   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by meejah):

 Okay, if the delay is going away soon, that's great :)

 If any kind of delay or random jitter is still left in, though, it would
 be nice to tell controllers that because then they can provide e.g. an
 update every 1 second if they want. (I.e. if the controller knows it'll be
 5.3 seconds until any `HS_DESC UPLOAD` events can possibly arrive, that
 can be easily factored into a progress display).

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

Re: [tor-bugs] #20384 [Core Tor/Tor]: TROVE-2016-10-001: out-of-bounds read on buffer chunks

[Tor Bug Tracker & Wiki]

#20384: TROVE-2016-10-001: out-of-bounds read on buffer chunks
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 The attached tarball is gpg-signed with my older key and my newer key.
 It has patches for 0.2.4, 0.2.5, and 0.2.6.  The 0.2.6 patch should also
 apply cleanly to 0.2.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] #20384 [Core Tor/Tor]: TROVE-2016-10-001: out-of-bounds read on buffer chunks

[Tor Bug Tracker & Wiki]

#20384: TROVE-2016-10-001: out-of-bounds read on buffer chunks
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I am attaching a tarball of patches for older versions.

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

Re: [tor-bugs] #20384 [Core Tor/Tor]: TROVE-2016-10-001: out-of-bounds read on buffer chunks (was: TROVE-2016-10-001)

[Tor Bug Tracker & Wiki]

#20384: TROVE-2016-10-001: out-of-bounds read on buffer chunks
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Old description:

> Placeholder ticket; see #20383 for "TROVE" backronym.  Fix should go out
> in 0.2.9.4-alpha in the next 48 hours.  Severity is "Medium".

New description:

 Placeholder ticket; see #20383 for "TROVE" backronym.  Fix should go out
 in 0.2.9.4-alpha in the next 48 hours.  Severity is "Medium".

 This is fixed in 0.2.8.9 and 0.2.9.4-alpha.  The changelog says:

 {{{
   Tor 0.2.9.4-alpha fixes a security hole in previous versions of Tor
   that would allow a remote attacker to crash a Tor client, hidden
   service, relay, or authority. All Tor users should upgrade to this
   version, or to 0.2.8.9. Patches will be released for older versions
   of Tor.

   o Major features (security fixes):
 - Prevent a class of security bugs caused by treating the contents
   of a buffer chunk as if they were a NUL-terminated string. At
   least one such bug seems to be present in all currently used
   versions of Tor, and would allow an attacker to remotely crash
   most Tor instances, especially those compiled with extra compiler
   hardening. With this defense in place, such bugs can't crash Tor,
   though we should still fix them as they occur. Closes ticket
   20384 (TROVE-2016-10-001).

 }}}

--

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

Re: [tor-bugs] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 I found https://bugzilla.mozilla.org/show_bug.cgi?id=1070038 which
 describes similar symptoms, but it was fixed for Firefox 35. I guess the
 fact that ESR 45 does not show a problem is not that interesting because
 it does not contain the fixes we backported for this ticket (I keep
 getting confused by Apple's exception for Firefox <= 48).

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

Re: [tor-bugs] #20195 [HTTPS Everywhere/EFF-HTTPS Everywhere]: HTTPS Everywhere's SSL Observatory code doesn't honor domain isolation.

[Tor Bug Tracker & Wiki]

#20195: HTTPS Everywhere's SSL Observatory code doesn't honor domain isolation.
-+-
 Reporter:  yawning  |  Owner:  legind
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Major| Resolution:  fixed
 Keywords:  tbb-linkability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by legind):

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


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

Re: [tor-bugs] #20381 [Applications/Tor Browser]: Tor Browser nightly bundles crash on Linux 64bit systems

[Tor Bug Tracker & Wiki]

#20381: Tor Browser nightly bundles crash on Linux 64bit systems
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  tbb-crash, TorBrowserTeam201610, |  Actual Points:
  GeorgKoppen201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 I am not a compiler expert, but it surprises me that lifetime-dse=1 or
 -fno-lifetime-dse does not make the problem disappear. But
 https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c11 says otherwise.
 Maybe there are problems with gcc 6 that Mozilla does not understand yet.

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

Re: [tor-bugs] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

[Tor Bug Tracker & Wiki]

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Repeating comments here that I made on IRC in case they were missed:

 Kathy and I do not have as many different OSX versions as I hoped. Here is
 what we learned though:
 * on 10.6.8, dragging anywhere in the window (including on the scrollbar)
 moves the window.
 * on 10.11.6 and 10.12, the same problem occurs if you load a second page
 and then go back in history.
 We have no way to test on 10.7 - 10.10 at the moment.
 I cannot find a Mozilla bug for the 10.11.6 and 10.12 behavior, but I
 cannot reproduce the problem with Firefox 49 or 50 beta either. I will try
 ESR 45.4.0.

 and a few minutes later:
 * I cannot reproduce the problem with Firefox ESR 45.4.0

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

Re: [tor-bugs] #19270 [Applications/Tor Browser]: update warning on about:tor is not eye-catchy enough

[Tor Bug Tracker & Wiki]

#19270: update warning on about:tor is not eye-catchy enough
--+--
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, UX |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 I think this is a good suggestion. It also raises the question of what is
 the best UX for updates. Right now we have the about:tor arrow, the "Check
 for Updates" menu, and also if the user choose "About Tor Browser", the
 update happens.

 Other approaches might be:
 1. Automatically download updates whenever a new version is available,
 notify user and offer to restart now or later, or
 2. Present the user with a modal dialog to force them to decide whether to
 update now or postpone.

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

Re: [tor-bugs] #20289 [Core Tor]: HS_DESC event while waiting for upload

[Tor Bug Tracker & Wiki]

#20289: HS_DESC event while waiting for upload
-+
 Reporter:  meejah   |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by twim):

 We're going to remove this useless delay in #20082.
 When there is no "artificial" delay it's implied that we are waiting for
 the uploads to finish. Once one created new onion service next step is to
 wait for `HS_DESC UPLOADED`. This is not a deterministic delay - it's
 jitter.
 That's why I don't think there should be one more control event for this.

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

Re: [tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:85 bugzilla]:
 > Replying to [comment:84 gk]:
 > > I think Tor Browser started for all of them (see comment:73,
 comment:75 and I tested it on my machines as well) and it worked with GCC
 6 while it did not without it.
 > Have you seen the requirements for invoking `AvailableMemoryTracker`?

 Yes. Not sure what you want to point out.

 > Have you reverted https://hg.mozilla.org/releases/mozilla-
 aurora/rev/7d7176ca2470 to test `IOInterposer`?

 No. But what I did was compiling our latest 45.4.0esr code once with GCC <
 6 and once with GCC 6 and the latter allowed me to run Tor Browser with
 EMET while the former not. *All* other things were equal.

 > TBB freezes with EAF, nothing to discuss.

 You mean the nightly build I pointed you to? That worked pretty fine for
 me with all the EMET features enabled. Others reported that as well (and I
 assume they had all features enabled, too).

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

Re: [tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 Replying to [comment:84 gk]:
 > I think Tor Browser started for all of them (see comment:73, comment:75
 and I tested it on my machines as well) and it worked with GCC 6 while it
 did not without it.
 Have you seen the requirements for invoking `AvailableMemoryTracker`?
 Have you reverted https://hg.mozilla.org/releases/mozilla-
 aurora/rev/7d7176ca2470 to test `IOInterposer`?
 TBB freezes with EAF, nothing to discuss.
 GCC could improve optimized code with `-g`, but it's not suitable for
 release.

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

Re: [tor-bugs] #20371 [Core Tor/Tor]: Lower HSDir query backoff delay

[Tor Bug Tracker & Wiki]

#20371: Lower HSDir query backoff delay
-+
 Reporter:  twim |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs research  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by dgoulet):

 Oh yeah, 15m is crazy... Just the intro point failure cache is at 5
 minutes which is probably also too high so that one is definitely a bit to
 intense.

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

Re: [tor-bugs] #20291 [Applications/Tor Browser]: Create user experience for security slider on Android (wireframes)

[Tor Bug Tracker & Wiki]

#20291: Create user experience for security slider on Android (wireframes)
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  android, ux-mobile, tbb-mobile  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * cc: brade, mcs (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] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:83 bugzilla]:
 > Newer GCC is a good way to reveal bugs, not to fix, and it's not needed
 if nobody is going to fix them. So nothing has changed, it didn't work
 anyways.
 > It wasn't discovered by testers as
 > > the application freezes very early in the process and does not
 completely start
 > because of ticket:18935#comment:24

 I think Tor Browser started for all of them (see comment:73, comment:75
 and I tested it on my machines as well) and it worked with GCC 6 while it
 did not without 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] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor, 2016-06

[Tor Bug Tracker & Wiki]

#20348: Kazakhstan blocking of vanilla Tor, 2016-06
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 please can you close this ticket? kz no need tor, tor no need kz, if
 anybody want they can to use ultrasurf.

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

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:49 iwakeh]:
 > Replying to [comment:46 karsten]:
 >
 > I found the a good reference for the paths topic: it's in the
 [https://gitweb.torproject.org/collector.git/tree/src/main/resources
 /create-tarballs.sh#n68 create tars script]: [...]

 Indeed, that script reflects what's on the server.

 > The above makes an inconsistency between relay descriptor and bridge
 descriptor paths visible.

 Right.  The reason is that we recently switched from bridge descriptor
 tarballs containing all bridge descriptors to separate tarballs for each
 type.  I didn't change the directory structure to avoid breaking stuff.
 In theory, it would have been an easy change, but going back to a previous
 version would have become more difficult.  And it didn't seem necessary to
 change the directory structure, because nobody would look at it anyway.

 > As the new structure from #20228, i.e. votes also grouped and all dates
 in recent paths are derived from the acquisition time, will be in place
 soon, I'd like to use the 'new way' already for the merge.
 >
 > With these as background the test diff has some soon to be outdated
 corrections (comments added after '//'):
 > > [...]
 >
 > When changing the structure now shouldn't relays and bridges be stored
 in similar ways?  I think the current difference (in 'out') caused some of
 the confusion here.

 Agreed on the acquisition time thing.  We could change that now.

 Regarding the directory structure, as I said above, I didn't think this
 was necessary a few weeks ago, but I see your point that it's confusing
 for contributors.

 So, if we change paths in `out/` now, should we use the exact same
 directory structure as for the `recent/` directory?  Whoever runs a
 CollecTor instance now will have to stop it, move and rename some
 directories, upgrade, and restart.  What we should avoid is change some
 paths now and some more paths in a few weeks.

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

Re: [tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 OK, as nobody cares, then some updates on my comments only:
 `AvailableMemoryTracker` appeared to be a bad thing, despite the
 underlying bug was fixed. Moz devs wondered why they got so few report
 from it by their Telemetry, that's because it hangs the browser reliably
 after several calls.
 Newer GCC is a good way to reveal bugs, not to fix, and it's not needed if
 nobody is going to fix them. So nothing has changed, it didn't work
 anyways.
 It wasn't discovered by testers as
 > the application freezes very early in the process and does not
 completely start
 because of ticket:18935#comment:24
 About `LoadLibraryW`: `PR_LD_LAZY`
 P.S. default for FF is `-Os` or without `-g`.

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

Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by arthuredelstein):

 I forgot to mention that the torbutton patch remains the same,
 ​https://github.com/arthuredelstein/torbutton/commit/19459. Also I'm
 leaving out the maxWidth and maxHeight options for now, because I don't
 think they are likely to be needed.

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

Re: [tor-bugs] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

[Tor Bug Tracker & Wiki]

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * cc: brade, mcs (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] #20306 [Core Tor/Tor]: "Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in th

[Tor Bug Tracker & Wiki]

#20306: "Tor cannot connect to the Internet if ReachableAddresses,
ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please
accept some addresses in these options." when "FascistFirewall 1" is set
+--
 Reporter:  arma|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.9.3-alpha
 Severity:  Normal  | Resolution:
 Keywords:  regression nickm-deferred-20161017  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:  regression => regression nickm-deferred-20161017


Comment:

 This is annoying, but not a regression in 0.2.9. Deferring to 0.3.0.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20306#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20247 [Core Tor/Tor]: crash after closing and opening ipv6 DirPort + OrPort

[Tor Bug Tracker & Wiki]

#20247: crash after closing and opening ipv6 DirPort + OrPort
-+-
 Reporter:  toralf   |  Owner:
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.8
 Severity:  Normal   | Resolution:
 Keywords:  crash 028-backport ipv6 nickm-   |  Actual Points:
  deferred-20161017  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  crash 028-backport ipv6 => crash 028-backport ipv6 nickm-
 deferred-20161017
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


Comment:

 Not a regression in 0.2.9, so it waits for 0.3.0.  (Is this still
 needs_information?)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20247#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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: #15434, #16706, #20267, #18988, ...

[Tor Bug Tracker & Wiki]

Batch modification to #15434, #16706, #20267, #18988, #20070, #20269, #20307 by 
nickm:
keywords to nickm-deferred-20161017
milestone to Tor: 0.3.0.x-final

Comment:
I am fairly sure that these are neither regressions nor major problems. So, 
deferring from 0.2.9. Please let me know if I'm wrong.

--
Tickets URL: 
<https://trac.torproject.org/projects/tor/query?id=15434%2C16706%2C20267%2C18988%2C20070%2C20269%2C20307>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

[Tor Bug Tracker & Wiki]

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:46 karsten]:

 I found the a good reference for the paths topic: it's in the
 [https://gitweb.torproject.org/collector.git/tree/src/main/resources
 /create-tarballs.sh#n68 create tars script]:
 {{{
   $OUTDIR/exit-lists/$YEARONE/$MONTHONE/
   $OUTDIR/exit-lists/$YEARTWO/$MONTHTWO/
   $OUTDIR/torperf/$YEARONE/$MONTHONE/
   $OUTDIR/torperf/$YEARTWO/$MONTHTWO/
   $OUTDIR/relay-descriptors/certs/
   $OUTDIR/relay-descriptors/microdesc/$YEARONE/$MONTHONE
   $OUTDIR/relay-descriptors/microdesc/$YEARTWO/$MONTHTWO
   $OUTDIR/relay-descriptors/consensus/$YEARONE/$MONTHONE
   $OUTDIR/relay-descriptors/consensus/$YEARTWO/$MONTHTWO
   $OUTDIR/relay-descriptors/vote/$YEARONE/$MONTHONE/
   $OUTDIR/relay-descriptors/vote/$YEARTWO/$MONTHTWO/
   $OUTDIR/relay-descriptors/server-descriptor/$YEARONE/$MONTHONE/
   $OUTDIR/relay-descriptors/server-descriptor/$YEARTWO/$MONTHTWO/
   $OUTDIR/relay-descriptors/extra-info/$YEARONE/$MONTHONE/
   $OUTDIR/relay-descriptors/extra-info/$YEARTWO/$MONTHTWO/
   $OUTDIR/bridge-descriptors/$YEARONE/$MONTHONE/statuses/
   $OUTDIR/bridge-descriptors/$YEARTWO/$MONTHTWO/statuses/
   $OUTDIR/bridge-descriptors/$YEARONE/$MONTHONE/server-descriptors/
   $OUTDIR/bridge-descriptors/$YEARTWO/$MONTHTWO/server-descriptors/
   $OUTDIR/bridge-descriptors/$YEARONE/$MONTHONE/extra-infos/
   $OUTDIR/bridge-descriptors/$YEARTWO/$MONTHTWO/extra-infos/
 }}}

 The above makes an inconsistency between relay descriptor and bridge
 descriptor paths visible.

 As the new structure from #20228, i.e. votes also grouped and all dates in
 recent paths are derived from the acquisition time, will be in place soon,
 I'd like to use the 'new way' already for the merge.

 With these as background the test diff has some soon to be outdated
 corrections (comments added after '//'):
 >
 > {{{
 > diff --git
 a/src/test/java/org/torproject/collector/sync/SyncPersistenceTest.java
 b/src/test/java/org/torproject/collector/sync/SyncPersistenceTest.java
 > index ad5ee6a..cdb90b8 100644
 > ---
 a/src/test/java/org/torproject/collector/sync/SyncPersistenceTest.java
 > +++
 b/src/test/java/org/torproject/collector/sync/SyncPersistenceTest.java
 > @@ -58,15 +58,15 @@ public class SyncPersistenceTest {
 >@Parameters
 >public static Collection pathFilename() {
 >  return Arrays.asList(new Object[][] {
 > -{"exit-lists/2016-10-05-19-06-17", // expected recent path  //
 acqu-date, which will be ok
 > +{"exit-lists/2016-09-20-13-02-00", // expected recent path
 >   "exit-lists/2016/09/20/2016-09-20-13-02-00", // expected out
 path
 >   "2016-09-20-13-02-00", // test-filename
 >   Integer.valueOf(1), // expected recent count of descs files
 >   Integer.valueOf(1)}, // expected output count of descs files
 >
 >  {"relay-descriptors/microdescs/consensus-microdesc/"
 > - + "2016-10-05-19-06-17-consensus-microdesc", // acqu-date,
 which will be ok
 > - "relay-descriptors/microdescs/2016/10/consensus-microdesc/"
 > + + "2016-10-02-17-00-00-consensus-microdesc",
 > + "relay-descriptors/microdesc/2016/10/consensus-microdesc/"
 >   + "02/2016-10-02-17-00-00-consensus-microdesc",
 >   "2016-10-02-17-00-00-consensus-microdesc",
 >   Integer.valueOf(1),
 > @@ -74,7 +74,7 @@ public class SyncPersistenceTest {
 >
 >  {"bridge-descriptors/server-descriptors/"
 >   + "2016-10-05-19-06-17-server-descriptors",
 > - "bridge-descriptors/server-descriptor/2016/10/"
 > + "bridge-descriptors/2016/10/server-descriptor/"
 >   + "A/8/A8A5509AD1393C8F36ABD2D8F0DE1BB751926872",
 >   "bridge-2016-10-02-16-09-00-server-descriptors",
 >   Integer.valueOf(1),
 > @@ -88,28 +88,30 @@ public class SyncPersistenceTest {
 >   Integer.valueOf(1),
 >   Integer.valueOf(10)},
 >
 > -{"relay-descriptors/consensuses/2016-10-05-19-06-17-consensus",
 // acqu-date, which will be ok
 > +{"relay-descriptors/consensuses/2016-09-20-13-00-00-consensus",
 >   "relay-
 descriptors/consensus/2016/09/20/2016-09-20-13-00-00-consensus",
 >   "2016-09-20-13-00-00-consensus",
 >   Integer.valueOf(1),
 >   Integer.valueOf(1)},
 >
 >  {"bridge-descriptors/statuses/"
 > 

Re: [tor-bugs] #20385 [Core Tor/Tor]: Module documentation for assorted modules, group 1

[Tor Bug Tracker & Wiki]

#20385: Module documentation for assorted modules, group 1
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  TorCoreTeam201610  |  Actual Points:  2
Parent ID:  #14683 | Points:  2
 Reviewer: |Sponsor:  SponsorU-can
---+
Changes (by nickm):

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


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

[tor-bugs] #20385 [Core Tor/Tor]: Module documentation for assorted modules, group 1

[Tor Bug Tracker & Wiki]

#20385: Module documentation for assorted modules, group 1
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  TorCoreTeam201610
Actual Points:  2 |  Parent ID:  #14683
   Points:  2 |   Reviewer:
  Sponsor:  SponsorU-can  |
--+
 In aae034d13e458dfe82b503d3a1b54b0e5200b6b8 I merged module documentation
 for these modules:
 {{{
   buffers.c circuitstats.c command.c connection_edge.c control.c
   cpuworker.c crypto_curve25519.c crypto_curve25519.h
   crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
   dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
   onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
   protover.c protover.h reasons.c rephist.c replaycache.c
   routerlist.c routerparse.c routerset.c statefile.c status.c
   tor_main.c workqueue.c
 }}}

 Adding this ticket to track 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] #20385 [Core Tor/Tor]: Module documentation for assorted modules, group 1

[Tor Bug Tracker & Wiki]

#20385: Module documentation for assorted modules, group 1
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201610  |  Actual Points:  2
Parent ID:  #14683 | Points:  2
 Reviewer: |Sponsor:  SponsorU-can
---+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #20383 [Core Tor/Tor]: Create a Tor-specific vulnerabilty enumeration scheme

[Tor Bug Tracker & Wiki]

#20383: Create a Tor-specific vulnerabilty enumeration scheme
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * cc: mcs (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] #20184 [Applications/Tor Browser]: OS X builds are still not reproducible on some machines

[Tor Bug Tracker & Wiki]

#20184: OS X builds are still not reproducible on some machines
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-gitian, GeorgKoppen201610,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Replying to [comment:7 gk]:
 > bug_20184_v2 (https://gitweb.torproject.org/user/gk/tor-browser-
 bundle.git/commit/?h=bug_20184_v2=8cb911a5516dd89e99a429d2c2f5912e3a6a326c)
 in my public tor-browser-bundle has a patch up for review.

 This patch looks good to me.

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

Re: [tor-bugs] #19067 [Applications/Quality Assurance and Testing]: Create a testsuite bundle to provide an easy way for users to run the test suite

[Tor Bug Tracker & Wiki]

#19067: Create a testsuite bundle to provide an easy way for users to run the 
test
suite
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201610 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by boklm):

 The differents things I'm planning to do in this ticket are:
 - adding some build scripts to generate bundles containing the testsuite
 and its dependencies, for Linux, Windows, OSX
 - making those builds reproducible
 - adding some process to update the bundle, when some new dependencies
 have been added
 - adding a small GUI allowing to launch tests on Tor Browser, show
 results, and update the testsuite

 In commit f3be72d91a02570c1f1f6f6263e3d94e849bfe94 I started adding build
 scripts to generate a bundle for Linux.

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

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, 030-proposed, |  Actual Points:
  prop224, TorCoreTeam201609 |
Parent ID:  #17238   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by dgoulet):

 Replying to [comment:15 asn]:
 > Nitpicking: do we actually want to call it `direct-connection`? Isn't
 that too vague/general?
 >
 > Why not `single-onion-service`?
 +1

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

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, 030-proposed, |  Actual Points:
  prop224, TorCoreTeam201609 |
Parent ID:  #17238   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by asn):

 Nitpicking: do we actually want to call it `direct-connection`? Isn't that
 too vague/general?

 Why not `single-onion-service`?

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

Re: [tor-bugs] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

[Tor Bug Tracker & Wiki]

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, 030-proposed, |  Actual Points:
  prop224, TorCoreTeam201609 |
Parent ID:  #17238   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-

Comment (by dgoulet):

 Ok so only `direct-connection` flag is enough then? If so, I'll make a
 spec patch for 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] #12820 [Applications/Tor Browser]: Test+Recommend Tor Browser with MS EMET (Enhanced Mitigation Experience Toolkit)

[Tor Bug Tracker & Wiki]

#12820: Test+Recommend Tor Browser with MS EMET (Enhanced Mitigation Experience
Toolkit)
-+-
 Reporter:  mikeperry|  Owner:  gk
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-isec-report,   |  Actual Points:
  GeorgKoppen201610, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by bugzilla):

 As you see, configurations of EMET in
 > All other mitigations work fine (be sure to add "mozjs.dll;xul.dll"
 without quotes to the EAF+ mitigation).
 and comment:9 are different. So you need a proper one to
 > Test+Recommend
 But it's not ready until ticket:18935#comment:24 gets fixed.

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

Re: [tor-bugs] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_revision => 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] #20077 [Core Tor/Tor]: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent

[Tor Bug Tracker & Wiki]

#20077: Make is_sensitive_dir_purpose and purpose_needs_anonymity consistent
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactor, 030-proposed,  |  Actual Points:
  TorCoreTeam201610  |
Parent ID:   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 This looks good to me; I'm going to merge it into 0.3.0.

 I'm thinking of converting the big "if" into a switch statement too.  I'll
 open a separate ticket for that.

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

Re: [tor-bugs] #16624 [Applications/Tor Browser]: Improper key passed to nsHttpChannel::DoInvalidateCacheEntry()?

[Tor Bug Tracker & Wiki]

#16624: Improper key passed to nsHttpChannel::DoInvalidateCacheEntry()?
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mozilla-merge |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> During the cache2 review in #13035, mcs noticed that an empty key was
> being passed to nsHttpChannel::DoInvalidateCacheEntry().
>
> {{{
> nsHttpChannel::DoInvalidateCacheEntry() to use our modified (isolated)
> cache keys. That would involve passing a non-empty string as the second
> parameter to cacheStorage->AsyncDoomURI() within that method. This is not
> new code and not something we patched in the past... and Kathy and I do
> not understand the implications of not patching it. But it seems like the
> wrong key is being used there.
> }}}
>
> I replied:
> {{{
> I have not dug through all of the eviction code (there sure are a lot of
> codepaths involved there), but my initial take is that since Mozilla has
> been using this same extension key to isolate caching for POST requests,
> it probably is not a serious issue to omit it, since the original code
> would have been experiencing similar problems even before our isolation
> made further use of this key...
> }}}
>
> We should ask Mozilla for an opinion. This may be a bug in their code,
> too.

New description:

 During the cache2 review in #13035, mcs noticed that an empty key was
 being passed to nsHttpChannel::DoInvalidateCacheEntry().
 > nsHttpChannel::DoInvalidateCacheEntry() to use our modified (isolated)
 cache keys. That would involve passing a non-empty string as the second
 parameter to cacheStorage->AsyncDoomURI() within that method. This is not
 new code and not something we patched in the past... and Kathy and I do
 not understand the implications of not patching it. But it seems like the
 wrong key is being used there.

 I replied:
 > I have not dug through all of the eviction code (there sure are a lot of
 codepaths involved there), but my initial take is that since Mozilla has
 been using this same extension key to isolate caching for POST requests,
 it probably is not a serious issue to omit it, since the original code
 would have been experiencing similar problems even before our isolation
 made further use of this key...


 We should ask Mozilla for an opinion. This may be a bug in their code,
 too.

--

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

Re: [tor-bugs] #9763 [Applications/Tor Browser]: Torbutton's startup component sometimes doesn't load (no cache isolation)

[Tor Bug Tracker & Wiki]

#9763: Torbutton's startup component sometimes doesn't load (no cache isolation)
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-linkability, tbb-torbutton  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by bugzilla):

 If you check `Display the release notes on updates` in NoScript, you could
 find
 {{{
 [08-09 20:19:31] Torbutton INFO: tor SOCKS isolation catchall:
 https://noscript.net/- via --unknown--:e6426471d0ba12963acf49868a95d24b
 }}}

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

Re: [tor-bugs] #9336 [Applications/Tor Browser]: Odd wyswig schemes without isolation for browserspy.dk

[Tor Bug Tracker & Wiki]

#9336: Odd wyswig schemes without isolation for browserspy.dk
+--
 Reporter:  mikeperry   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-linkability, tbb-firefox-patch  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by bugzilla):

 * severity:   => Normal


Comment:

 Nice ticket to add to Mozilla first-party isolation effort.

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

Re: [tor-bugs] #16624 [Applications/Tor Browser]: Improper key passed to nsHttpChannel::DoInvalidateCacheEntry()?

[Tor Bug Tracker & Wiki]

#16624: Improper key passed to nsHttpChannel::DoInvalidateCacheEntry()?
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mozilla-merge |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * severity:   => Normal


Comment:

 It's time to ask Mozilla (during `mozilla52`).

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

Re: [tor-bugs] #19043 [Core Tor/Tor]: prop224: Implementation of ESTABLISH_INTRO cell

[Tor Bug Tracker & Wiki]

#19043: prop224: Implementation of ESTABLISH_INTRO cell
-+-
 Reporter:  alec.heif|  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, 6.s194, |  Actual Points:
  TorCoreTeam201610, review-group-10 |
Parent ID:  #17241   | Points:  3
 Reviewer:  asn, dgoulet |Sponsor:
 |  SponsorR-must
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Ok I've done a round of review on the merge request.

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

Re: [tor-bugs] #16486 [Applications/Tor Browser]: about:cache page (disk entry) is confusing in Tor Browser

[Tor Bug Tracker & Wiki]

#16486: about:cache page (disk entry) is confusing in Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Maybe, it's time to report it to Mozilla (during `mozilla52`)?

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

Re: [tor-bugs] #16487 [Applications/Tor Browser]: Tor Browser has non private browsing mode related cache entries

[Tor Bug Tracker & Wiki]

#16487: Tor Browser has non private browsing mode related cache entries
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 > When you change your History setting to Never remember history, this is
 equivalent to always being in Private Browsing mode.
 from https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-
 without-history
 and now `Always use private browsing mode` is checked (equal?), but it
 seems it's about windows only :(, i.e. there is no mode of browser, just
 of new windows (Private windows). So that anything not related to a window
 is not in `Private Browsing mode`, e.g. HTTPS-E bug #20195 request is also
 in a cache.

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

Re: [tor-bugs] #20383 [Core Tor/Tor]: Create a Tor-specific vulnerabilty enumeration scheme

[Tor Bug Tracker & Wiki]

#20383: Create a Tor-specific vulnerabilty enumeration scheme
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 https://trac.torproject.org/projects/tor/wiki/TROVE is a work in progress.
 Let's try this process and see how we like 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] #20347 [Applications/Tor Browser]: Put "custom" option on security slider?

[Tor Bug Tracker & Wiki]

#20347: Put "custom" option on security slider?
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [comment:2 arthuredelstein]:
 Finally you've found the right place for `Restore Defaults` button ;)

 This is a general problem of creating UI for different user groups. And
 your solution is correct if you don't want to mix advanced options with
 simple.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20384 [Core Tor/Tor]: TROVE-2016-10-001

[Tor Bug Tracker & Wiki]

#20384: TROVE-2016-10-001
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Placeholder ticket; see #20383 for "TROVE" backronym.  Fix should go out
 in 0.2.9.4-alpha in the next 48 hours.  Severity is "Medium".

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20383 [Core Tor/Tor]: Create a Tor-specific vulnerabilty enumeration scheme

[Tor Bug Tracker & Wiki]

#20383: Create a Tor-specific vulnerabilty enumeration scheme
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We've been bad at reliably getting CVE numbers for stuff, but it's still
 useful for packages to have a "this security issue got fixed by that
 thing" cross reference. So let's make our own. We can even match them up
 to bug numbers and CVE numbers if we want: they aren't mutually exclusive.

 Right now I like TROVE: Tor Registry Of Vulnerabilities and Exposures .
 Any objection?

 If not, I am allocating TROVE-2016-001.

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

Re: [tor-bugs] #20310 [Applications/Tor Browser]: Requests for certificates in Certificate Viewer are sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#20310: Requests for certificates in Certificate Viewer are sent over the 
catch-all
circuit
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by bugzilla):

 All first-party tickets are related. Are you going to squash them all?
 (Do you like the message in bold?)

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

Re: [tor-bugs] #17123 [Applications/Tor Browser]: Request for certificate is sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#17123: Request for certificate is sent over the catch-all circuit
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Requests from webpage `about:neterror` and dialog are different (not
 #20130).

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

Re: [tor-bugs] #17637 [Applications/Tor Browser]: NoScript in Tor-Browser allows all third party domains

[Tor Bug Tracker & Wiki]

#17637: NoScript in Tor-Browser allows all third party domains
--+--
 Reporter:  ctbu  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Giorgio could explain to you why this option is no good and disabled by
 default in NoScript. Who is that one that checked the cascading
 permissions option by default in TBB?

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

Re: [tor-bugs] #20214 [Applications/Tor Browser]: Ultrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

[Tor Bug Tracker & Wiki]

#20214: Ultrasound Cross Device Tracking techniques could be used to launch
deanonymization attacks against some users
--+--
 Reporter:  VasiliosMavroudis |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by VasiliosMavroudis):

 Replying to [comment:7 bugzilla]:


 > Replying to [comment:6 VasiliosMavroudis]:
 >
 > > You seem to imply that it's not possible to use ultrasounds to perform
 this attack. However, there are already a few companies using this
 technology, e.g., SilverPush, Lisnr.
 > >
 > Impossible on non ultrasound-capable hardware/software.

 That is correct. Unfortunately, most commodity devices such as
 smartphones, desktop/laptop speakers, and TVs are all ultrasound-capable,
 making this attack relevant.

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

Re: [tor-bugs] #19899 [Core Tor/Tor]: prop224: Add a consensus param to enable/disable next gen onion service

[Tor Bug Tracker & Wiki]

#19899: prop224: Add a consensus param to enable/disable next gen onion service
+--
 Reporter:  dgoulet |  Owner:  dgoulet
 Type:  enhancement | Status:  accepted
 Priority:  High|  Milestone:  Tor:
|  0.3.0.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  prop224, tor-hs, TorCoreTeam201610  |  Actual Points:  0.1
Parent ID:  #17238  | Points:  1
 Reviewer:  |Sponsor:
|  SponsorR-must
+--
Changes (by dgoulet):

 * keywords:  prop224, tor-hs, TorCoreTeam201609, nickm-deferred-20161005 =>
 prop224, tor-hs, TorCoreTeam201610


Comment:

 As discussed in Seattle, the idea here would be to have a consensus
 parameters _only_ for client and service but not the relay side. If the
 relay supports a feature, it should use it. This will be comparable to the
 same technique we used for ntor handshake using `UseNTorHandshake=1` at
 once. We'll be able to start switching client and services on as we see
 enough of the network supporting correctly prop224.

 Patch for this will come _after_ #17238 is merged.

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

Re: [tor-bugs] #14683 [Core Tor/Tor]: Document medium-scale design of key Tor abstractions

[Tor Bug Tracker & Wiki]

#14683: Document medium-scale design of key Tor abstractions
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-doc, 027-triaged-1-in,   |  Actual Points:
  028-triaged, tor-docs-dev, tor-doc-modules,|
  nickm-check-done-20160905  |
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  SponsorU-must
-+-

Comment (by nickm):

 I documented a lot of this stuff in
 aae034d13e458dfe82b503d3a1b54b0e5200b6b8 ; call it 2 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] #20310 [Applications/Tor Browser]: Requests for certificates in Certificate Viewer are sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#20310: Requests for certificates in Certificate Viewer are sent over the 
catch-all
circuit
--+---
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Yes. I think we can squash both issues in #17310, though as they are
 pretty much related.

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

Re: [tor-bugs] #17637 [Applications/Tor Browser]: NoScript in Tor-Browser allows all third party domains

[Tor Bug Tracker & Wiki]

#17637: NoScript in Tor-Browser allows all third party domains
--+--
 Reporter:  ctbu  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 No need to bother Giorgio. I already said that this behavior is intended:
 if one checks the cascading permissions option then one wants to get it I
 guess.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+--
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Here's a branch: https://gitweb.torproject.org/karsten/metrics-
 db.git/log/?h=task-20380

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

Re: [tor-bugs] #20191 [Core Tor/Tor]: Prevent a recurrence of #20103

[Tor Bug Tracker & Wiki]

#20191: Prevent a recurrence of #20103
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_information => new
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.0.x-final


Comment:

 It would also be possible to make it harder for anything to accidentally
 mess with the routerstatus_t pointers in the nodelist between freeing the
 old networkstatus and making everything point to the new on.

 Also it could be possible to change the order in which the two operations
 happen.

 Also we could look at the stuff that caused the bug, and see if it really
 needed to look at the networkstatus list at all.

 Not in 029 though.

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

Re: [tor-bugs] #20214 [Applications/Tor Browser]: Ultrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

[Tor Bug Tracker & Wiki]

#20214: Ultrasound Cross Device Tracking techniques could be used to launch
deanonymization attacks against some users
--+--
 Reporter:  VasiliosMavroudis |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 Replying to [comment:6 VasiliosMavroudis]:
 > You seem to imply that it's not possible to use ultrasounds to perform
 this attack. However, there are already a few companies using this
 technology, e.g., SilverPush, Lisnr.
 Impossible on non ultrasound-capable hardware/software.

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

Re: [tor-bugs] #20376 [Core Tor/Tor]: Do not mark circs for close again after relay_send_command_from_edge()

[Tor Bug Tracker & Wiki]

#20376: Do not mark circs for close again after relay_send_command_from_edge()
--+
 Reporter:  twim  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * points:   => 0.2
 * milestone:   => Tor: 0.3.0.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] #20314 [Applications/Tor Browser]: Make SVG click-to-play

[Tor Bug Tracker & Wiki]

#20314: Make SVG click-to-play
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  noscript, tbb-usability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 You too dunno how to deal with gk's bugtracker...

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

Re: [tor-bugs] #18807 [Internal Services/Service - trac]: Trac Error: OSError: [Errno 12] Cannot allocate memory

[Tor Bug Tracker & Wiki]

#18807: Trac Error: OSError: [Errno 12] Cannot allocate memory
--+
 Reporter:  bugzilla  |  Owner:  qbi
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by bugzilla):

 Who's there? I just opened the Timeline.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20382 [- Select a component]: atlas doesn't check if all family members list themselves

[Tor Bug Tracker & Wiki]

#20382: atlas doesn't check if all family members list themselves
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  atlas family members
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hello,

 (sorry, english isn't my mother tongue, so please excuse my writing)

 As said in title, atlas isn't checking if all family members list
 themselves, so it leads to some ambiguous results, showing relay being
 part of the same family when it's not the case.

 Below a copy/paste from the IRC (nicknames are anonymized as I didn't ask
 permission to paste the log)


 < mickael> Hello, it seems someone is hijacking my family members, what
 can be done against that? I mean: a node pretends to be part of my family
 but it's wrong. I'm running one single middle node, nothing else.
 < nick1> it doesn't matter.
 < nick1> two nodes are only considered a family if they list each other.
 < mickael> Ok, so even if atlas tells we're part of the same family, there
 is no need to worry ?
 < nick1> probably correct.
 < nick2> sounds like an atlas bug
 < nick3> and even if nodes are in same family, I do not see ~any harm in
 it
 < mickael> nick1: thanks, nick2: do you want me to fill a bug report ?
 < nick4> oh in theory there is harm if you ask me, you would be able to
 make the tor network not use the two nodes in a circuit, no?
 < nick2> mickael: that could be helpful!  I don't maintain atlas, so I
 can't guarantee much, but it is probably a good idea.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+--
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 This sound good.

 Yes, a branch and using md/txt will make work on the doc easier.

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

Re: [tor-bugs] #20328 [Applications/Tor Browser]: No cookies are visible, except...

[Tor Bug Tracker & Wiki]

#20328: No cookies are visible, except...
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 From time to time I see this after being logged in to Trac for several
 days.

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

Re: [tor-bugs] #17637 [Applications/Tor Browser]: NoScript in Tor-Browser allows all third party domains

[Tor Bug Tracker & Wiki]

#17637: NoScript in Tor-Browser allows all third party domains
--+--
 Reporter:  ctbu  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

 * keywords:   => noscript


Comment:

 Then we need an answer from Giorgio whether this behavior is intended or
 could be improved.

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

Re: [tor-bugs] #7130 [Applications/Tor Browser]: Canvas image data is blocked from chrome (such as NoScript's ClearClick)

[Tor Bug Tracker & Wiki]

#7130: Canvas image data is blocked from chrome (such as NoScript's ClearClick)
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by bugzilla):

 The question is about comment:1.

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

Re: [tor-bugs] #20310 [Applications/Tor Browser]: Requests for certificates in Certificate Viewer are sent over the catch-all circuit

[Tor Bug Tracker & Wiki]

#20310: Requests for certificates in Certificate Viewer are sent over the 
catch-all
circuit
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by bugzilla):

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


Comment:

 Nein! It is about Certificate Viewer (Page Info / Security / View
 Certificate):
 [[Image(Certificate Viewer.png)]]
 (also there is a wonderful message ;)

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

Re: [tor-bugs] #20214 [Applications/Tor Browser]: Ultrasound Cross Device Tracking techniques could be used to launch deanonymization attacks against some users

[Tor Bug Tracker & Wiki]

#20214: Ultrasound Cross Device Tracking techniques could be used to launch
deanonymization attacks against some users
--+--
 Reporter:  VasiliosMavroudis |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by VasiliosMavroudis):

 Replying to [comment:3 bugzilla]:

 > At a first glance it looks like OP came here with a tinfoil hat,
 especially as most 44.1/48 kHz formats are not ultrasound capable. But, in
 general, there is some chance to become deanonymized during playback of
 watermarked media (e.g. from YouTube) in a range where compromised devices
 can record the differences in sound.
 >
 > > The prompt would only serve as an annoyance that the user would learn
 to ignore.
 > >
 > Warning as for maximization should be enough.

 You seem to imply that it's not possible to use ultrasounds to perform
 this attack. However, there are already a few companies using this
 technology, e.g., SilverPush, Lisnr.

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

Re: [tor-bugs] #11501 [Obfuscation/Pluggable transport]: Improve visual identity of Tor's PTs

[Tor Bug Tracker & Wiki]

#11501: Improve visual identity of Tor's PTs
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: mcs (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] #18093 [Applications/Tor Browser]: Torbutton UI flow improvement

[Tor Bug Tracker & Wiki]

#18093: Torbutton UI flow improvement
-+-
 Reporter:  bugzilla |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  security-slider, TorBrowserTeam201610R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by gk):

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


Comment:

 Cherry-picked to torbutton master with commit
 7a0efdf6a99969007792d418a6bbfd5e0da4b3cf.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+--
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Good idea!  New first two paragraphs:

 "Welcome to CollecTor, your friendly data-collecting service in the Tor
 network. CollecTor fetches data from various nodes and services in the
 public Tor network and makes it available to the world. This data includes
 relay descriptors from the directory authorities, sanitized bridge
 descriptors from the bridge authority, and other data about the Tor
 network.

 This document describes how to set up your very own CollecTor instance. It
 was written with an audience in mind that has at least some experience
 with running services and is comfortable with the command line. It’s not
 required that you know how to read or even write Java code, though."

 Should I go ahead and create a branch for this, so that we can fine-tune
 the text?  Or would you rather provide more feedback based on the PDF?

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

Re: [tor-bugs] #12820 [Applications/Tor Browser]: Test+Recommend Tor Browser with MS EMET (Enhanced Mitigation Experience Toolkit)

[Tor Bug Tracker & Wiki]

#12820: Test+Recommend Tor Browser with MS EMET (Enhanced Mitigation Experience
Toolkit)
-+-
 Reporter:  mikeperry|  Owner:  gk
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-isec-report,   |  Actual Points:
  GeorgKoppen201610, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-security, tbb-isec-report, GeorgKoppen201610,
 TorBrowserTeam201610 =>
 tbb-security, tbb-isec-report, GeorgKoppen201610,
 TorBrowserTeam201610, ff52-esr
 * sponsor:  SponsorU =>


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

Re: [tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * sponsor:  SponsorU =>


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

Re: [tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x

[Tor Bug Tracker & Wiki]

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-security, tbb-crash, tbb-|  Actual Points:
  usability-stoppoint-app, fuck-mingw-gcc,   |
  GeorgKoppen201609, TorBrowserTeam201610,   |
  ff52-esr   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by gk):

 * status:  closed => reopened
 * keywords:
 tbb-security, tbb-crash, tbb-usability-stoppoint-app, fuck-mingw-gcc,
 GeorgKoppen201609, TorBrowserTeam201610R
 =>
 tbb-security, tbb-crash, tbb-usability-stoppoint-app, fuck-mingw-gcc,
 GeorgKoppen201609, TorBrowserTeam201610, ff52-esr
 * resolution:  fixed =>


Comment:

 We need to wait for switching to GCC 6 as Firefox is not ready yet. :( See
 #20381 for more details. We should revisit the state of GCC 6 support when
 we switch to Firefox 52 ESR.

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

Re: [tor-bugs] #20381 [Applications/Tor Browser]: Tor Browser nightly bundles crash on Linux 64bit systems

[Tor Bug Tracker & Wiki]

#20381: Tor Browser nightly bundles crash on Linux 64bit systems
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  tbb-crash, TorBrowserTeam201610, |  Actual Points:
  GeorgKoppen201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Backing out the patch for #13893 with commit
 48b0c33bf651b972e81490b3896dd332437e and thus reverting GCC back to
 5.1.0

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #20301, #20302

[Tor Bug Tracker & Wiki]

Batch modification to #20301, #20302 by gk:
keywords to TorBrowserTeam201610

Action: new

Comment:
Taking off the review queue as GCC 6 seems to be too unstable to use right now. 
See #20381 for further details.

--
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] #20381 [Applications/Tor Browser]: Tor Browser nightly bundles crash on Linux 64bit systems

[Tor Bug Tracker & Wiki]

#20381: Tor Browser nightly bundles crash on Linux 64bit systems
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201610, |  Actual Points:
  GeorgKoppen201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 It turns out this is GCC 6 related. Mozilla provided patches in bug

 https://bugzilla.mozilla.org/show_bug.cgi?id=1269317 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1269319

 which fixed the problem. They did not get backported to ESR45/Aurora,
 though, as they caused other build bustages, with MSVC and while doing
 builds for Android. We could think about trying to backport those fixes
 ourselves but builds with GCC 6 still seem to be broken until

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

 gets fixed. Thus, this will be too unstable to get into 6.5. We should aim
 for Tor Browser 7.0 earliest for GCC 6. Unfortunately, this means EMET
 support (#13893) will need to wait for another while :(

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20381 [Applications/Tor Browser]: Tor Browser nightly bundles crash on Linux 64bit systems

[Tor Bug Tracker & Wiki]

#20381: Tor Browser nightly bundles crash on Linux 64bit systems
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-crash,
 Severity:  Critical |  TorBrowserTeam201610,
 |  GeorgKoppen201610
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 A couple of hours ago I hit a crash which is reproducible with the
 following backtrace:
 {{{
 Thread 1 "firefox" received signal SIGSEGV, Segmentation fault.
 0x73e2cbe1 in js::jit::SnapshotIterator::numAllocations (
 this=0x7fff6200)
 at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:2159
 2159/home/debian/build/tor-browser/js/src/jit/JitFrames.cpp: Datei
 oder Verzeichnis nicht gefunden.
 (gdb) bt
 #0  0x73e2cbe1 in js::jit::SnapshotIterator::numAllocations (
 this=0x7fff6200)
 at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:2159
 #1  js::jit::IonFrameStackDepthOp::IonFrameStackDepthOp (frame=...,
 this=)
 at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:421
 #2  js::jit::TryNoteIterIon::TryNoteIterIon (frame=..., cx=0x7fffdf71d800,
 this=0x7fff61c0)
 at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:431
 #3  js::jit::HandleExceptionIon (overrecursed=0x7fff60af,
 rfe=0x7fff6660,
 frame=..., cx=0x7fffdf71d800)
 at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:478
 #4  js::jit::HandleException (rfe=0x7fff6660)
 at /home/debian/build/tor-browser/js/src/jit/JitFrames.cpp:853
 }}}
 We did not change anything recently JIT code related.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+--
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [ticket:20380 karsten]:
 > ...
 > I'd also like to remove the current `README.md`, because there should be
 just one document telling operators how to use CollecTor, and we can
 probably expect most operators to know how to use `gpg`.
 >
 > Thoughts?

 Maybe, there should be a new section at the beginning with an audience
 description and the skill set expected?

 And, yes, one expected skill is knowing how to use gpg.

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

Re: [tor-bugs] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+--
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Attached.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

[Tor Bug Tracker & Wiki]

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 In the last week or two we spent some time on writing more complete
 operator's guides for the various metrics services.  This is for our
 October milestone: "Provide user-friendly documentation that empowers
 users to independently operate CollecTor instances."

 I'll attach the latest operator's guide for CollecTor in a minute.  The
 funny whitespace comes from the document being a LaTeX table with
 commented-out columns for the other metrics services.

 I'd like to put the text from that PDF into the current `INSTALL.md`,
 maybe after reformatting some things in Markdown.

 I'd also like to remove the current `README.md`, because there should be
 just one document telling operators how to use CollecTor, and we can
 probably expect most operators to know how to use `gpg`.

 Thoughts?

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

Re: [tor-bugs] #20364 [Metrics/Ooni]: Update debian/ubuntu packages of ooniprobe to 2.0.0

[Tor Bug Tracker & Wiki]

#20364: Update debian/ubuntu packages of ooniprobe to 2.0.0
--+--
 Reporter:  hellais   |  Owner:  irl
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Ooni  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * status:  new => accepted


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

Re: [tor-bugs] #20364 [Metrics/Ooni]: Update debian/ubuntu packages of ooniprobe to 2.0.0

[Tor Bug Tracker & Wiki]

#20364: Update debian/ubuntu packages of ooniprobe to 2.0.0
--+-
 Reporter:  hellais   |  Owner:  irl
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Ooni  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by irl):

 Cool. This might actually lead to simplifying packaging.

 Should the systemd service be installed disabled by default then? Or does
 it do a check on startup that it was wanted by looking at a conf file?

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

Re: [tor-bugs] #20373 [Applications/Tor Browser]: Privacy and Security Settings window opens twice

[Tor Bug Tracker & Wiki]

#20373: Privacy and Security Settings window opens twice
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good to me and fixed with commit
 52fbcbfa9df65d56dce5b1654c4d56012b3ff6a9 on torbutton master.

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

Re: [tor-bugs] #20244 [Applications/Tor Browser]: Move privacy checkboxes to about:preferences#privacy (proposed)

[Tor Bug Tracker & Wiki]

#20244: Move privacy checkboxes to about:preferences#privacy (proposed)
-+-
 Reporter:  arthuredelstein  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-usability, TorBrowserTeam201610  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Alright, that got fixed on tor-browser-45.4.0esr-6.5-1 with commits

 1b92582f7ef5bec693b01bc78672122add405834
 e5c3cd25ed459765a91d1b364151c46afaca36c0

 and on torbutton master with commits

 6d785fa1bf95f997a95b867538ba3353d9a76a58
 aa05941ee0144026fb843b6f5a2098aed5e17b46
 2978978e64fbc9164185564a19d56d5fea0b25d8
 ee88e783a98b22e743b943cc144cb6b79c70706e
 ea0d6dc4ebc59c594162202e142549356075a981
 7f16ada703d07b1b0140eaf12dd3e93864c14568

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

Re: [tor-bugs] #11501 [Obfuscation/Pluggable transport]: Improve visual identity of Tor's PTs

[Tor Bug Tracker & Wiki]

#11501: Improve visual identity of Tor's PTs
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by isis):

 APPROVE. Are we going to make a chibi Hatsune Miku rendition of Loituma?

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