Re: [tor-bugs] #18274 [Applications/Tor Browser]: 3DES_EDE_CBC cipher is weak in the current TBB configuration!

[Tor Bug Tracker & Wiki]

#18274: 3DES_EDE_CBC cipher is weak in the current TBB configuration!
--+--
 Reporter:  bugzilla  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  invalid
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mancha):

 Bhargavan and Leurent [https://sweet32.info/ detail] a computationally
 feasible attack on 3DES. It's probably a good time to review our
 assumptions and re-open this for further consideration.

 See [https://sweet32.info/SWEET32_CCS16.pdf SWEET32 paper] for a detailed
 technical description.

 tags: CVE-2016-2183, CVE-2016-6329, SWEET32

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19975 [Obfuscation/BridgeDB]: I can't find any available bridges

[Tor Bug Tracker & Wiki]

#19975: I can't find any available bridges
--+--
 Reporter:  uedadayon |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Obfuscation/BridgeDB  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:  BridgeDB
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 i'm using Windows10 and TorBrowser6.0.4 (based on Mozilla Firefox 45.3.0).

 Since i re-installed Windows10 and killed unnecessary Windows-services a
 week ago,
 I can't find any bridges in any pluggable transports, responding
 "Uh oh, spaghettios! There currently aren't any bridges available...
 Perhaps you should try going back and choosing a different bridge type!".

 Did I kill Windows-services necessary for Tor?

 Please tell me what to do !!

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

Re: [tor-bugs] #19938 [Metrics/CollecTor]: stats on versions of Tor that bridges are running

[Tor Bug Tracker & Wiki]

#19938: stats on versions of Tor that bridges are running
---+-
 Reporter:  isabela|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #19728 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by arma):

 I contacted some bridge operators who were running 0.2.7.6, to ask why
 they were still on that version. The answer in each case so far has been
 "oops I didn't run apt-get upgrade, there I just did" upon which they were
 running 0.2.8.6.

 So I don't know of any package systems where creating an 0.2.7.7 tarball
 will help anybody.

 I think that means this ticket is ready for close? I.e. it has served its
 purpose?

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

Re: [tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+--
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * keywords:   => regression


Comment:

 I am guessing the Orbot folks will find this bug really important.

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

Re: [tor-bugs] #19974 [Core Tor/Tor]: Test failure

[Tor Bug Tracker & Wiki]

#19974: Test failure
--+
 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.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Can you describe the system this was running on?

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

Re: [tor-bugs] #19843 [Applications/Tor Check]: Sorry. You are not using Tor.Your IP address appears to be: 108.61.122.139(new:108.61.122.70)

[Tor Bug Tracker & Wiki]

#19843: Sorry. You are not using Tor.Your IP address appears to be:
108.61.122.139(new:108.61.122.70)
+--
 Reporter:  108.61.122.139  |  Owner:  arlolra
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arlolra):

 The relay in question is,
 https://atlas.torproject.org/#details/7A5F0856723FF95617828B7C4852C0C81CD58997

 Looking at a sampling of the archives for `exit-list-2016-08.tar.xz`,
 https://collector.torproject.org/archive/exit-lists/

 {{{
 > grep -A 3 -r 7A5F0856723FF95617828B7C4852C0C81CD58997 . | more

 ./01/2016-08-01-00-02-02:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./01/2016-08-01-00-02-02-Published 2016-07-31 16:26:20
 ./01/2016-08-01-00-02-02-LastStatus 2016-07-31 17:03:46
 ./01/2016-08-01-00-02-02-ExitAddress 108.61.123.66 2016-07-31 17:09:46
 --
 ./01/2016-08-01-19-02-02:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./01/2016-08-01-19-02-02-Published 2016-08-01 10:27:20
 ./01/2016-08-01-19-02-02-LastStatus 2016-08-01 11:03:19
 ./01/2016-08-01-19-02-02-ExitAddress 108.61.123.69 2016-08-01 11:07:15
 --
 ./02/2016-08-02-12-02-04:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./02/2016-08-02-12-02-04-Published 2016-08-02 04:27:21
 ./02/2016-08-02-12-02-04-LastStatus 2016-08-02 09:26:55
 ./02/2016-08-02-12-02-04-ExitAddress 108.61.123.70 2016-08-02 05:11:52
 --
 ./03/2016-08-03-06-02-03:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./03/2016-08-03-06-02-03-Published 2016-08-02 22:27:53
 ./03/2016-08-03-06-02-03-LastStatus 2016-08-02 23:03:16
 ./03/2016-08-03-06-02-03-ExitAddress 108.61.123.85 2016-08-02 23:05:51
 --
 ./04/2016-08-04-18-02-02:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./04/2016-08-04-18-02-02-Published 2016-08-04 10:28:54
 ./04/2016-08-04-18-02-02-LastStatus 2016-08-04 11:03:03
 ./04/2016-08-04-18-02-02-ExitAddress 108.61.122.152 2016-08-04 11:08:23
 --
 ./05/2016-08-05-12-02-03:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./05/2016-08-05-12-02-03-Published 2016-08-05 04:28:55
 ./05/2016-08-05-12-02-03-LastStatus 2016-08-05 05:03:25
 ./05/2016-08-05-12-02-03-ExitAddress 108.61.122.8 2016-08-05 05:08:12
 --
 ...
 }}}

 It goes on and on, and eventually gets to,

 {{{
 ./08/2016-08-08-19-02-02:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./08/2016-08-08-19-02-02-Published 2016-08-08 10:27:58
 ./08/2016-08-08-19-02-02-LastStatus 2016-08-08 11:02:56
 ./08/2016-08-08-19-02-02-ExitAddress 108.61.122.139 2016-08-08 11:03:49
 }}}

 and,

 {{{
 ./13/2016-08-13-07-02-02:ExitNode 7A5F0856723FF95617828B7C4852C0C81CD58997
 ./13/2016-08-13-07-02-02-Published 2016-08-13 04:26:06
 ./13/2016-08-13-07-02-02-LastStatus 2016-08-13 05:03:04
 ./13/2016-08-13-07-02-02-ExitAddress 108.61.122.70 2016-08-12 23:12:49
 }}}

 This is somewhat analogous to what teor was talking about here,
 https://lists.torproject.org/pipermail/tor-dev/2016-August/011309.html

 We could perhaps change the wording a bit on check to waffle a bit on the
 certainty of its results, but that doesn't help other services that depend
 critically on an accurate exit list, like ExoneraTor.

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

Re: [tor-bugs] #19791 [Metrics/metrics-lib]: Use CollecTor's index.json for download; adapt current download to use new date format

[Tor Bug Tracker & Wiki]

#19791: Use CollecTor's index.json for download; adapt current download to use 
new
date format
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Didn't have time to verify much, but
 [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-19791-2=4352e1b923f23576da9ccfafe407cc1874429092
 this commit] might help.

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

Re: [tor-bugs] #9675 [Applications/Tor Launcher]: Provide feedback mechanism for clock-skew and other bad problems

[Tor Bug Tracker & Wiki]

#9675: Provide feedback mechanism for clock-skew and other bad problems
-+-
 Reporter:  lunar|  Owner:  brade
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-3.0, extdev-interview, tbb-  |  Actual Points:
  helpdesk-frequent, tbb-usability,  |
  AffectsTails   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by fem):

 * severity:  Blocker => Normal


Comment:

 related: #3652

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

Re: [tor-bugs] #9675 [Applications/Tor Launcher]: Provide feedback mechanism for clock-skew and other bad problems

[Tor Bug Tracker & Wiki]

#9675: Provide feedback mechanism for clock-skew and other bad problems
-+-
 Reporter:  lunar|  Owner:  brade
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Blocker  | Resolution:
 Keywords:  tbb-3.0, extdev-interview, tbb-  |  Actual Points:
  helpdesk-frequent, tbb-usability,  |
  AffectsTails   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  tbb-3.0, extdev-interview, tbb-helpdesk-frequent, tbb-
 usability =>
 tbb-3.0, extdev-interview, tbb-helpdesk-frequent, tbb-usability,
 AffectsTails
 * severity:   => Blocker


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19974 [Core Tor/Tor]: Test failure

[Tor Bug Tracker & Wiki]

#19974: Test failure
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.2-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 - git commit 20136a8207f0cda0d23093a884caae0358f98bac
 - debian unstable 32bit


 {{{
 util/monotonic_time:
   FAIL ../src/test/test_util.c:5356: assert(usec1 OP_LE nsec1 / 1000 +10):
 140514332 vs 140514092
   [monotonic_time FAILED]

 }}}

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

Re: [tor-bugs] #19791 [Metrics/metrics-lib]: Use CollecTor's index.json for download; adapt current download to use new date format

[Tor Bug Tracker & Wiki]

#19791: Use CollecTor's index.json for download; adapt current download to use 
new
date format
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  metrics-lib 1.4.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  merge_ready => needs_revision


Comment:

 Bad news for the 1.4.0 release!  I ran into a bug that I couldn't resolve
 easily.  Or rather, I shouldn't fix this bug quickly and then put out the
 1.4.0 release, because that would make a 1.4.1 release quite likely.
 Let's postpone that 1.4.0 release until we're sure what the fix is.

 Please look at [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-19791-2 my task-19791-2 branch] which contains your
 #19791 commit and all subsequent tweaks squashed together, plus some
 tweaks to the change log.  That branch also includes the following fix
 that I made after realizing that `DescriptorIndexCollector` doesn't
 download actual descriptor files but rather the `index.html` file:

 {{{
 diff --git
 a/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 b/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 index 5d6bcdd..4f62be6 100644
 ---
 a/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 +++
 b/src/main/java/org/torproject/descriptor/index/DescriptorIndexCollector.java
 @@ -83,7 +83,8 @@ public class DescriptorIndexCollector implements
 DescriptorCollector {
}
File destinationFile = new File(filepath, filename);
File tempDestinationFile = new File(filepath, "." + filename);
 -  try (InputStream is = new URL(baseUrl).openStream()) {
 +  try (InputStream is = new URL(baseUrl + "/" + filepathname)
 +  .openStream()) {
  Files.copy(is, tempDestinationFile.toPath());
  if (tempDestinationFile.length() == entry.getValue().size) {
tempDestinationFile.renameTo(destinationFile);
 }}}

 However, that change makes the tests fail, and that makes me less
 optimistic that the change was correct, despite the fact that it's working
 fine in a quickly written test application.  I think you should take a
 look.

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

Re: [tor-bugs] #19843 [Applications/Tor Check]: Sorry. You are not using Tor.Your IP address appears to be: 108.61.122.139(new:108.61.122.70)

[Tor Bug Tracker & Wiki]

#19843: Sorry. You are not using Tor.Your IP address appears to be:
108.61.122.139(new:108.61.122.70)
+--
 Reporter:  108.61.122.139  |  Owner:  arlolra
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arlolra):

 For a general response to when false negatives are encountered, please
 see: http://tor.stackexchange.com/a/873

 I'll look into the specifics of this case in a bit.

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

Re: [tor-bugs] #14271 [Applications/Tor Browser]: Make Torbutton work with Unix Domain Socket option

[Tor Bug Tracker & Wiki]

#14271: Make Torbutton work with Unix Domain Socket option
-+-
 Reporter:  gk   |  Owner:  brade
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-security, |  Actual Points:
  TorBrowserTeam201608R  |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * keywords:  tbb-torbutton, tbb-security, TorBrowserTeam201608 => tbb-
 torbutton, tbb-security, TorBrowserTeam201608R
 * status:  assigned => needs_review
 * severity:   => Normal


Comment:

 Here is a patch for review:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug14271-01=115d96e5ca5a861573a6efe08fbb3ba7a3ce149d
 For this to work correctly, you will need a Tor Launcher that includes the
 changes from #14272.

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

Re: [tor-bugs] #14272 [Applications/Tor Launcher]: Make Tor Launcher work with Unix Domain Socket option

[Tor Bug Tracker & Wiki]

#14272: Make Tor Launcher work with Unix Domain Socket option
-+-
 Reporter:  gk   |  Owner:  brade
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201608R  |  Actual Points:
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by mcs):

 * keywords:  tbb-security, TorBrowserTeam201608 => tbb-security,
 TorBrowserTeam201608R
 * status:  assigned => needs_review
 * severity:   => Normal


Comment:

 Switching to a Unix domain socket for the control port turns out to mostly
 be a matter of configuration plus creation of a different kind of socket
 transport. Here is a patch for review:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug14272-01=fe86a337bac123466433a5d7dff19333b5907daf

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

Re: [tor-bugs] #19843 [Applications/Tor Check]: Sorry. You are not using Tor.Your IP address appears to be: 108.61.122.139(new:108.61.122.70)

[Tor Bug Tracker & Wiki]

#19843: Sorry. You are not using Tor.Your IP address appears to be:
108.61.122.139(new:108.61.122.70)
+--
 Reporter:  108.61.122.139  |  Owner:  arlolra
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arlolra):

 Replying to [comment:8 bugzilla]:
 > Oh, forgot to mention, https://check.torproject.org/ sometimes shows an
 IPv6 address of the exit node with "Sorry. You are not using Tor."
 message.

 Since #19940, check should no longer be reachable by IPv6.  Fixing the
 underlying issue is in #16947.

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

Re: [tor-bugs] #19945 [Core Tor/Tor]: tor 0.2.8.5-rc connecting/binding to 18.0.0.1 (regression)

[Tor Bug Tracker & Wiki]

#19945: tor 0.2.8.5-rc connecting/binding to 18.0.0.1 (regression)
---+-
 Reporter:  landers|  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.5-rc
 Severity:  Normal | Resolution:
 Keywords:  regression, windows, easy  |  Actual Points:
Parent ID: | Points:  1.0
 Reviewer: |Sponsor:
---+-

Comment (by landers):

 >In this case, it's likely that GetAdaptersAddresses failed to return any
 addresses, and >to the UDP socket hack is being used to find the client IP
 address. To confirm this, >please check the info-level logs for messages
 like:

 >Unable to load iphlpapi.dll
 >Unable to obtain pointer to GetAdaptersAddresses
 >GetAdaptersAddresses failed


 after setting Log info or log debug stdout.. i didnt get any info for the
 adapters. tor connects to the network and only
 references 127.0.0.1 with "Notice"

 "[Notice] Opening Socks listener on 127.0.0.1:"


 "DisableIOCP 0/1" wont push away tor connecting to 18... either but i
 tried just in case to see if the behavior from
 IOCP networking API would affect the connection.


 >Tor clients generate a new SSL certificate each time their IP address
 changes - this >makes sure they can't be tracked across different
 networks.
 >Tor uses two methods to find the address, GetAdaptersAddresses and the
 "UDP socket >hack": asking the machine the local address of a UDP socket.
 For the hack to work, the >socket has to be associated with a public IP
 address. Tor never sends data on the >socket, it's entirely safe to block
 it with your firewall. Tor's just using it to check >if your local address
 has changed.


 yes blocking the ip does the trick for the fw while tor connects to the
 network.


 thank you for the explanation.

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

Re: [tor-bugs] #18693 [Core Tor/Tor]: New SOCKS port restriction to only allow connections to .onion

[Tor Bug Tracker & Wiki]

#18693: New SOCKS port restriction to only allow connections to .onion
---+
 Reporter:  ioerror|  Owner:  dgoulet
 Type:  enhancement| Status:  needs_review
 Priority:  Very Low   |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, socks  |  Actual Points:  0.5
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:  SponsorR-can
---+
Changes (by dgoulet):

 * status:  accepted => needs_review


Comment:

 I addressed the latest from teor here. I've removed the NATD and Trans
 port restriction for IPv6. I've rebased this to current git master as
 well:

 See branch `ticket18693_029_01`.

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

Re: [tor-bugs] #19972 [Core Tor/Tor]: prop224: Proposal fixes from implementation of HSDir support

[Tor Bug Tracker & Wiki]

#19972: prop224: Proposal fixes from implementation of HSDir support
--+
 Reporter:  dgoulet   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proposal, tor-hs  |  Actual Points:  0.1
Parent ID:  #17238| Points:  0.5
 Reviewer:|Sponsor:  SponsorR-must
--+
Changes (by dgoulet):

 * status:  new => needs_review
 * actualpoints:   => 0.1


Comment:

 See top two commits in branch `ticket19972_01`

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

Re: [tor-bugs] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by gk):

 Replying to [comment:13 mcs]:
 > Replying to [comment:12 gk]:
 > > 3) I have the feeling that
 > > {{{
 > > // XXX: Hack for TBB people who alternate between transproxy and non
 > > }}}
 > > in `startup-observer.js` can go as well or did I miss something?
 > Do you mean just remove the comment or do you want the code to be
 removed? Kathy and I thought we should keep the code so that existing
 behavior is not modified for users who rely on setting the env variables.

 Just the comment. It seemed to me, if at all, then it only applied to the
 lines you removed.

 > Thanks for reviewing all of this!

 Sure. :)

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

Re: [tor-bugs] #19791 [Metrics/metrics-lib]: Use CollecTor's index.json for download; adapt current download to use new date format

[Tor Bug Tracker & Wiki]

#19791: Use CollecTor's index.json for download; adapt current download to use 
new
date format
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:  metrics-lib 1.4.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:11 iwakeh]:
 > Replying to [comment:10 karsten]:
 > [...]
 >
 > > Regarding the new subpackage `org.torproject.descriptor.index`, I'm
 yet unclear whether that's supposed to be "visible" to API users or not,
 that is, if they're supposed to import and/or use those classes directly.
 If it is, that's going to grow the overall interface quite a bit,
 requiring us to keep the public parts stable in subsequent releases.  For
 example, I'm unclear whether CollecTor is supposed to instantiate its own
 `*Node` classes when writing its `index.json*` files.  Ideally, metrics-
 lib would hide away those classes by providing some kind of
 `DescriptorIndexGenerator` interface that takes a local directory as
 parameter and writes one or more `index.json[*]` files, but I'm not sure
 what your plan is there.  If the plan is to hide that package from users,
 how about we rename it to `org.torproject.descriptor.impl.index` to make
 that clearer?  We could even create similar implementation subpackages in
 the future to clean up the `impl` package a bit, but that's not something
 that users would have to care about.
 >
 > I'd like to add the package as '''alpha'''. Warning that it can change
 still in unexpected ways.  Thus, it can be used in CollecTor and from the
 findings there we can decide to remove it from the public interface, or
 change it w/o being backward compatible.
 > I provide a commit with the package-info and more javadoc below.
 >
 > The *Node classes are of use on their own for clients that want to know
 about a CollecTor's instance files.  They are there anyway and maintained,
 so others can just use them as well.

 Okay, I'm fine postponing this decision, and adding that alpha notice
 should be clear enough.

 However, I'm yet unconvinced by the reasons you're giving.  Ideally,
 clients shouldn't have to deal with the details of an index.json file.  We
 should give them interfaces that are powerful enough to do all the things
 they'd want to do.  Also, my past experience is that maintaining code can
 be very different depending on whether it's exposed in an API or not.  I'd
 rather want to provide fewer details in interfaces than what's already
 there.  But, no need to find a conclusion for this today, we can still
 think about this for 1.5.0.

 > > Can we avoid changing the parameter usage of
 `DescriptorIndexCollector#collectDescriptors()` by overloading that method
 in the interface?  How about we add a new method `collectDescriptor(String
 collecTorIndexUrl, String collecTorIndexPath, String[] remoteDirectories,
 ...)` and use an implementation-specific default for `collecTorIndexPath`
 in the current method, such as `"/index.html"` for
 `DescriptorCollectorImpl` and `"/index.json.xz"` for
 `DescriptorIndexCollector`?  If we retain backward compatibility here, I'd
 say we could switch to `DescriptorIndexCollector` in 1.5.0 when this class
 has seen some more testing.  Otherwise I'd suggest waiting for 2.0.0.
 >
 > I wouldn't want to change the interface for that.  Both are URL strings
 and whoever uses the non-default implementation must know what their
 doing, i.e. at least read javadoc of the class they explicitly request to
 be used.  At the point DescriptorIndexCollector becomes default we might
 not want to keep maintaining the old implementation and simply remove it.
 Then the additional method wouldn't make sense any more.

 My point is that we could do the switch to the new implementation in a
 version 1.5.0 if it remains backward-compatible, whereas we'd have to call
 that version 2.0.0 otherwise.  So, we can merge this code as is for 1.4.0,
 but we should aim for a backward-compatible version if we want to make it
 the new default in 1.5.0.

 Here's an even better suggestion: we accept both, base URLs (like
 `"https://collector.torproject.org"`) and full URLs to index files (like
 `"https://collector.torproject.org/index.html"` or
 `"https://collector.torproject.org/index.json.xz"`), in the current
 `collectDescriptors()` method, and if no file is specified, we'll use an
 implementation-specific default (`"/index.html"` in
 `DescriptorCollectorImpl` and `"/index.json.xz"` in
 `DescriptorIndexCollector`).  That doesn't break 

Re: [tor-bugs] #19973 [Core Tor/Tor]: ReachableAddresses applied too broadly

[Tor Bug Tracker & Wiki]

#19973: ReachableAddresses applied too broadly
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major| Resolution:  fixed
 Keywords:  regression path  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Thanks also for testing here.  I've merged this to maint-0.2.8 and
 forwards.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by jgrahamc):

 Hmm. That shouldn't happen. I have raised this internally to find out why.
 Did you have JavaScript enabled or disabled?

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

Re: [tor-bugs] #19973 [Core Tor/Tor]: ReachableAddresses applied too broadly

[Tor Bug Tracker & Wiki]

#19973: ReachableAddresses applied too broadly
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major| Resolution:
 Keywords:  regression path  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 ACK.

 I confirm also that I was able to reproduce nickm's experiment as well
 with the patch and confirm that the bug exists without it although Exit
 node picking doesn't seem to be affected but Guard and Middle are all
 strictly picked from the A network (`ReachableAddresses` filter).

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

Re: [tor-bugs] #19973 [Core Tor/Tor]: ReachableAddresses applied too broadly

[Tor Bug Tracker & Wiki]

#19973: ReachableAddresses applied too broadly
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major| Resolution:
 Keywords:  regression path  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I believe  that the patch is correct.

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

Re: [tor-bugs] #19973 [Core Tor/Tor]: ReachableAddresses applied too broadly

[Tor Bug Tracker & Wiki]

#19973: ReachableAddresses applied too broadly
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major| Resolution:
 Keywords:  regression path  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Teor's branch is in my public repository now as `bug19973_028`.

 I hand-confirmed that this bug exists, and that this branch has the
 intended effect, by using ReachableAddresses to restrict myself to a class
 A network, and then using "GETINFO circuit-status" to see what paths were
 built.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19973 [Core Tor/Tor]: ReachableAddresses applied too broadly

[Tor Bug Tracker & Wiki]

#19973: ReachableAddresses applied too broadly
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major |   Keywords:  regression path
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The ReachableAddresses filter should only apply when picking a first node.
 But in 268608c in #17840 , it began to apply to the whole path.

 This is bad for path selection, in proportion to the restrictiveness of
 your ReachableAddresses filter. It's probably not a hard break, but it's
 important to fix.

 Teor found this issue and wrote a patch for it.  It should go into an 028
 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] #19973 [Core Tor/Tor]: ReachableAddresses applied too broadly

[Tor Bug Tracker & Wiki]

#19973: ReachableAddresses applied too broadly
-+
 Reporter:  nickm|  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.8.2-alpha
 Severity:  Major| Resolution:
 Keywords:  regression path  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 My `sample_path` branch is supposed to help test this kind of  thing.

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

Re: [tor-bugs] #15852 [Applications/Tor Browser]: Remove/synchronize Torbutton SOCKS pref logic

[Tor Bug Tracker & Wiki]

#15852: Remove/synchronize Torbutton SOCKS pref logic
-+-
 Reporter:  mikeperry|  Owner:  brade
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-4.5-regression, tbb-torbutton-   |  Actual Points:
  conversion, TorBrowserTeam201608R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by mcs):

 Replying to [comment:12 gk]:
 > commit 573bb7fb3b22cfc28d3dce01e2378d1b181e6d43 looks good.
 >
 > re commit 6244aadf7cfd944e8b53aabd1da52fe40df89f96:
 >
 > 1) It seems we don't need to add/remove an observer for `network.proxy`
 anymore in torbutton,js?
 You are right. We will remove that observer.

 > 2) Maybe add `3. Reset Security Slider settings" in
 `torbutton_prefs_reset_defaults()`?
 OK.

 > 3) I have the feeling that
 > {{{
 > // XXX: Hack for TBB people who alternate between transproxy and non
 > }}}
 > in `startup-observer.js` can go as well or did I miss something?
 Do you mean just remove the comment or do you want the code to be removed?
 Kathy and I thought we should keep the code so that existing behavior is
 not modified for users who rely on setting the env variables.

 Thanks for reviewing all of 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] #19728 [Core Tor/Tor]: Pick, and deploy, a new bridge authority

[Tor Bug Tracker & Wiki]

#19728: Pick, and deploy, a new bridge authority
--+
 Reporter:  arma  |  Owner:
 Type:  task  | Status:  needs_review
 Priority:  Immediate |  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  6
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Added a changes file, and cherry-picked to 0.2.7 and forward.

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

Re: [tor-bugs] #19640 [Metrics/metrics-lib]: review and improve interface hierarchy

[Tor Bug Tracker & Wiki]

#19640: review and improve interface hierarchy
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.5.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 `ParseHelper` should be split into a utility class that is part of the
 interface and the implementation specific part inside `impl`.

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

Re: [tor-bugs] #19791 [Metrics/metrics-lib]: Use CollecTor's index.json for download; adapt current download to use new date format

[Tor Bug Tracker & Wiki]

#19791: Use CollecTor's index.json for download; adapt current download to use 
new
date format
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  metrics-lib 1.4.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:10 karsten]:
 > Alright, let's go through the last four commits in that branch:

 Thanks for looking at all that!

 >
 > 91fdb9b is already contained in master as 1dab40d.

 correct.

 >
 > a74563a looks good and is merged to my branch (see below) as 7a0e109.
 >
 > 1276c14 looks good, too, and is merged to my branch as e9c0731.  Thanks
 for caring about tests!

 Without tests a codebase becomes unmaintainable very soon ...

 >
 > 32f628f is preliminary merged to my branch as 82eb1cf, but I have a
 couple of questions and change requests, as follows:
 >
 > Commit bf5ba78 in [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-19791 my task-19791 branch] contains a few trivial
 fixes.  Please take a look and let me know if you're okay with those.

 Does look fine.

 >
 > Regarding the new subpackage `org.torproject.descriptor.index`, I'm yet
 unclear whether that's supposed to be "visible" to API users or not, that
 is, if they're supposed to import and/or use those classes directly.  If
 it is, that's going to grow the overall interface quite a bit, requiring
 us to keep the public parts stable in subsequent releases.  For example,
 I'm unclear whether CollecTor is supposed to instantiate its own `*Node`
 classes when writing its `index.json*` files.  Ideally, metrics-lib would
 hide away those classes by providing some kind of
 `DescriptorIndexGenerator` interface that takes a local directory as
 parameter and writes one or more `index.json[*]` files, but I'm not sure
 what your plan is there.  If the plan is to hide that package from users,
 how about we rename it to `org.torproject.descriptor.impl.index` to make
 that clearer?  We could even create similar implementation subpackages in
 the future to clean up the `impl` package a bit, but that's not something
 that users would have to care about.

 I'd like to add the package as '''alpha'''. Warning that it can change
 still in unexpected ways.  Thus, it can be used in CollecTor and from the
 findings there we can decide to remove it from the public interface, or
 change it w/o being backward compatible.
 I provide a commit with the package-info and more javadoc below.

 The *Node classes are of use on their own for clients that want to know
 about a CollecTor's instance files.  They are there anyway and maintained,
 so others can just use them as well.

 >
 > Can we avoid changing the parameter usage of
 `DescriptorIndexCollector#collectDescriptors()` by overloading that method
 in the interface?  How about we add a new method `collectDescriptor(String
 collecTorIndexUrl, String collecTorIndexPath, String[] remoteDirectories,
 ...)` and use an implementation-specific default for `collecTorIndexPath`
 in the current method, such as `"/index.html"` for
 `DescriptorCollectorImpl` and `"/index.json.xz"` for
 `DescriptorIndexCollector`?  If we retain backward compatibility here, I'd
 say we could switch to `DescriptorIndexCollector` in 1.5.0 when this class
 has seen some more testing.  Otherwise I'd suggest waiting for 2.0.0.

 I wouldn't want to change the interface for that.  Both are URL strings
 and whoever uses the non-default implementation must know what their
 doing, i.e. at least read javadoc of the class they explicitly request to
 be used.  At the point DescriptorIndexCollector becomes default we might
 not want to keep maintaining the old implementation and simply remove it.
 Then the additional method wouldn't make sense any more.

 >
 > The condition `if (!filepath.exists() && filepath.mkdirs())` in
 `DescriptorIndexCollector#fetchRemoteFiles()` looks wrong.  Shouldn't it
 be `!filepath.mkdirs()` there?  I didn't test this, but the API says that
 `mkdirs()` returns "true if and only if the directory was created, along
 with all necessary parent directories; false otherwise".

 Thanks for spotting this!
 I'll added a test and the fix in a new commit.

 >
 > Is `FileNode#lastModifiedMillis()` called often?  If so, it may be
 better to use `ParseHelper#getDateFormat()` to obtain a thread-safe
 `DateFormat` instance for the given format and store it in a map.  That
 avoids creating single-use instances of that class over and over.  We'd
 have to make that 

Re: [tor-bugs] #10394 [Applications/Tor Browser]: Torbrowser's updater updates HTTPS-everywhere

[Tor Bug Tracker & Wiki]

#10394: Torbrowser's updater updates HTTPS-everywhere
--+--
 Reporter:  StrangeCharm  |  Owner:  tbb-team
 Type:  task  | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:7 bugzilla]:
 > mcs, thanks for the clarification. But,
 > > Interim updates are still retrieved from addons.mozilla.org using the
 extension update mechanism
 > No. From EFF.

 Thanks. My mistake.

 > > so users can get updates if desired.
 > What does it mean (desired)? Update Add-ons Automatically is selected by
 default.

 It means users do have a way to disable updates if they want to do so. But
 most will keep the default setting.

 > > We use the same approach for NoScript.
 > No. But, maybe, it's better to use the same, because recent updates led
 to 5.2.0 on alpha, 5.1.x on stable and 5.2.1 on AMO.

 There is a policy question here: should we disable updates for bundled
 extensions. By allowing updates from EFF or AMO, we risk that users may
 get a version of an extension that is somehow incompatible with Tor
 Browser. But by allowing updates we ensure that users will have the latest
 (and hopefully most secure) versions of HTTPS-E and NoScript.

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

Re: [tor-bugs] #19814 [Community]: Tor Browser User Manual points users to the helpdesk

[Tor Bug Tracker & Wiki]

#19814: Tor Browser User Manual points users to the helpdesk
---+---
 Reporter:  boklm  |  Owner:  phoul
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by brade):

 * 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

[tor-bugs] #19972 [Core Tor/Tor]: prop224: Proposal fixes from implementation of HSDir support

[Tor Bug Tracker & Wiki]

#19972: prop224: Proposal fixes from implementation of HSDir support
---+
 Reporter:  dgoulet|  Owner:
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  proposal, tor-hs
Actual Points: |  Parent ID:  #17238
   Points:  0.5|   Reviewer:
  Sponsor:  SponsorR-must  |
---+
 With the implementation work of #17238, we ended up changing small pieces
 of proposal 224. This is the ticket to address those.

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

Re: [tor-bugs] #12736 [Applications/Tor Browser]: DLL hijacking vulnerability in TBB

[Tor Bug Tracker & Wiki]

#12736: DLL hijacking vulnerability in TBB
+--
 Reporter:  underdoge   |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201608  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by boklm):

 I didn't try to do some debugging yet, but after looking at the HTTPS
 Everywhere code, I am wondering if it could be caused by the
 NSS.initialize function:
 https://gitweb.torproject.org/https-
 
everywhere.git/tree/src/chrome/content/code/NSS.js?id=7035dde6b76eb8be458d410768188d9cd5d09f89#n28

 {{{
   try {
 sharedLib = tcypes.open(nssPath);
   } catch (e) {

 }}}

 when `nssPath` is empty when called from:
 https://gitweb.torproject.org/https-everywhere.git/tree/src/components
 /ssl-observatory.js?id=7035dde6b76eb8be458d410768188d9cd5d09f89#n126
 {{{
   try {
 NSS.initialize("");
   } catch(e) {
 }}}

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

Re: [tor-bugs] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201608  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 This sounds like a good idea. I will try to do something like 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] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201608  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:23 boklm]:
 > Replying to [comment:21 gk]:
 > >
 > > I think we should care about getting a valid date out of it (at least
 it can't hurt). What I do not understand is the need for hard-coding the
 oldest supported ESR version. Why can't we extract a version from the
 parameter the script get passed anyway (in fact the major ESR version does
 already get extracted)? It seems to me there always will be times where
 the alphas and the stable series share build ids which does not seem to be
 bad to me. So, what is your motivation for hard-coding that number?
 >
 > Maybe the "oldest support ESR version" name is confusing. It is just a
 number that we subtract to the major ESR version to make it less than 30
 (I was wrong in my previous comment, the major ESR version is not used as
 the month but as day of the month). We don't want this number to be based
 on the current version, because for instance when we release a version
 based on ESR 52, we still want to continue subtracting 45 so that the
 buildid for ESR 52 releases is bigger than for ESR 45 releases.
 >
 > For ESR 45 releases, the buildid will start with 20160101 or 20170101
 (for the releases made in 2017). The ESR 52 releases made in 2017 will
 have a buildid starting with 20170108. In 2018 we will change $oldest_esr
 to 52 and ESR 52 releases will have a buildid starting with 20180101, ESR
 59 releases a buildid starting with 20180108.

 I see. So, bumping the hard-coded value is year-bound, right? More
 precisely: every two years starting with 2018 we increase the hard-coded
 value by 7, correct? If that's the case then we can hard-code the current
 year and then we compare the year extracted (like done with
 `COPYRIGHT_YEAR`) with the one we hard-coded: if the extracted one is the
 hard-coded one + 2 we add to the hard-coded "old-ESR" value 7 if + 4 then
 we add +14 etc. If incrementing is not year bound (maybe it should not
 because ESR release are not happening exactly every 12 month) I guess we
 could construct something similar taking ESR versions into account (like
 every two major ESR versions we can add 7 to our hard-coded value.

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

Re: [tor-bugs] #19894 [Metrics/CollecTor]: print message when no module is activated

[Tor Bug Tracker & Wiki]

#19894: print message when no module is activated
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 Looks good, will merge together with #19895!

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

Re: [tor-bugs] #19895 [Metrics/CollecTor]: make CollecTor stop after RunOnce

[Tor Bug Tracker & Wiki]

#19895: make CollecTor stop after RunOnce
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Hmm, it seems that I'm running out of non-daemon threads now.  Execution
 stops immediately after writing this log file:

 {{{
 $ cat collector-all.log
 2016-08-24 12:34:05,688 INFO o.t.c.cron.Scheduler:80 Single run for
 org.torproject.collector.relaydescs.ArchiveWriter.
 2016-08-24 12:34:05,724 INFO o.t.c.cron.Scheduler:130 New Thread created:
 CollecTor-Scheduled-Thread-1
 }}}

 Here's my config file, as compared to defaults:

 {{{
 $ diff src/main/resources/collector.properties collector.properties
 10c10
 < RunOnce = false
 ---
 > RunOnce = true
 24c24
 < RelaydescsActivated = false
 ---
 > RelaydescsActivated = true
 83c83
 < DownloadRelayDescriptors = false
 ---
 > DownloadRelayDescriptors = true
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19971 [Applications/TorBirdy]: Option to disable gnupg version dependent changes in the Enigmail settings

[Tor Bug Tracker & Wiki]

#19971: Option to disable gnupg version dependent changes in the Enigmail 
settings
---+-
 Reporter:  p.hansen   |  Owner:  sukhbir
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 When using Thunderbird with Enigmail and Torbirdy with the "modern"
 version of gnupg (2.1.15 in my case), Torbirdy modifies the options for
 Enigmail/gpg on every start of Thunderbird. Unfortunately some of the
 'injected' options are not compatible with the new gpg version.
 It would be helpful (at least for the moment) to add an option that either
 completely disables this 'injection' or disables injecting the
 incompatible parameters.
 Afaik the incompatible options are `no-try-dns-srv` and `http-
 proxy=socks5h://127.0.0.1:9150`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19970 [Internal Services/Service - trac]: Login after registration leads to endless Captcha queries

[Tor Bug Tracker & Wiki]

#19970: Login after registration leads to endless Captcha queries
--+-
 Reporter:  p.hansen  |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 After registering in trac and logging in I got infinite Captcha requests
 even though I was logged in already.
 Perhaps a wrong redirection after 'solving' the first captcha?

 Using a link (instead of solving the next captcha) on the trac site got me
 out of the loop.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 jgrahamc: The CAPTCHA-loop is back. Why is that? Before giving up I was
 served 13 lakes, rivers, and of course ¡street signs!

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

Re: [tor-bugs] #19895 [Metrics/CollecTor]: make CollecTor stop after RunOnce

[Tor Bug Tracker & Wiki]

#19895: make CollecTor stop after RunOnce
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  new => needs_review


Comment:

 I was wondering why this didn't get attention, well, setting it to
 needs_review might help.

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

Re: [tor-bugs] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201608  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 Replying to [comment:21 gk]:
 >
 > I think we should care about getting a valid date out of it (at least it
 can't hurt). What I do not understand is the need for hard-coding the
 oldest supported ESR version. Why can't we extract a version from the
 parameter the script get passed anyway (in fact the major ESR version does
 already get extracted)? It seems to me there always will be times where
 the alphas and the stable series share build ids which does not seem to be
 bad to me. So, what is your motivation for hard-coding that number?

 Maybe the "oldest support ESR version" name is confusing. It is just a
 number that we subtract to the major ESR version to make it less than 30
 (I was wrong in my previous comment, the major ESR version is not used as
 the month but as day of the month). We don't want this number to be based
 on the current version, because for instance when we release a version
 based on ESR 52, we still want to continue subtracting 45 so that the
 buildid for ESR 52 releases is bigger than for ESR 45 releases.

 For ESR 45 releases, the buildid will start with 20160101 or 20170101 (for
 the releases made in 2017). The ESR 52 releases made in 2017 will have a
 buildid starting with 20170108. In 2018 we will change $oldest_esr to 52
 and ESR 52 releases will have a buildid starting with 20180101, ESR 59
 releases a buildid starting with 20180108.

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

Re: [tor-bugs] #19528 [Applications/Tor Browser]: The build id stays the same with every Firefox update

[Tor Bug Tracker & Wiki]

#19528: The build id stays the same with every Firefox update
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:
  |  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-gitian, TorBrowserTeam201608  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * keywords:  tbb-gitian, TorBrowserTeam201608R => tbb-gitian,
 TorBrowserTeam201608
 * status:  needs_information => needs_revision


Comment:

 Getting the current year with the method mcs mentioned for
 `COPYRIGHT_YEAR` seems reasonable 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] #19791 [Metrics/metrics-lib]: Use CollecTor's index.json for download; adapt current download to use new date format

[Tor Bug Tracker & Wiki]

#19791: Use CollecTor's index.json for download; adapt current download to use 
new
date format
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  metrics-lib 1.4.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Alright, let's go through the last four commits in that branch:

 91fdb9b is already contained in master as 1dab40d.

 a74563a looks good and is merged to my branch (see below) as 7a0e109.

 1276c14 looks good, too, and is merged to my branch as e9c0731.  Thanks
 for caring about tests!

 32f628f is preliminary merged to my branch as 82eb1cf, but I have a couple
 of questions and change requests, as follows:

 Commit bf5ba78 in [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-19791 my task-19791 branch] contains a few trivial
 fixes.  Please take a look and let me know if you're okay with those.

 Regarding the new subpackage `org.torproject.descriptor.index`, I'm yet
 unclear whether that's supposed to be "visible" to API users or not, that
 is, if they're supposed to import and/or use those classes directly.  If
 it is, that's going to grow the overall interface quite a bit, requiring
 us to keep the public parts stable in subsequent releases.  For example,
 I'm unclear whether CollecTor is supposed to instantiate its own `*Node`
 classes when writing its `index.json*` files.  Ideally, metrics-lib would
 hide away those classes by providing some kind of
 `DescriptorIndexGenerator` interface that takes a local directory as
 parameter and writes one or more `index.json[*]` files, but I'm not sure
 what your plan is there.  If the plan is to hide that package from users,
 how about we rename it to `org.torproject.descriptor.impl.index` to make
 that clearer?  We could even create similar implementation subpackages in
 the future to clean up the `impl` package a bit, but that's not something
 that users would have to care about.

 Can we avoid changing the parameter usage of
 `DescriptorIndexCollector#collectDescriptors()` by overloading that method
 in the interface?  How about we add a new method `collectDescriptor(String
 collecTorIndexUrl, String collecTorIndexPath, String[] remoteDirectories,
 ...)` and use an implementation-specific default for `collecTorIndexPath`
 in the current method, such as `"/index.html"` for
 `DescriptorCollectorImpl` and `"/index.json.xz"` for
 `DescriptorIndexCollector`?  If we retain backward compatibility here, I'd
 say we could switch to `DescriptorIndexCollector` in 1.5.0 when this class
 has seen some more testing.  Otherwise I'd suggest waiting for 2.0.0.

 The condition `if (!filepath.exists() && filepath.mkdirs())` in
 `DescriptorIndexCollector#fetchRemoteFiles()` looks wrong.  Shouldn't it
 be `!filepath.mkdirs()` there?  I didn't test this, but the API says that
 `mkdirs()` returns "true if and only if the directory was created, along
 with all necessary parent directories; false otherwise".

 Is `FileNode#lastModifiedMillis()` called often?  If so, it may be better
 to use `ParseHelper#getDateFormat()` to obtain a thread-safe `DateFormat`
 instance for the given format and store it in a map.  That avoids creating
 single-use instances of that class over and over.  We'd have to make that
 method public for this, but that shouldn't be an issue.  However, if it's
 not called very often, we can skip this.

 In `IndexNode#retrieveFiles()` I'm not yet clear what situations lead to
 returning the half-done map in the middle of the loop.  If one invalid
 remote directory leads to that case, I think we should either warn and
 skip that remote directory or return an empty map.  Otherwise, the order
 of remote directories would affect the result, and that might lead to bugs
 in user applications that are quite hard to find.

 Can we pick a smaller `test.json` and compressed equivalents in
 `src/test/resources/`?  For example, we could take the `index.json` from
 the main CollecTor instance and throw out all files that haven't been
 modified in the past, say, four weeks.  Or did you include a large file on
 purpose to check something that cannot be tested with a smaller file?

 I'd say once we have resolved these questions, it's good to go into 1.4.0,
 even today.  Thanks for working on this!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

[tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

[Tor Bug Tracker & Wiki]

#19969: tor client does not immediately open new circuits after standby
--+--
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.6
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Viktor writes via https://bugs.debian.org/835119:

 I use tor only as a client to connect icedove to the tor network with
 the extension Torbirdy (on port 9050). With the tor version 0.2.8.6 I
 can't immediately connect to any mail server or news feed after the pc
 woke up from standby ("long" time in standby) and I started icedove. I
 have to wait for several minutes in order to connect successfully, but
 the timespan seems to be random. This does not occur after a (re)boot.
 The first version I remember to have this issue is 0.2.8.6-2, I did an
 upgrade from 0.2.7.6-1 to 0.2.8.6-2, so I skipped the alpha and rc
 versions and the first upload to unstable. I am very sure that the issue
 didn't occur in version 0.2.7.6-1 which I used for several months. I can
 exclude network connectivity problems because e.g. I can immediately
 start the Tor Browser after standby.

 Today I purged tor, installed version 0.2.7.6-1, copied the old "state"
 file to /var/lib/tor, and set the pc in standby mode for a couple of
 minutes. After waking up from standby I immediately tried to connect to
 a mail server which worked. Then I upgraded step by step to every
 version of tor 0.2.8 which I could find on snapshot.debian.org and tried
 to connect to a mail server immediately after waking up from standby.
 Unfortunately I could not reproduce the bug then. Finally with version
 0.2.8.6-3 the bug occured again, but only after a "long" standby time
 (almost 90 minutes).

 Attached are two log files from the weekend and the complete log from
 today after the installation of version 0.2.7.6-1.

 As you can see, the bug is not easily reproducible, and the logs don't
 show any particular reason for why tor does not open new circuits
 immediately. Please tell me what I can do to give you more information
 about the bug.

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

[tor-bugs] #19968 [Core Tor/Tor]: Test fails on Debian experimental reproducible builds

[Tor Bug Tracker & Wiki]

#19968: Test fails on Debian experimental reproducible builds
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 A [https://tests.reproducible-
 builds.org/debian/rbuild/experimental/i386/tor_0.2.9.1-alpha-1.rbuild.log
 recent build] on the reproducible build machines with Debian experimental
 fails on one test.

 {{{
 util/num_cpus:
   FAIL ../src/test/test_util.c:3689: assert(num OP_LE 16): 18 vs 16
   [num_cpus FAILED]
 }}}

 This test was added in
 
[https://gitweb.torproject.org/tor.git/commit/?id=603cb712ef756dd700a52e837bcd643a96311ad6
 commit 603cb712ef756dd700a52e837bcd643a96311ad6] which expects the maximum
 number of CPUs to be 16. The
 
[https://gitweb.torproject.org/tor.git/tree/src/common/compat.c?id=8feb301413cc0f23b37dedbac0c57de25b88f519#n2801
 compute_num_cpus function] only logs a message for machines with more than
 16 CPUs but doesn't clamp the return value to 16. So there is a
 discrepancy between the implementation and the test. (Why is there a limit
 anyway?)

 Furthermore, the preprocessor macro that defines the maximum number of
 CPUs isn't public and can't be used in tests leading to undefined magic
 numbers.

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

Re: [tor-bugs] #19410 [Applications/Tor Browser]: Incremental updates from 6.0 to 6.0.1 are not working on OS X

[Tor Bug Tracker & Wiki]

#19410: Incremental updates from 6.0 to 6.0.1 are not working on OS X
-+-
 Reporter:  gk   |  Owner:  boklm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  TorBrowserTeam201608,|  Actual Points:
  tbb-6.0-issues |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  TorBrowserTeam201608R, tbb-6.0-issues => TorBrowserTeam201608,
 tbb-6.0-issues


Comment:

 I think we could need an easy integration of this script into our build
 process as well, like a `make` target. Then, could you add a patch for our
 updated release procedures to this ticket, too?
 While being a bit annoying the `p7zip` situation is not that dramatic.
 There won't be many that need to go through the hassle you are describing
 in your patch. FWIW: I think you should make the comment there future
 proof saying that Debian Stretch users can install this directly from the
 repo while users with older Debian versions and/or `p7zip` < 15.14 need to
 follow the things you are outlining in the comment. After all Debian
 Stretch is supposed to get stable at the end of the year IIRC.

 I guess once this lands we need to adapt our explanation on how to verify
 the MAR files Gitian built are really the same as those we ship. :/ But
 this can be a different 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] #19960 [Core Tor/Tor]: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing one test on NetBSD

[Tor Bug Tracker & Wiki]

#19960: Tor v0.2.9.1-alpha-dev (git-b3f43a22ab921ce6) - failing one test on 
NetBSD
-+-
 Reporter:  yancm|  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:  self test regression netbsd  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:4 yancm]:
 > Replying to [comment:2 cypherpunks]:
 > > I don't have a NetBSD machine available,
 > [...]
 > > Because i don't have a NetBSD machine I'm unsure which firewall system
 is used on NetBSD.
 > > It seems the rest of the Tor code assumes NetBSD is similar to
 OpenBSD...so i guess it
 > > should use pf-divert?
 >
 > I'm uncertain, it might be built in. I actually use ipf (pf and npf are
 also available)
 >
 > I'll try your patch soon unless it's already been pushed up...
 I don't expect the patch to solve your issue. It was just meant as
 premature cleanup of related code before actually fixing the issue.

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