date:20161005

[tor-bugs] #20299 [- Select a component]: Tried to update now tor wont start

2016-10-05 Thread Tor Bug Tracker & Wiki

#20299: Tried to update now tor wont start
--+-
 Reporter:  lfresh|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 this is the error message:

 Tor exited during startup. This might be due to an error in your torrc
 file, a bug in Tor or another program on your system, or faulty hardware.
 Until you fix the underlying problem and restart Tor, Tor Browser will not
 start.


 there are 0 tor logs to show unfortunately and i have no idea what the
 problem is. i've tossed the old brpawser tried to download a new one
 still stuck

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

Re: [tor-bugs] #20296 [Applications/Tor Browser]: Rotate default obfs4 bridges again

2016-10-05 Thread Tor Bug Tracker & Wiki

#20296: Rotate default obfs4 bridges again
---+---
 Reporter:  lynntsai   |  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201610R tbb-bridges  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dcf):

 * status:  new => needs_review
 * keywords:  TorBrowserTeam201609R tbb-bridges => TorBrowserTeam201610R
 tbb-bridges


Comment:

 The 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] #20023 [Applications/Tor Browser]: Upgrade Go to 1.7.1

2016-10-05 Thread Tor Bug Tracker & Wiki

#20023: Upgrade Go to 1.7.1
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 Replying to [comment:2 dcf]:
 > I'm testing a build of the attached patches now. If they work, I'll mark
 this ticket needs_review.

 The build failed for me, during the building of go1.7.1 in the mac
 pluggable-transports descriptor, in the `make.bash` command. I haven't
 figured out what went wrong yet. The exit status was 2. The last few lines
 of output were
 {{{
 cmd/compile/internal/x390x
 cmd/compile/internal/x86
 cmd/yacc
 cmd/compile
 }}}

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

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

2016-10-05 Thread Tor Bug Tracker & Wiki

#20195: HTTPS Everywhere's SSL Observatory code doesn't honor domain isolation.
-+-
 Reporter:  yawning  |  Owner:  legind
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability  |  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] #20298 [Applications/Tor Messenger]: Tor Messenger: OTR not working with macOS Sierra

2016-10-05 Thread Tor Bug Tracker & Wiki

#20298: Tor Messenger: OTR not working with macOS Sierra
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  otr |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 I should note that I've successfully used that version of TM on Sierra, so
 this is likely something specific to your environment (or, mine).

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

Re: [tor-bugs] #20298 [Applications/Tor Messenger]: Tor Messenger: OTR not working with macOS Sierra

2016-10-05 Thread Tor Bug Tracker & Wiki

#20298: Tor Messenger: OTR not working with macOS Sierra
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  otr |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 It sounds like the ctypes-otr extension is failing to load.  You'd need to
 scroll all the way to the top of the error console to see the errors
 related to loading the extension.

 I'm wondering if this is related to, https://github.com/arlolra/ctypes-
 otr/issues/91

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

Re: [tor-bugs] #20297 [Applications/Tor Messenger]: Tor Messenger: error messages with|without HTML formatting

2016-10-05 Thread Tor Bug Tracker & Wiki

#20297: Tor Messenger: error messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by sukhbir):

 Replying to [comment:4 arlolra]:
 > Ps. the reason you're seeing these at all, is because of #20298 where we
 find out the ctypes-otr isn't enabled for you for some reason.

 Yeah so I am guessing it's related more to that than to comment:3.

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

Re: [tor-bugs] #20297 [Applications/Tor Messenger]: Tor Messenger: error messages with|without HTML formatting

2016-10-05 Thread Tor Bug Tracker & Wiki

#20297: Tor Messenger: error messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Ps. the reason you're seeing these at all, is because of #20298 where we
 find out the ctypes-otr isn't enabled for you for some reason.

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

Re: [tor-bugs] #20297 [Applications/Tor Messenger]: Tor Messenger: error messages with|without HTML formatting

2016-10-05 Thread Tor Bug Tracker & Wiki

#20297: Tor Messenger: error messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Thanks for reporting!

 See the commit msg here, https://github.com/arlolra/ctypes-
 otr/commit/26d384d8407c2fd5ad3797fad5f599ae28acb4b4

 The dead link to https://bugs.otr.im/issues/79 is now
 https://bugs.otr.im/lib/libotr/issues/79
 I'm not sure where my patch disappeared to there, but there used to be a
 fix that was awaiting review.  I could maybe just apply it to the
 libotr.so we're shipping, but I'd rather wait on them to give it the ok.

 Basically, the one that doesn't have formatting is from when arma manually
 triggered the query message to start the conversation.

 The second one, with the formatting, is the one that libotr send
 automatically when you type a message before the OTR session is started,
 and encrypting is enforced.

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

Re: [tor-bugs] #20297 [Applications/Tor Messenger]: Tor Messenger: error messages with|without HTML formatting

2016-10-05 Thread Tor Bug Tracker & Wiki

#20297: Tor Messenger: error messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by sukhbir):

 Related: #20298.

 (I can't reproduce this on sierra, but since there is no OTR menu I am
 guessing the issue lies there).

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

[tor-bugs] #20298 [Applications/Tor Messenger]: Tor Messenger: OTR not working with macOS Sierra

2016-10-05 Thread Tor Bug Tracker & Wiki

#20298: Tor Messenger: OTR not working with macOS Sierra
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:  otr
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 It seems like Tor Messenger 0.2.0b2 doesn't support OTR with macOS Sierra
 10.12.

 I'm on k2r67kry5haud25b.onion on the default port specified by Tor
 Messenger (5299?). I've been online for about an hour now, so I don't
 think it should still be generating keys.

 What's odd is that under "Tools" I don't see "OTR preferences."

 I've checked the error console, but there are no errors relating to OTR.

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

Re: [tor-bugs] #20297 [Applications/Tor Messenger]: Tor Messenger: error messages with|without HTML formatting

2016-10-05 Thread Tor Bug Tracker & Wiki

#20297: Tor Messenger: error messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by sukhbir):

 * cc: sukhbir (added)


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

[tor-bugs] #20297 [Applications/Tor Messenger]: Tor Messenger: error messages with|without HTML formatting

2016-10-05 Thread Tor Bug Tracker & Wiki

#20297: Tor Messenger: error messages with|without HTML formatting
+-
 Reporter:  lnl |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Minor   |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 I'm using Tor Messenger 0.2.0b2 on macOS Sierra 10.12.

 I've gotten the same error, but sometimes, it displays as:

 " has requested an Off-the Record private conversation. However,
 you do not have a plugin to support that. See http://otr.cypherpunks.ca/
 for more information."

 And other times, it displays as (I see the HTML formatting as plaintext):

 " has requested an https://otr.cypherpunks.ca
 /">Off-the-Record private conversation.  However, you do not have a
 plugin to support that.
 See https://otr.cypherpunks.ca/;>https://otr.cypherpunks.ca/;
 for more information."

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

Re: [tor-bugs] #17480 [Applications/Tor Messenger]: Make URL linkification togglable with a pref

2016-10-05 Thread Tor Bug Tracker & Wiki

#17480: Make URL linkification togglable with a pref
+-
 Reporter:  anonym  |  Owner:  sukhbir
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  AffectsTails|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by arlolra):

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


Comment:

 This was always toggleable in Preferences > Content > Formattings, but the
 settings beyond `none` were rather permissive.  I've narrowed down the
 options to `none`, which is still the above very restrictive patch, and
 now `basic`, which fulfills the ask in this ticket.  Thanks.

 New patch is,
 https://gitweb.torproject.org/tor-messenger-
 build.git/commit/?id=233e7b23770f4c89d637e0db4d23ca2d6f0a512a

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20296 [Applications/Tor Browser]: Rotate default obfs4 bridges again

2016-10-05 Thread Tor Bug Tracker & Wiki

#20296: Rotate default obfs4 bridges again
-+-
 Reporter:  lynntsai |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201609R
 Severity:  Normal   |  tbb-bridges
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Link: https://lists.torproject.org/pipermail/tor-
 project/2016-August/000664.html

 We would like to rotate the ports again for the next release. The previous
 ports will remain open and functional.

 This is the second rotation, first one can be seen in ticket # 20092 here:
 https://trac.torproject.org/projects/tor/ticket/20092

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

Re: [tor-bugs] #20043 [Applications/Tor Browser]: SharedWorker uses catchall circuit

2016-10-05 Thread Tor Bug Tracker & Wiki

#20043: SharedWorker uses catchall circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:11 mcs]:
 > Kathy and I are okay with these changes. It would be clearer to us to
 use a comparison like `aWorkerType == WorkerTypeShared` instead of the
 less obvious `aLoadGroupBehavior == OverrideLoadGroup` (if it would work).

 Good point. I added a test for WorkerTypeService for completeness,
 although we have WorkerTypeService disabled, and this patch will likely be
 excluded from the TBB/ESR52 release.

 https://github.com/arthuredelstein/tor-browser/commits/20043+3

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

Re: [tor-bugs] #7349 [Core Tor/Tor]: Obfsbridges should be able to "disable" their ORPort

2016-10-05 Thread Tor Bug Tracker & Wiki

#7349: Obfsbridges should be able to "disable" their ORPort
-+-
 Reporter:  asn  |  Owner:  isis
 Type:  project  | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge SponsorZ tor-pt   |  Actual Points:
  proposal-needed 028-triage |
Parent ID:   | Points:  9000+
 Reviewer:   |Sponsor:
-+-
Changes (by mrphs):

 * cc: mrphs (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] #20111 [Applications/Tor Browser]: use Unix domain sockets for SOCKS port by default

2016-10-05 Thread Tor Bug Tracker & Wiki

#20111: use Unix domain sockets for SOCKS port by default
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-torbutton, tbb-security, TorBrowserTeam201610R => tbb-
 torbutton, tbb-security, TorBrowserTeam201610
 * status:  needs_information => needs_revision


Comment:

 Kathy and I are going to revise these patches to account for the #18753
 fix.

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

Re: [tor-bugs] #20043 [Applications/Tor Browser]: SharedWorker uses catchall circuit

2016-10-05 Thread Tor Bug Tracker & Wiki

#20043: SharedWorker uses catchall circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Kathy and I are okay with these changes. It would be clearer to us to use
 a comparison like `aWorkerType == WorkerTypeShared` instead of the less
 obvious `aLoadGroupBehavior == OverrideLoadGroup` (if it would work).

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

Re: [tor-bugs] #20043 [Applications/Tor Browser]: SharedWorker uses catchall circuit

2016-10-05 Thread Tor Bug Tracker & Wiki

#20043: SharedWorker uses catchall circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Replying to [comment:9 gk]:
 > Looks good to me. I am still not sure I understand why you suddenly need
 to add `worker.js` to the `suffixes` list, too. Could you elaborate?

 Good observation. It's because I should have included it before, but
 failed to do so.

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

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

2016-10-05 Thread Tor Bug Tracker & Wiki

#13893: Torbrowser crashes on start when using MS EMET 5.x
-+-
 Reporter:  Diapolo  |  Owner:  gk
 Type:  defect   | Status:
 |  needs_review
 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, TorBrowserTeam201610R   |
Parent ID:  #12820   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 r=mcs
 Both the tor-browser and tor-browser-bundle changes look okay as far as I
 can tell.

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

Re: [tor-bugs] #19904 [Core Tor/Tor]: evutil_secure_rng_add_bytes() not present in openbsd libevent 2

2016-10-05 Thread Tor Bug Tracker & Wiki

#19904: evutil_secure_rng_add_bytes() not present in openbsd libevent 2
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  openbsd, TorCoreTeam201608  |  Actual Points:  0
Parent ID:  | Points:  0
 Reviewer:  |Sponsor:
+--

Comment (by rubiate):

 Nope, it can't find evutil_secure_rng_add_bytes or
 evutil_secure_rng_set_urandom_device_file because it's still looking with
 -levent

 configure:8355: checking for evutil_secure_rng_set_urandom_device_file
 configure:8355: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include
 -I${top_srcdir}/src/common -L/usr/local/lib  conftest.c -levent
 -lpthread  >&5
 /tmp//cc7rk6IF.o: In function `main':
 /tor/conftest.c:99: undefined reference to
 `evutil_secure_rng_set_urandom_device_file'
 [...]
 configure:8355: checking for evutil_secure_rng_add_bytes
 configure:8355: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include
 -I${top_srcdir}/src/common -L/usr/local/lib  conftest.c -levent
 -lpthread  >&5
 /tmp//cc2XrDZc.o: In function `main':
 /tor/conftest.c:99: undefined reference to
 `evutil_secure_rng_add_bytes'

 With things moved around, it can find
 evutil_secure_rng_set_urandom_device_file

 configure:8507: checking for evutil_secure_rng_set_urandom_device_file
 configure:8507: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include
 -I${top_srcdir}/src/common -L/usr/local/lib  conftest.c -levent_extra
 -levent_core   -lpthread  >&5
 configure:8507: $? = 0
 configure:8507: result: yes
 [...]
 configure:8507: checking for evutil_secure_rng_add_bytes
 configure:8507: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include
 -I${top_srcdir}/src/common -L/usr/local/lib  conftest.c -levent_extra
 -levent_core   -lpthread  >&5
 /tmp//ccmjPCe2.o: In function `main':
 /tor/conftest.c:103: undefined reference to
 `evutil_secure_rng_add_bytes'


 Updated to apply against current master:

 {{{
 diff --git a/configure.ac b/configure.ac
 index f6edb3a..23371d3 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -490,21 +490,17 @@ void *event_init(void);],
  event_init();
  ], [--with-libevent-dir], [/opt/libevent])

 -dnl Now check for particular libevent functions.
 +dnl Determine the incantation needed to link libevent.
  save_LIBS="$LIBS"
  save_LDFLAGS="$LDFLAGS"
  save_CPPFLAGS="$CPPFLAGS"
 -LIBS="-levent $STATIC_LIBEVENT_FLAGS $TOR_LIB_WS32 $LIBS"
 +
 +LIBS="$STATIC_LIBEVENT_FLAGS $TOR_LIB_WS32 $save_LIBS"
  LDFLAGS="$TOR_LDFLAGS_libevent $LDFLAGS"
  CPPFLAGS="$TOR_CPPFLAGS_libevent $CPPFLAGS"
 -AC_CHECK_FUNCS([evutil_secure_rng_set_urandom_device_file \
 -evutil_secure_rng_add_bytes \
 -])

  AC_CHECK_HEADERS(event2/event.h event2/dns.h event2/bufferevent_ssl.h)

 -LIBS="$STATIC_LIBEVENT_FLAGS $TOR_LIB_WS32 $save_LIBS"
 -
  if test "$enable_static_libevent" = "yes"; then
 if test "$tor_cv_library_libevent_dir" = "(system)"; then
   AC_MSG_ERROR("You must specify an explicit --with-libevent-dir=x
 option when using --enable-static-libevent")
 @@ -527,6 +523,11 @@ else
   fi
  fi

 +dnl Now check for particular libevent functions.
 +AC_CHECK_FUNCS([evutil_secure_rng_set_urandom_device_file \
 +evutil_secure_rng_add_bytes \
 +])
 +
  LIBS="$save_LIBS"
  LDFLAGS="$save_LDFLAGS"
  CPPFLAGS="$save_CPPFLAGS"
 }}}

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

Re: [tor-bugs] #20295 [Internal Services/Service - git]: Git onion server is down (was: GIt server is down)

2016-10-05 Thread Tor Bug Tracker & Wiki

#20295: Git onion server is down
-+
 Reporter:  larsl|  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 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

[tor-bugs] #20295 [Internal Services/Service - git]: GIt server is down

2016-10-05 Thread Tor Bug Tracker & Wiki

#20295: GIt server is down
-+
 Reporter:  larsl|  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:   |
-+
 The Git server at dccbbv6cooddgcrq.onion has been down since at least
 2016-10-04 18:29 UTC. Trying to do a 'torsocks git pull' gives me the
 error message:

 [Oct 05 19:40:19] ERROR torsocks[8594]: Host unreachable (in
 socks5_recv_connect_reply() at socks5.c:528)
 fatal: unable to access
 'http://dccbbv6cooddgcrq.onion/user/isis/tor.git/': Couldn't connect to
 server

 Trying to load the address in Tor Browser gives me several minutes of
 'Connecting...' and then 'The connection has timed out'.

 This address is listed on http://yz7lpwfhhzcdyc5y.onion/ as an onion
 mirror of git.torproject.org. I have been able to pull from it before so I
 don't think it's a configuration error on my side.

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

Re: [tor-bugs] #20288 [Core Tor/Tor]: Use correct arguments to tor_calloc

2016-10-05 Thread Tor Bug Tracker & Wiki

#20288: Use correct arguments to tor_calloc
--+
 Reporter:  mfrw  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.3-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

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

2016-10-05 Thread 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 isabela):

 * type:  defect => task


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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)

2016-10-05 Thread Tor Bug Tracker & Wiki

#20291: Create user experience for security slider on Android (wireframes)
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  defect  | 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:
+--
Description changed by isabela:

Old description:

> '''Background:'''
>
> We got a small grant to start implementing Tor Button into Orfox and for
> it we plan to also bring the security slider feature.
>
> We are not bringing the other features from Tor Button just yet. But we
> do have plans to do and have applied for more grant to do so.
>
> You can find more information about this project and it's roadmap here:
>
> https://trac.torproject.org/projects/tor/wiki/org/teams/ApplicationsTeam/TorBrowserAndroid/Roadmap
>
> 
> '''Work:'''
>
> The attached pdf and OmniGraffle source file were created based on
> multiple conversations during Tor Meeting in Seattle (Sept 2016).
>
> It shows current user path for general settings and how they get to
> privacy settings.
>
> It also contains a suggested experience for when we bring Tor Button and
> the Security Slider that follows the standard flow from the application.
>
> With lack of landscape to work on we had to make some changes such as:
>
>  * horizontal slider - instead of vertical
>  * combine both medium options - saved space and it will also be less
> confuse to the user if we just display 'low, medium, high'. (Tor Browser
> Desktop will also make such change)
>  * we reorganized the way we present the description of each security
> level
>* presenting a short description giving a highlight of what that level
> means
>* organized each item from previous description into group so the user
> can make the connection of what that action will affect in their
> experience

New description:

 '''Background:'''

 We got a small grant to start implementing Tor Button into Orfox and for
 it we plan to also bring the security slider feature.

 We are not bringing the other features from Tor Button just yet. But we do
 have plans to do so, and have applied for more a grant to fund this work.

 You can find more information about this project and it's roadmap here:

 
https://trac.torproject.org/projects/tor/wiki/org/teams/ApplicationsTeam/TorBrowserAndroid/Roadmap

 
 '''Work:'''

 The attached pdf and OmniGraffle source files (zip) were created based on
 multiple conversations during Tor Meeting in Seattle (Sept 2016).

 It shows the current user path for general settings and how they get to
 privacy settings.

 It also contains a suggested experience for when we bring Tor Button and
 the Security Slider that follows the standard flow from the application.

 With lack of landscape to work on we had to make some changes such as:

  * horizontal slider - instead of vertical
  * combine both medium options - saved space and it will also be less
 confuse to the user if we just display 'low, medium, high'. (Tor Browser
 Desktop will also make such change)
  * we reorganized the way we present the description of each security
 level
* presenting a short description giving a highlight of what that level
 means
* organized each item from previous description into group so the user
 can make the connection of what that action will affect in their
 experience

--

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

Re: [tor-bugs] #20188 [Core Tor/Tor]: hsfetch hs_desc FAILED with REASON missing

2016-10-05 Thread Tor Bug Tracker & Wiki

#20188: hsfetch hs_desc FAILED with REASON missing
--+
 Reporter:  grarpamp  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 This would be good-to-have in 0.2.9 -- does anybody want to spec it up and
 implement it in the next 10 days? Else it will have to wait for 0.3.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] #20266 [Core Tor/Tor]: Provide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.1

2016-10-05 Thread Tor Bug Tracker & Wiki

#20266: Provide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.1
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, openssl  |  Actual Points:  .1
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * actualpoints:   => .1


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

Re: [tor-bugs] #20266 [Core Tor/Tor]: Provide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.1

2016-10-05 Thread Tor Bug Tracker & Wiki

#20266: Provide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.1
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, openssl  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Like this?  (see my branch `bug20266_028`.)  Though actually, I think we
 should consider this as a possible "wontfix" for these reasons:

   1. It's been like this since at least 0.2.8; maybe even since 0.2.7.
 This is the first time somebody complained afaik. :)
   2. OpenSSL 1.0.0 has not been supported since 31 Dec 2015, and is no
 longer getting security updates.

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

Re: [tor-bugs] #20270 [Core Tor/Tor]: "Descriptor is missing an ntor curve25519 onion key" message too noisy?

2016-10-05 Thread Tor Bug Tracker & Wiki

#20270: "Descriptor is missing an ntor curve25519 onion key" message too noisy?
--+
 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:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 >So I think maybe I *do* want to hear about relays that I refused due to
 lack of an ntor curve onion key, but only the ones that had a satisfactory
 version string?

 Sounds reasonable to me.

 I'd be glad to take a patch here for 029 if somebody writes one by the
 15th. Else it can wait till 030.

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

Re: [tor-bugs] #18357 [Core Tor/Tor]: HiddenServicePort IPv6 broken

2016-10-05 Thread Tor Bug Tracker & Wiki

#18357: HiddenServicePort IPv6 broken
--+
 Reporter:  sega01|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.10
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-hs  |  Actual Points:  .1
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by nickm):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #18357 [Core Tor/Tor]: HiddenServicePort IPv6 broken

2016-10-05 Thread Tor Bug Tracker & Wiki

#18357: HiddenServicePort IPv6 broken
--+
 Reporter:  sega01|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.10
 Severity:  Normal| Resolution:
 Keywords:  ipv6, tor-hs  |  Actual Points:  .1
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted
 * actualpoints:   => .1


Comment:

 I think that the problem lies in the test in conmnection_exit_connect().
 The parentheses are wrong. We should allow rendezvous connections to IPv6
 addresses even when IPv6Exit is false, right?

 I've tried rewriting this test to be correct and easier to read; please
 review and test my branch bug18357?

 (This code is not tested.)

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

Re: [tor-bugs] #19926 [Core Tor/Tor]: BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :*

2016-10-05 Thread Tor Bug Tracker & Wiki

#19926: BUG warning in connection_ap_attach_pending: waiting for rendezvous 
desc :*
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  bug, regression?  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => new


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

Re: [tor-bugs] #19926 [Core Tor/Tor]: BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :*

2016-10-05 Thread Tor Bug Tracker & Wiki

#19926: BUG warning in connection_ap_attach_pending: waiting for rendezvous 
desc :*
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  bug, regression?  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => assigned
 * owner:  nickm =>


Comment:

 oh darn that was the wrong ticket.  Please ignore previous messages.

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

Re: [tor-bugs] #19926 [Core Tor/Tor]: BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :*

2016-10-05 Thread Tor Bug Tracker & Wiki

#19926: BUG warning in connection_ap_attach_pending: waiting for rendezvous 
desc :*
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  bug, regression?  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted
 * actualpoints:   => .1


Comment:

 I think that the problem lies in the test in conmnection_exit_connect().
 The parentheses are wrong.  We should allow rendezvous connections to IPv6
 addresses even when IPv6Exit is false, right?

 I've tried rewriting this test to be correct and easier to read; please
 review and test my branch `bug19926`?

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

Re: [tor-bugs] #19926 [Core Tor/Tor]: BUG warning in connection_ap_attach_pending: waiting for rendezvous desc :*

2016-10-05 Thread Tor Bug Tracker & Wiki

#19926: BUG warning in connection_ap_attach_pending: waiting for rendezvous 
desc :*
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  bug, regression?  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


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

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

2016-10-05 Thread Tor Bug Tracker & Wiki

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

Comment (by yawning):

 Replying to [comment:10 gk]:
 > Alright, so here is what is going on. First, do you see the weird
 floating point number thing appended to the `#` in the
 `check.torproject.org` URL? Torbutton does not do such things. It turns
 out this is part if the HTTPS-Everywhere SSL Observatory code where it
 checks whether Tor is available and to use (e.g. for submissions). As a
 sidenode: one does see the issue in the Tor Browser log as well without
 pcaps. It is visible there that the request does not go over the catch-all
 circuit but rather is put on one without any username/password isolation
 at all.

 Nice catch.

 Is there a ticket for "SSL Observatory makes at least one network request
 on startup to check proxy settings, even if it's disabled"?  If "Use the
 Observatory?" isn't checked, this request shouldn't be made at all, but as
 it stands absolutely everyone (with working SSL-Observatory) is hitting
 this bug.

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

Re: [tor-bugs] #20226 [Core Tor/Tor]: Support DNS-MX resource records with .onion-filtering for TOR as secure/anonymous email transport protocoll

2016-10-05 Thread Tor Bug Tracker & Wiki

#20226: Support DNS-MX resource records with .onion-filtering for TOR as
secure/anonymous email transport protocoll
-+-
 Reporter:  renne|  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  email, DNS, MX, resource record, |  Actual Points:
  nickm-deferred-20161005|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  email, DNS, MX, resource record => email, DNS, MX, resource
 record, nickm-deferred-20161005
 * priority:  High => Medium
 * milestone:  Tor: 0.2.9.x-final => Tor: unspecified


Comment:

 This would make sense to do as part of any more general DNS-type
 expansion.  Not time before the 029 freeze, though.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20226#comment:1>
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] #19904 [Core Tor/Tor]: evutil_secure_rng_add_bytes() not present in openbsd libevent 2

2016-10-05 Thread Tor Bug Tracker & Wiki

#19904: evutil_secure_rng_add_bytes() not present in openbsd libevent 2
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  openbsd, TorCoreTeam201608  |  Actual Points:  0
Parent ID:  | Points:  0
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  new => needs_information


Comment:

 (I'm not sure this was actually true; did we fix this along with the other
 libevent2 issues on OpenBSD?)

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

Re: [tor-bugs] #17049 [Core Tor/Tor]: This platform is missing getrlimit(). Increase the number of connections in Windows

2016-10-05 Thread Tor Bug Tracker & Wiki

#17049: This platform is missing getrlimit(). Increase the number of 
connections in
Windows
-+--
 Reporter:  TORques  |  Owner:  lunar
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  nickm-deferred-20161005  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by nickm):

 * keywords:   => nickm-deferred-20161005
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.2.???


Comment:

 I'd take a patch to display a more useful warning message here, if
 somebody wants to write one?  I'd prefer that it be somebody with windows
 experience, so that we get the message right.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17049#comment:8>
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: #8453, #19877, #19878, #19879, ...

2016-10-05 Thread Tor Bug Tracker & Wiki

Batch modification to #8453, #19877, #19878, #19879, #19880, #19881, #19882, 
#19883, #19884, #19886, #19887, #19888, #19889, #20060 by nickm:
keywords to nickm-deferred-20161005
milestone to Tor: 0.3.0.x-final

Comment:
Deferring more things -- even ones I love -- to 0.3.0. Please argue if I'm 
wrong.

--
Tickets URL: 
<https://trac.torproject.org/projects/tor/query?id=8453%2C19877%2C19878%2C19879%2C19880%2C19881%2C19882%2C19883%2C19884%2C19886%2C19887%2C19888%2C19889%2C20060>
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: #18571, #18572, #18637, #19899, ...

2016-10-05 Thread Tor Bug Tracker & Wiki

Batch modification to #18571, #18572, #18637, #19899, #17295, #19162, #19205, 
#18295, #18515, #15054, #15056, #8018, #10218, #16852, #19301, #19302, #19333, 
#20168, #15055, #16861, #17592, #17604, #17238, #17262, #14881, #18320, #18933, 
#19024, #19487, #19552, #19858, #20004 by nickm:
keywords to nickm-deferred-20161005
milestone to Tor: 0.3.0.x-final

Comment:
Deferring big/risky-feature things (even the ones I really love!) to 0.3.0. 
Please argue if I'm wrong.

--
Tickets URL: 
<https://trac.torproject.org/projects/tor/query?id=18571%2C18572%2C18637%2C19899%2C17295%2C19162%2C19205%2C18295%2C18515%2C15054%2C15056%2C8018%2C10218%2C16852%2C19301%2C19302%2C19333%2C20168%2C15055%2C16861%2C17592%2C17604%2C17238%2C17262%2C14881%2C18320%2C18933%2C19024%2C19487%2C19552%2C19858%2C20004>
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: #10688, #18189, #12668, #15521

2016-10-05 Thread Tor Bug Tracker & Wiki

Batch modification to #10688, #18189, #12668, #15521 by nickm:
milestone to Tor: 0.2.9.x-final

Action: resolve

Comment:
The bufferevents code and corresponding build options have been removed in 
0.2.9.2-alpha

--
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] #15935 [Core Tor/Tor]: Implement an advisory-only request to stop for old clients

2016-10-05 Thread Tor Bug Tracker & Wiki

#15935: Implement an advisory-only request to stop for old clients
-+-
 Reporter:  teor |  Owner:
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  SponsorS, needs-proposal,|  implemented
  028-triage, SponsorU-deferred  |  Actual Points:
  TorCoreTeam201609  |
Parent ID:  #15940   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => closed
 * keywords:  SponsorS, needs-proposal, 028-triage, SponsorU-deferred =>
 SponsorS, needs-proposal, 028-triage, SponsorU-deferred
 TorCoreTeam201609
 * resolution:   => implemented
 * severity:   => Normal
 * milestone:  Tor: 0.2.??? => Tor: 0.2.9.x-final


Comment:

 This falls out as a consequence of proposals 264 and 271, both implemented
 in 0.2.9

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

Re: [tor-bugs] #17528 [Applications/Tor Messenger]: Summarize Tor Messenger protocols

2016-10-05 Thread Tor Bug Tracker & Wiki

#17528: Summarize Tor Messenger protocols
+-
 Reporter:  sukhbir |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 We did a bit of this at the recent meeting in Seattle (though not entirely
 this ticket's ask),
 
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeeting/Notes/Messaging
 #WhatmakesaTor-enabledMessengerToday

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20294 [Applications/Tor Messenger]: Don't publish vcards to servers

2016-10-05 Thread Tor Bug Tracker & Wiki

#20294: Don't publish vcards to servers
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Part of the metadata reduction possibilities

 
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeeting/Notes/Messaging#MetadataReductionPossibilities

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20293 [Applications/Tor Messenger]: Don't publish buddy list / Rosterless communication

2016-10-05 Thread Tor Bug Tracker & Wiki

#20293: Don't publish buddy list / Rosterless communication
+-
 Reporter:  arlolra |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Part of the metadata reduction possibilities

 
https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeeting/Notes/Messaging#MetadataReductionPossibilities

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

Re: [tor-bugs] #18753 [Core Tor/Tor]: Unix socket paths cannot contain spaces

2016-10-05 Thread Tor Bug Tracker & Wiki

#18753: Unix socket paths cannot contain spaces
+--
 Reporter:  special |  Owner:  nickm
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  nickm-deferred-20160905, tbb-needs  |  Actual Points:  1
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 This change should work for Tor Browser. We need to modify Tor Launcher to
 use the new quoted syntax for the `ControlPort` and `SocksPort` options,
 and we need to modify Torbutton to correctly parse responses to `GETINFO
 net/listeners/socks`. But Kathy and I made enough of a start on the Tor
 Launcher and Torbutton changes to convince ourselves that this tor patch
 works.

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

Re: [tor-bugs] #20292 [Core Tor/Tor]: Update to October GeoIP2 database

2016-10-05 Thread Tor Bug Tracker & Wiki

#20292: Update to October GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-relay 024-backport|  Actual Points:
  025-backport 026-backport 027-backport |
  028-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * status:  new => needs_review


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

[tor-bugs] #20292 [Core Tor/Tor]: Update to October GeoIP2 database

2016-10-05 Thread Tor Bug Tracker & Wiki

#20292: Update to October GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:
 Type:   | Status:  new
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-client tor-relay 024-backport
 Severity:  Normal   |  025-backport 026-backport 027-backport
 |  028-backport
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 [https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-oct2016
 geoip-oct2016] contains the updated `geoip` and `geoip6` files with IPv4
 and IPv6 ranges and is supposed to be merged into maint-0.2.4 and all
 other relevant branches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2016-10-05 Thread Tor Bug Tracker & Wiki

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

Comment (by gk):

 Okay, cross-compiling works but `tor` is still crashing with
 {{{
 Exception Type:  EXC_BREAKPOINT (SIGTRAP)
 Exception Codes: 0x0002, 0x
 Crashed Thread:  0  Dispatch queue: com.apple.main-thread

 Dyld Error Message:
   Symbol not found: _memmem
   Referenced from:
 /Users/release/Desktop/TorBrowser.app/Contents/MacOS/Tor/tor.real
   Expected in: /usr/lib/libSystem.B.dylib
 }}}

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

Re: [tor-bugs] #20287 [Metrics/CollecTor]: digest computation for names of vote files in CollecTor's file protocol and code differs

2016-10-05 Thread Tor Bug Tracker & Wiki

#20287: digest computation for names of vote files in CollecTor's file protocol 
and
code differs
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * owner:   => iwakeh
 * status:  needs_information => assigned


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

Re: [tor-bugs] #20228 [Metrics/CollecTor]: Append all votes with same valid-after time to a single file in `recent/`

2016-10-05 Thread Tor Bug Tracker & Wiki

#20228: Append all votes with same valid-after time to a single file in 
`recent/`
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Great!  Glad we agree here. :)  If you'd like to implement this, I'd be
 happy to review the resulting patches.  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] #20287 [Metrics/CollecTor]: digest computation for names of vote files in CollecTor's file protocol and code differs

2016-10-05 Thread Tor Bug Tracker & Wiki

#20287: digest computation for names of vote files in CollecTor's file protocol 
and
code differs
---+---
 Reporter:  iwakeh |  Owner:
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by iwakeh):

 Thanks! Yes, it does answer the question.  I assumed the code is the way
 to go, but wanted a confirmation.  The question was asked with regard to
 both 'recent' and tar-structure.

 I need these clarifications to provide useful tests for the sync-code.
 That's why this is on set to 'high'.

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

Re: [tor-bugs] #20228 [Metrics/CollecTor]: Append all votes with same valid-after time to a single file in `recent/`

2016-10-05 Thread Tor Bug Tracker & Wiki

#20228: Append all votes with same valid-after time to a single file in 
`recent/`
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Thanks for the history here!  Parts like `rsync` to `recent` could be
 guessed from the code, but its good to have it confirmed.  And, for other
 topics like the purpose of 'recent' it is very important and an easy read
 :-)

 Well, so the definition/purpose for/of `recent` is:
  Provide the latest subset of descriptors a CollecTor could acquire, where
 'latest' is currently defined as three days or more current acquisition
 time, which can be download time or sync-time (once sync is in place).

 Following this definition your second suggestion to store all descriptors
 in 'recent' bundled according to their acquisition time is a simple
 consequence.

 It just needs to be stated prominently somewhere that recent is not for
 human-readable browsing.
 (The database should not be too difficult to be supplied here soon.)

 How to approach the implementation?
 I'd like to have this implementation in order to simplify merging and some
 of the existing CollecTor code.
 I could implement it together with the sync ticket (with decent commits
 for review).  That also would be a big step forward in modularizing the
 Collector code and making it testable etc.

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

Re: [tor-bugs] #20274 [Applications/Tor Browser]: Strange loading and browsing activity on www.hitrecord.org

2016-10-05 Thread Tor Bug Tracker & Wiki

#20274: Strange loading and browsing activity on www.hitrecord.org
--+
 Reporter:  empresspyra   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:   => tbb-usability-website
 * resolution:   => worksforme
 * status:  new => closed
 * component:  - Select a component => Applications/Tor Browser


Comment:

 Works for me on a Linux system with the 6.5a3-hardened. Is that still an
 issue for you? If so, please provide details about which Tor Browser
 version you are using and which operating system and reopen the ticket.
 Thanks. Additional things which were good to know are: Is that
 reproducible? Does a vanilla Firefox ESR 45 work for you? Does a clean,
 new Tor Browser solve the problem?

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

Re: [tor-bugs] #20228 [Metrics/CollecTor]: Append all votes with same valid-after time to a single file in `recent/`

2016-10-05 Thread Tor Bug Tracker & Wiki

#20228: Append all votes with same valid-after time to a single file in 
`recent/`
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * priority:  Medium => High


Comment:

 I'd like us to move forward here, ideally with descriptors grouped by
 download time and both of us being fully convinced that it's the best way
 forward. :)

 So, let me give you some background on where the `recent/` folder comes
 from.

 A few years back, there was just the `archive/` folder with tarballs that
 were updated every few days.  All services like Tor Metrics, ExoneraTor,
 and Onionoo were running on the same host as CollecTor and using
 CollecTor's directory structure for importing new descriptors.  This was
 very convenient for running these services, but of course very fragile and
 very impossible for others to run similar services.  That's when I turned
 CollecTor into its own service.

 The new CollecTor service had a local directory called `rsync/`, the
 predecessor of `recent/`, which had just the newest files that other
 services would download via `rsync` rather than http.  The idea was to
 provide the latest 72 hours of descriptors, so that services can miss
 updates for up to 3 days (a weekend) without having to fall back to
 importing tarballs from the `archive/` directory.  This fixed the problem
 of running all services on one machine, but it didn't allow others to run
 services.  We quickly learned that rsyncing thousands or even hundreds of
 thousands of files did not scale, so we appended many small descriptors
 into one file per CollecTor update run.

 At some point we made that `rsync/` directory available via http as
 `recent/` and taught Onionoo et al. to download descriptors from there
 instead of relying on a local `rsync` command to magically fetch them.
 This is when other services could first enter the game.  It's also when
 users started browsing the `recent/` directory to have an easy way to
 download descriptors---but that was mostly coincidence and a nice side
 effect.

 Now we're considering changing the directory structure to make it even
 more efficient for services to keep up to date.  Merging votes into single
 files reduces the `index.json*` size while keeping the service exactly as
 useful for other services.  Something that we'll make a bit more difficult
 is accessibility for humans, because they cannot locate a vote as easily
 anymore.

 Also consider a feature request that people ask for every so often:
 provide a search for raw descriptors.  This is something that folks like
 directory authority operators or others who debug the network would find
 really useful.  And these folks might be sad that votes are appended to
 single files and stored by download time rather than valid-after time.
 But it's again coincidence that votes are easily locatable by valid-after
 time.  On the other hand, if a user searches for something different, like
 a relay fingerprint or IP address, they'll likely have to download the
 latest few votes and search locally.

 So, we might even go one step further and store ''all'' descriptors in the
 `recent/` folder by download time.  That would include consensuses of
 which there are usually only per CollecTor update run.  The upside would
 be that it'd become more obvious that all files contain the download time,
 not the published or valid-after time.

 All in all, I'd like to consider the `recent/` folder as an update channel
 for services rather than something that humans browse.  I'm not going to
 stop them from doing that, but I'm very hesitant to make the original use
 case of that directory less useful by supporting this new use case.  And
 we would do that by forcing services to download multiple files containing
 many descriptors they already know.

 Somebody should go and write a descriptor database that takes CollecTor's
 `recent/` folder as input and provides a search interface that returns raw
 descriptors.

 I hope this makes sense.  Please let me know if it doesn't!  And thanks
 for reading this wall of text. ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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. (was: torbutton-torCheckService doesn't honor domain isolation.)

2016-10-05 Thread Tor Bug Tracker & Wiki

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

 * severity:  Normal => Major
 * cc: gk (added)
 * component:  Applications/Tor Browser => HTTPS Everywhere/EFF-HTTPS
 Everywhere
 * priority:  Medium => High
 * owner:  tbb-team => legind
 * keywords:  tbb-torbutton, tbb-linkability => tbb-linkability


Comment:

 Replying to [comment:9 yawning]:
 > Ah there.  Looks like the domain isolation code is getting called, but
 wireshark doesn't lie.
 > FWIW, I took the pcaps without my sandboxing stuff in play, and the
 behavior is consistent.
 >
 > {{{
 > [09-22 08:31:02] Torbutton INFO: Component returned failure code:
 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
 [mozIThirdPartyUtil.getFirstPartyURIFromChannel]
 > [09-22 08:31:02] Torbutton INFO: tor SOCKS isolation catchall:
 
https://check.torproject.org/?TorButton=true#0.99726695529027310.5190771246311907
 via --unknown--:0
 > [09-22 08:31:02] Torbutton WARN: no SOCKS credentials found for current
 document.
 > }}}

 Alright, so here is what is going on. First, do you see the weird float
 number thing appended to the `#` in the `check.torproject.org` URL?
 Torbutton does not do such things. It turns out this is part if the HTTPS-
 Everywhere SSL Observatory code where it checks whether Tor is available
 and to use (e.g. for submissions). As a sidenode: one does see the issue
 in the Tor Browser log as well without pcaps. That request does not go
 over the catch-all circuit but rather is put on one without any
 username/password isolation at all.

 So, even if the request comes from HTTPS-Everywhere why is it not isolated
 like any other internal request? Looking at Necko logs shows that indeed
 things are wrong, already at the nsHTTPConnectionManager level:
 {{{
 -957356288[7fd9e2dabb60]: nsHttpConnectionMgr::OnMsgSpeculativeConnect
 [ci=.Scheck.torproject.org:443 (socks:127.0.0.1:9150)[:]]
 }}}
 Before and after the colon in the brackets should be the respective
 username and password.

 Looking closer at the SSL Observatory code shows it is bypassing our proxy
 filter respoonsible for domain isolation in case the CSRF nonce is found
 in the path:

 {{{
 if (isSubmission || testingForTor) {
   if (aURI.path.search(this.csrf_nonce+"$") != -1) {

 this.log(INFO, "Got observatory url + nonce: "+aURI.spec);
 var proxy_settings = null;
 var proxy = null;

 // Send it through tor by creating an nsIProxy instance
 // for the torbutton proxy settings.
 try {
   proxy_settings = this.getProxySettings(testingForTor);
   proxy = this.pps.newProxyInfo(
 proxy_settings.type,
 proxy_settings.host,
 proxy_settings.port,
 Ci.nsIProxyInfo.TRANSPARENT_PROXY_RESOLVES_HOST,
 0x, null);
 } catch(e) {
   this.log(WARN, "Error specifying proxy for observatory: "+e);
 }

 this.log(INFO, "Specifying proxy: "+proxy);

 // TODO: Use new identity or socks u/p to ensure we get a unique
 // tor circuit for this request
 return proxy;
   }
 }
 }}}

 FWIW: the reason you thought this was fixed in the alpha was due to HTTPS-
 Everywhere 5.2.4 that was the latest version at that time. In that version
 SSL Observatory code was broken due to #19996. This got fixed in 5.2.5
 which makes this issue visible in the alphas again.

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

Re: [tor-bugs] #20287 [Metrics/CollecTor]: digest computation for names of vote files in CollecTor's file protocol and code differs

2016-10-05 Thread Tor Bug Tracker & Wiki

#20287: digest computation for names of vote files in CollecTor's file protocol 
and
code differs
---+---
 Reporter:  iwakeh |  Owner:
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 The code is correct, I overlooked that difference when reviewing the
 protocol draft.

 I guess for votes in the `recent/` folder this doesn't matter much,
 because we're thinking about merging them all into a single file.  And
 just in case we decide against that, we can still document what exactly
 we're doing and possibly even why.

 For votes in the tarballs it matters a bit, because those will stay in
 separate files.  There it makes sense to include a descriptor digest,
 because just in case an authority publishes more than one vote, we might
 want to keep those different copies and not overwrite the first with the
 second.

 Does that answer the question?

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

Re: [tor-bugs] #20043 [Applications/Tor Browser]: SharedWorker uses catchall circuit

2016-10-05 Thread Tor Bug Tracker & Wiki

#20043: SharedWorker uses catchall circuit
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: mcs, brade (added)


Comment:

 Looks good to me. I am still not sure I understand why you suddenly need
 to add `worker.js` to the the `suffixes` list as well. Could you
 elaborate?

 mcs/brade: Could you have a look as well?

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

Re: [tor-bugs] #14881 [Core Tor/Tor]: incorrect defaults when producing bandwidth-weights line in directory footer

2016-10-05 Thread Tor Bug Tracker & Wiki

#14881: incorrect defaults when producing bandwidth-weights line in directory
footer
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  027-triaged-1-in, 028-triaged,   |  Actual Points:
  pre028-patch, tor-sponsorU-orphan, |
  TorCoreTeam-postponed-201604, review-group-9   |
Parent ID:   | Points:  3
 Reviewer:  mikeperry|Sponsor:
 |  SponsorU-can
-+-

Comment (by arma):

 Here you go:
 {{{
 Sep 22 21:55:01.524 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29203290 M=4549813 E=1297342 D=9238190 T=44288635
 Sep 22 21:55:01.756 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29203290 M=4549813 E=1297342 D=9238190 T=44288635
 Sep 22 22:55:01.603 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29256210 M=4496382 E=1294965 D=9243530 T=44291087
 Sep 22 22:55:01.841 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29256210 M=4496382 E=1294965 D=9243530 T=44291087
 Sep 22 23:55:01.502 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29295220 M=4441890 E=1270753 D=9209290 T=44217153
 Sep 22 23:55:01.716 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29295220 M=4441890 E=1270753 D=9209290 T=44217153
 Sep 23 00:55:01.571 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29340940 M=4569705 E=1357328 D=9297810 T=44565783
 Sep 23 00:55:01.785 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29340940 M=4569705 E=1357328 D=9297810 T=44565783
 Sep 23 01:55:01.508 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29371910 M=4531469 E=1360359 D=9310870 T=44574608
 Sep 23 01:55:01.724 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29371910 M=4531469 E=1360359 D=9310870 T=44574608
 Sep 23 02:55:01.593 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29270750 M=4509242 E=1365297 D=9303970 T=9259
 Sep 23 02:55:01.804 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29270750 M=4509242 E=1365297 D=9303970 T=9259
 Sep 23 03:55:01.601 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29314870 M=4466842 E=1368374 D=9237310 T=44387396
 Sep 23 03:55:01.814 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29314870 M=4466842 E=1368374 D=9237310 T=44387396
 Sep 23 04:55:01.541 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29316470 M=4374086 E=1327032 D=927 T=44287588
 Sep 23 04:55:01.771 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29316470 M=4374086 E=1327032 D=927 T=44287588
 Sep 23 05:55:01.614 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29316780 M=4390302 E=1348871 D=9285860 T=44341813
 Sep 23 05:55:01.828 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29316780 M=4390302 E=1348871 D=9285860 T=44341813
 Sep 23 06:55:01.629 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29371270 M=339 E=1335815 D=9306940 T=44458364
 Sep 23 06:55:01.846 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29371270 M=339 E=1335815 D=9306940 T=44458364
 Sep 23 07:55:01.598 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29384260 M=4385343 E=1338573 D=9324090 T=44432266
 Sep 23 07:55:01.829 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29384260 M=4385343 E=1338573 D=9324090 T=44432266
 Sep 23 08:55:01.608 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29404200 M=4369584 E=1321205 D=9282310 T=44377299
 Sep 23 08:55:01.831 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29404200 M=4369584 E=1321205 D=9282310 T=44377299
 Sep 23 09:55:01.660 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29483510 M=4341154 E=1343763 D=9230060 T=44398487
 Sep 23 09:55:01.887 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with v10: G=29483510 M=4341154 E=1343763 D=9230060 T=44398487
 Sep 23 10:55:01.644 [notice] Computed bandwidth weights for Case 3a (E
 scarce) with

Re: [tor-bugs] #20023 [Applications/Tor Browser]: Upgrade Go to 1.7.1

2016-10-05 Thread Tor Bug Tracker & Wiki

#20023: Upgrade Go to 1.7.1
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

 * cc: gk (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] #20290 [Applications/Tor Browser]: Upgrade meek to 0.24

2016-10-05 Thread Tor Bug Tracker & Wiki

#20290: Upgrade meek to 0.24
+--
 Reporter:  dcf |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  meek TorBrowserTeam201610R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Applied to master, maint-6.0 and hardened-builds (commit
 a933bb826a463fa8372fe1e5ed372a3390b1db31,
 c8e727d5b00af25194cde2577a45b68bcb31f7ca, and
 40fd8cb1c914996adb817bf961ed23d1e5eb4856), 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] #20182 [Applications/Tor Browser]: Recreating the ja .mar files on OS X is not working correctly

2016-10-05 Thread Tor Bug Tracker & Wiki

#20182: Recreating the ja .mar files on OS X is not working correctly
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-gitian, TorBrowserTeam201610R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

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


Comment:

 Looks good and merged to master (commit
 3993fb0ee7624b8c0daaefcd9f08d1ccf0a048e1).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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)

2016-10-05 Thread Tor Bug Tracker & Wiki

#20291: Create user experience for security slider on Android (wireframes)
+--
 Reporter:  isabela |  Owner:  tbb-team
 Type:  defect  | 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 gk):

 * keywords:  android, ux-mobile => android, ux-mobile, tbb-mobile


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

Re: [tor-bugs] #12381 [Applications/Tor bundles/installation]: Pluggable Transports + proxy is not working on Windows with TBB 3.6.2

2016-10-05 Thread Tor Bug Tracker & Wiki

#12381: Pluggable Transports + proxy is not working on Windows with TBB 3.6.2
-+-
 Reporter:  gk   |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:
 Keywords:  tbb-helpdesk-frequent|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:37 arma]:
 > Hello abandoned ticket still in needs-revision.
 >
 > Is this thing (fte + proxy on Windows) still an issue?

 Yes.

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

67 matches

Mail list logo