Re: [tor-bugs] #21443 [Metrics/CollecTor]: CollecTor does not delete exit lists after three days anymore

[Tor Bug Tracker & Wiki]

#21443: CollecTor does not delete exit lists after three days anymore
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Hmm, wouldn't that clean the entire recent-dir?

 And, it would be nice to have a test for this.  It would be a good
 preparation for introducing `CleanUtils` (#20546 which I have on my list
 review and some tweaking).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21443 [Metrics/CollecTor]: CollecTor does not delete exit lists after three days anymore

[Tor Bug Tracker & Wiki]

#21443: CollecTor does not delete exit lists after three days anymore
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Replying to [comment:2 iwakeh]:
 > Hmm, wouldn't that clean the entire recent-dir?

 Retracting this question,
 
[https://gitweb.torproject.org/collector.git/tree/src/main/java/org/torproject/collector/exitlists/ExitListDownloader.java#n72
 line 72] explains.  Looks fine.


 >
 > And, it would be nice to have a test for this.  It would be a good
 preparation for introducing `CleanUtils` (#20546 which I have on my list
 review and some tweaking).
 >

 Still applies ;-)

 And, maybe some modernization regarding download and persisting the lists?
 But, that extends the scope of this ticket.

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

Re: [tor-bugs] #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:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by sukhbir):

 Replying to [comment:2 intrigeri]:
 > The torified-dirmngr-compatibility branch on https://git-
 tails.immerda.ch/torbirdy.git adds an option that allows one to address
 this use case. I've applied these changes in Tails for our 3.0 version,
 that uses Modern GnuPG, and therefore is affected by this problem.
 Feedback welcome!

 Thanks for the patch!

 This seems like a good solution in light of the GPG changes, compared to
 the HTTP proxy solution we have right now, which I feel is essentially
 broken.

 Before I merge: is there a reason why the
 `extensions.enigmail.agentAdditionalParam` preferences were removed?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20711 [Core Tor/Tor]: [warn] Cannot make an outgoing connection without a DirPort

[Tor Bug Tracker & Wiki]

#20711: [warn] Cannot make an outgoing connection without a DirPort
---+
 Reporter:  arma   |  Owner:
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.8.2-alpha
 Severity:  Normal | Resolution:
 Keywords:  triage-out-030-201612  |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+

Comment (by Christian):

 I have `DirPort` (and `ORPort`) set and get the same message, but a few
 lines before it stated that `DirPort` is reachable, so it must have found
 it in the configuration, right?

 {{{
 Feb 13 00:51:01.378 [notice] Tor 0.3.0.3-alpha-dev (git-2670844b2b64172f)
 running on Linux with Libevent 2.2.0-alpha-dev, OpenSSL 1.1.0d and Zlib
 1.2.8.
 [...]
 Feb 13 00:57:41.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Feb 13 00:57:41.000 [notice] Bootstrapped 100%: Done
 Feb 13 00:57:41.000 [notice] Now checking whether ORPort
 71.xxx.xxx.xxx:9001 and DirPort 71.xxx.xxx.xxx:9030 are reachable... (this
 may take up to 20 minutes -- look for log messages indicating success)
 Feb 13 00:57:42.000 [notice] Self-testing indicates your DirPort is
 reachable from the outside. Excellent.
 Feb 13 00:57:43.000 [notice] Self-testing indicates your ORPort is
 reachable from the outside. Excellent. Publishing server descriptor.
 Feb 13 00:57:51.000 [notice] Performing bandwidth self-test...done.
 Feb 13 00:58:15.000 [warn] Cannot make an outgoing connection without a
 DirPort.
 Feb 13 00:58:15.000 [warn] Cannot make an outgoing connection without a
 DirPort.
 Feb 13 01:02:20.000 [notice] New control connection opened from 127.0.0.1.
 }}}

 This is with today's Git checkout.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20751 [Applications/TorBirdy]: enforce stronger ciphers in torbirdy

[Tor Bug Tracker & Wiki]

#20751: enforce stronger ciphers in torbirdy
-+-
 Reporter:  cypherpunks  |  Owner:  sukhbir
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Applications/TorBirdy|Version:
 Severity:  Minor| Resolution:
 Keywords:  torbirdy, thunderbird,   |  Actual Points:
  TorBirdy0.2.2  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sukhbir):

 Replying to [comment:2 Diapolo]:
 > I'd like to support the idea of better and safer defaults!
 >
 > {{{
 > "security.tls.version.min": 1,
 > "security.tls.version.max": 3,
 > }}}
 >
 > I'm able to use 3, 3 and would also be able to use 3, 4 if Thunderbird
 supports TLS 1.3, so it's bad that these are getting overwritten ;).

 I am thinking of going with:

 {{{
 "security.tls.version.min": 3,
 "security.tls.version.max": 3,
 }}}

 And then have an opt-out if this breaks some mail providers, with the
 preferences (set via TorBirdy's preferences dialog):

 {{{
 "security.tls.version.min": 1,
 "security.tls.version.max": 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] #21165 [Applications/TorBirdy]: Uninstall not working

[Tor Bug Tracker & Wiki]

#21165: Uninstall not working
---+-
 Reporter:  thwaller   |  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by sukhbir):

 I am not sure but it does seem like that manually editing the
 configuration could have caused problems, including the residual TorBirdy
 settings. (I just realized that we point this out in
 https://trac.torproject.org/projects/tor/wiki/torbirdy#Branches). And
 while I thought that Thunderbird 51 may have caused issues, I tried to
 reproduce it on two different installations but couldn't. Anyways...

 One way to start clean would be to create a new profile but do realize
 that you have to set your accounts and preferences again. Starting
 Thunderbird with `thunderbird -p` brings up the profile creation dialog
 box. More information at https://support.mozilla.org/t5/Customize-
 controls-options-and/Using-Multiple-Profiles/ta-p/15125.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

[Tor Bug Tracker & Wiki]

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
--+-
 Reporter:  alecmuffett   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 I'm helping some people tune a very large Tor Onion site which has
 recently converted to 2.9.9 and Single Onions.

 There have been some strange reachability issues which I am helping
 triage.

 Analysis is tricky because independent copies of the onion exist in two
 different datacentres, and they both descriptors into the HSDirs.

 To date this configuration has not contributed to any outages that we're
 aware.

 For this ticket the specific onion address is "fbsbx2q4mvcl63pw" - though
 at least one other onion address (out of 3) has been showing the same
 symptoms.

 All onions are configured with "HiddenServiceNumIntroductionPoints 10"

 I have been monitoring the Onion descriptors with a Stem script* that
 prints the HS Descriptor IPs, and over time the listed IPs appear to drop
 from the expected 10, to as low as 4.

 Partial output from the script log, for this morning, is at:

 https://gist.github.com/alecmuffett/2910328730012f9af3410a28e5e6071e

 At 0800h the IPs in retrieved HSDescriptor (reminder: from one of two
 purposely-duplicated HS instances) looked like this, lines 1..12 in the
 Gist; note NumIntroductionPoints/nip=10

 Mon 13 Feb 2017 08:00:55 GMT
 v=2 age=55 nip=10 pub(2017-02-13 08:00:00) now(2017-02-13 08:00:55)
 fbsbx2q4mvcl63pw
 0: 134.19.177.109:443
 1: 178.254.20.134:9001
 2: 185.73.220.8:443
 3: 188.114.140.245:9001
 4: 37.187.4.8:21
 5: 46.101.102.71:443
 6: 46.4.49.201:9001
 7: 62.210.82.44:21
 8: 62.210.92.11:9001
 9: 83.44.207.3:9001

 Yet further down the file, a different descriptor, possibly from the other
 instance (lines 50-57)

 Mon 13 Feb 2017 08:21:03 GMT
 v=2 age=1263 nip=6 pub(2017-02-13 08:00:00) now(2017-02-13 08:21:03)
 fbsbx2q4mvcl63pw
 0: 188.118.217.236:443
 1: 192.42.116.161:9001
 2: 37.187.4.8:21
 3: 80.248.208.131:9001
 4: 82.165.207.102:9001
 5: 88.190.210.240:9001

 ...only 6 introduction points.

 If we assume (?) that it's unlikely for the two daemons to pick the same
 introduction point, the fact that "188.118.217.236:443" is present in all
 the descriptors in lines 40..150 suggests that all these descriptors are
 from the same daemon instance - however the number of introduction points
 varies.

 See attached image for highlight. Is this expected?

 *script: https://github.com/alecmuffett/halfagigonion/blob/master/ls-
 hsdir.py

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

[Tor Bug Tracker & Wiki]

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
--+-
 Reporter:  alecmuffett   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by alecmuffett):

 nb: per the Gist, the descriptor is retrieved and analysed at 5 minute
 intervals.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

[Tor Bug Tracker & Wiki]

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=fd54cffa9335cac2f8c09398da34b85d4fabfd5d
 this commit] for the first half of the changes above.  Shared randomness
 follows later today, I hope.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

[Tor Bug Tracker & Wiki]

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
--+
 Reporter:  alecmuffett   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * cc: dgoulet, asn (added)
 * keywords:   => tor-hs
 * version:   => Tor: 0.2.9.9
 * milestone:   => Tor: 0.3.1.x-final


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

Re: [tor-bugs] #21442 [Core Tor/Tor]: Update to February GeoIP2 database

[Tor Bug Tracker & Wiki]

#21442: Update to February GeoIP2 database
-+-
 Reporter:  karsten  |  Owner:
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.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 029-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * 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

Re: [tor-bugs] #20657 [Core Tor/Tor]: prop224: Implement service support.

[Tor Bug Tracker & Wiki]

#20657: prop224: Implement service support.
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #12424   | Points:  parent
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by asn):

 Hello again.

 I have implemented the time period functionality you asked for. Please
 check my branch `prop224-time-period-v1`.

 It introduces three public functions:
 {{{
 +unsigned int hs_get_time_period_num(time_t now);
 +unsigned int hs_get_next_time_period(time_t now);
 +STATIC int descriptor_overlap_mode_is_active(const networkstatus_t
 *consensus);
 }}}

 Let me know what else you might want, or what other interface you might
 like.

 For example, I think you asked me for a function that returns the start of
 a time period. Why do you want that again? I couldn't find a reason in the
 spec. I can of course do it if it's still useful.

 Also, hope that's a useful overlap mode function for you. Let me know if
 you want a different interface.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21439 [Core Tor/Tor]: Add a configure option to disable safety features that make fuzzing harder

[Tor Bug Tracker & Wiki]

#21439: Add a configure option to disable safety features that make fuzzing 
harder
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I checkpointed some work here in a branch called
 `disable_memory_sentinels`.  Not for review or merge yet: it needs an
 option to turn it on and off.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

[Tor Bug Tracker & Wiki]

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 And there's now [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=3a990a48ca23ff4c5069d50b170761fadeb49018
 another commit] for the second half of the changes above.  Please 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] #21446 [Core Tor/Tor]: Number of Introduction Points for a (SingleOnion?) HS seems variable, or degrades with time

[Tor Bug Tracker & Wiki]

#21446: Number of Introduction Points for a (SingleOnion?) HS seems variable, or
degrades with time
--+
 Reporter:  alecmuffett   |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 The screencap, am I looking at 5 different tor instance or the same tor
 instance but at 5 minutes interval? The former, I would be very worried
 that the same IPs are picked like that. The latter, there is a clear
 rotation of IPs that is not sane...

 Second, do you have any notice or warn or info logs that could be useful
 for this?

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

Re: [tor-bugs] #20657 [Core Tor/Tor]: prop224: Implement service support.

[Tor Bug Tracker & Wiki]

#20657: prop224: Implement service support.
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #12424   | Points:  parent
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by asn):

 I also pushed a topspec branch `prop224-time-period` which addresses some
 spec issues that we identified in IRC. Please ACK it and I will merge
 upstream.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21443 [Metrics/CollecTor]: CollecTor does not delete exit lists after three days anymore

[Tor Bug Tracker & Wiki]

#21443: CollecTor does not delete exit lists after three days anymore
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 Hmm, can you come up with a simple test for this bugfix?

 If not, I'd argue that fixes of recently introduced bugs don't need to be
 accompanied by tests, as opposed to enhancements.  Which probably means
 that we should have written a test when changing this code earlier, which
 might have uncovered the bug in the first place.  But really, I can see
 this trivial fix go in without test.

 And yes, modernization of this code is beyond the scope of this ticket,
 unfortunately.  We should probably think about that when adding other data
 to CollecTor, like webstats.  But that's for another day.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20252 [Metrics/metrics-lib]: Identify changes to dir-spec.txt from proposal 264

[Tor Bug Tracker & Wiki]

#20252: Identify changes to dir-spec.txt from proposal 264
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 I started writing a patch to support these new lines in #20765.  Closing
 as near-duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21309 [Applications/Tor Browser]: Fix Omnibox for TBB/52ESR

[Tor Bug Tracker & Wiki]

#21309: Fix Omnibox for TBB/52ESR
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  #20680  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by mcs):

 Do you know if the `browser.search.*` prefs are set from the values that
 are included in `browser/locales/search/list.json`?

 Also, do we need to change the en-US `US` and `CA` entries in that file? I
 assume the browser uses the `US` entries if it detects that the user is
 located in the USA and CA if in Canada (although maybe we disabled that
 kind of location detection? I cannot remember).

 For non-en-US locales, will it work to just patch
 `browser/locales/search/list.json` for each locale that we care to change?
 That won't work if the language packs override those settings though.

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

Re: [tor-bugs] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)

[Tor Bug Tracker & Wiki]

#20894: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http
(TROVE-2016-10-001)
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-03-unspecified-201612  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  assigned => needs_review
 * priority:  Medium => High


Comment:

 My branch `bug20894_024_v2` is now updated to use a separate function
 here, and to include a unit test.  It's written a little bit oddly for
 backward compatibility with 0.2.4's compiler flags and coding style, but
 it's fairly clean.  Please 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] #20323 [Metrics/metrics-lib]: avoid httpurl connection and use more robust approach

[Tor Bug Tracker & Wiki]

#20323: avoid httpurl connection and use more robust approach
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_information


Comment:

 Hmm, I briefly looked into this issue and tried to reproduce it, but
 failed.  Here's what I did: I placed a large file (100MB) on
 `people.torproject.org`, which is powered by Apache, and attempted to
 download it using `HttpURLConnection`.  This would take less than a minute
 under normal circumstances.  I removed the file from the server a few
 seconds after starting, but the download succeeded without problems.  I
 assume Apache was so kind to cache the file for me.

 But do we really need to analyze this problem, or could we as well kick
 out all mentions of `HttpURLConnection`?  As far as I can see this would
 only affect `DescriptorCollectorImpl` and `DirectoryDownloader`, and we
 could quite easily deprecate both of those.  Wouldn't that fix this issue,
 too?

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

Re: [tor-bugs] #21445 [Applications/Tor Browser]: Launching Tor Browser from the .dmg should obviously fail or install correclty, not neither

[Tor Bug Tracker & Wiki]

#21445: Launching Tor Browser from the .dmg should obviously fail or install
correclty, not neither
--+--
 Reporter:  pastly|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * cc: brade, mcs (added)


Comment:

 Thanks for reporting this. I filed a bug against Firefox because the
 problem occurs there also (no add-ons load when Firefox is opened on a
 read-only filesystem, at least on OSX):
 https://bugzilla.mozilla.org/show_bug.cgi?id=1339100

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21309 [Applications/Tor Browser]: Fix Omnibox for TBB/52ESR

[Tor Bug Tracker & Wiki]

#21309: Fix Omnibox for TBB/52ESR
+--
 Reporter:  arthuredelstein |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  #20680  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arthuredelstein):

 Replying to [comment:8 mcs]:
 > Do you know if the `browser.search.*` prefs are set from the values that
 are included in `browser/locales/search/list.json`?

 Yes, they appear to be.

 > Also, do we need to change the en-US `US` and `CA` entries in that file?
 I assume the browser uses the `US` entries if it detects that the user is
 located in the USA and CA if in Canada (although maybe we disabled that
 kind of location detection? I cannot remember).

 I believe that location detection is disabled, because we have
 browser.search.geoSpecificDefaults set to false.

 > For non-en-US locales, will it work to just patch
 `browser/locales/search/list.json` for each locale that we care to change?
 That won't work if the language packs override those settings though.

 Unfortunately it doesn't work -- the language packs each contains a
 list.json file that overrides these settings. So we'll need to update the
 #18915 patch as I mentioned in comment:7.

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

Re: [tor-bugs] #20430 [Metrics/metrics-lib]: log-level definition for metrics-lib

[Tor Bug Tracker & Wiki]

#20430: log-level definition for metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20540   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Looks like we already turned the error above into a warning as part of
 #20540 where we improved logging of the `index` package.

 What remains to be done here, and which part of that is blocking the 1.6.0
 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] #20430 [Metrics/metrics-lib]: log-level definition for metrics-lib

[Tor Bug Tracker & Wiki]

#20430: log-level definition for metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #20540   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 I see this ticket as reminder to apply the
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/MetricsJavaStyleGuide#Logging
 log-level scheme] we derived in #20540 to all of metrics-lib.

 That is these steps:
 * check current logging and turn any leftover printStackTrace into logging
 or throw an Exception
 * check Exceptions thrown, if the reason rather should be logged and not
 thrown
 * maybe, identify issues worth logging
 and the hidden task of verifying the description of the logging scheme,
 i.e., if it makes sense and is a usable guideline for metrics-lib.

 In total rather a task of spending a fixed amount of time to verify these
 things, not a blocker to the 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] #21306 [Applications/Tor Browser]: Be more helpful in the "cannot connect to tor control" error case

[Tor Bug Tracker & Wiki]

#21306: Be more helpful in the "cannot connect to tor control" error case
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:6 arma]:
 > Ok, we have an osx el capitan person in #tor right now who is getting
 this problem and we have failed to provide useful suggestions because we
 have no idea what might be going wrong on his system.

 Unfortunately I do not have the full #tor backlog so I cannot see what was
 discussed. For OSX, I would first ask the user to try removing or setting
 aside their TorBrowser-Data directory (so they can experience a clean
 start). The most common reason for the "cannot connect to control port"
 problem on OSX is that the user opened a recent alpha of Tor Browser
 (e.g., 7.0a1) and then switched back to a stable version (e.g., TB 6.5).
 Unix domain socket ControlPort config gets left behind in their torrc and
 TB 6.5 does not know how to connect.

 If that does not work, or if they are willing to go deeper, I would ask
 them to enable Tor Launcher and Torbutton debug logging by adding the
 following lines to their prefs.js file (the pref changes can be done via
 about:config instead if they can open Tor Browser enough to get to
 about:config):
  user_pref("extensions.torbutton.loglevel", 0);
  user_pref("extensions.torbutton.logmethod", 0);
  user_pref("extensions.torlauncher.loglevel", 0);
  user_pref("extensions.torlauncher.logmethod", 0);

 Then I would have them start Tor Browser from a Terminal window so the
 browser debug output and the tor output can be captured:
  cd TorBrowser.app
  ./Contents/MacOS/firefox


 > And now we have a windows 10 person there too who has the same problem.

 On Windows, things are harder to debug. As you know, the usual problem is
 interference from AV or other anti-malware software.

 > I think we need to prioritize some testing on normal user systems, so we
 can find out what is going wrong for them and fix it.

 Do you mean "The Tor Browser team should do more testing on various
 systems before they release" or do you mean "The Tor Browser team should
 help specific users who are experiencing this problem debug it?"

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

Re: [tor-bugs] #20323 [Metrics/metrics-lib]: avoid httpurl connection and use more robust approach

[Tor Bug Tracker & Wiki]

#20323: avoid httpurl connection and use more robust approach
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  needs_information
 Priority:  High |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:5 karsten]:
 > [snip]
 > But do we really need to analyze this problem, or could we as well kick
 out all mentions of `HttpURLConnection`?  As far as I can see this would
 only affect `DescriptorCollectorImpl` and `DirectoryDownloader`, and we
 could quite easily deprecate both of those.  Wouldn't that fix this issue,
 too?

 I agree, this seems the best solution here.

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

Re: [tor-bugs] #21443 [Metrics/CollecTor]: CollecTor does not delete exit lists after three days anymore

[Tor Bug Tracker & Wiki]

#21443: CollecTor does not delete exit lists after three days anymore
---+-
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready
 * milestone:   => CollecTor 1.2.0


Comment:

 Making the code testable is part of the modernization.  And, you're right
 this is part of another ticket, which already exists: #20516
 Ticket #20516 and the related ones are currently part of the next
 milestone 1.2.0.

 I added this ticket to milestone 1.2.0.

 Merge ready.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #21369, #21420

[Tor Bug Tracker & Wiki]

Batch modification to #21369, #21420 by nickm:


Action: reassign

--
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] #20957 [Applications/Tor Browser]: Get DieHarder working with Tor Browser

[Tor Bug Tracker & Wiki]

#20957: Get DieHarder working with Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-hardened  |  Actual Points:
Parent ID:  #20955| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 The Die Harder author, Emery Berger, kindly patched DieHarder to fix the
 crashes I reported in comment:1. So here is a new version of the patch
 that uses the updated DieHarder:

 https://github.com/arthuredelstein/tor-browser-bundle/commit/20957+1

 The question in comment:3 is a good one. From my reading, DieHarder looks
 like it has stronger protections that PartitionAlloc, but I could be wrong
 about this and I need to study both more to make a coherent argument.

 In the meantime I would be interested to hear from anyone who wants to try
 this patch out. It might be of interest to deploy DieHarder in one of our
 alpha releases 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] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options

[Tor Bug Tracker & Wiki]

#10281: Investigate usage of alternate memory allocators and memory hardening
options
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, tbb-hardened,  |  Actual Points:
  TorBrowserTeam201612R  |
Parent ID:  #20955   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-

Comment (by tom):

 I'm pasting this here from an email I wrote in Sept 2016.

 > The original problem with PartitionAlloc was the lack of memalign
 > functions and the need to implement them.  They don't seem to have been
 > added, so that problem persists.

 See https://github.com/struct/HardenedPartitionAlloc/issues/1

 > There seem to be some security
 > features that are in OpenBSD's allocator that aren't/can't be in
 > PartitionAlloc, but not all of them.
 >
 > - No inline metadata - PartitionAlloc has this feature as well.
 > - "It is guaranteed to abort for pointers that are not active malloc
 allocations." - not sure about this, but
 http://struct.github.io/partition_alloc.html has a patch for
 PartitionAlloc that does check the freelist for double frees. I'm not sure
 if this is a comprehensive equality of features though
 > - "sets the allocator to abort on out-of-memory by default" - This is
 probably pretty easy to do. (Just a NULL check and an abort() no?)
 > - "Fine-grained randomization is performed for small allocations by
 choosing a random pool to satisfy requests" - okay, but this is like
 'choose a random partition' except not as powerful, cause you're in the
 same heap
 > - "and then choosing a random free slot within a page provided by that
 pool" - PartitionAlloc does not have this, but it could. Here's a patch:
 http://struct.github.io/partition_alloc.html
 > - "Freed small allocations are quarantined before being put back into
 circulation via a randomized delayed allocation pool" - okay,
 PArtitionAlloc doesn't have this
 > - "CopperheadOS uses a ring buffer..." PartitionAlloc doesn't have this
 > - "Small allocations are filled with junk data upon being released." -
 this is easily added
 > - "Canaries can be placed at the end of small allocations to absorb
 small overflows and catch various forms of heap corruption upon free. This
 was a successfully upstreamed CopperheadOS extension. " - PartitionAlloc
 doesn't have this
 >
 >
 >
 > I looked at OpenBSD's allocator, which AFAICT is in openbsd's
 > src/lib/libc/stdlib/malloc.c
 > It contains an implementation of the needed functions: malloc,
 > posix_memalign, calloc, realloc, free, and usable_size
 > It does not contain an implementation of the following, but they should
 > be simple enough to implement: memalign, alligned_alloc, valloc,
 good_size
 >
 > So I think it would be possible to get OpenBSD's allocator in without a
 > ton of pain... But the main things OpenBSD's allocator seems to lack is
 > any sort of partitioning.  So the real gains that Chrome saw and made
 > was moving Layout Objects and Buffer Objects to their own partitions.
 >
 >
 >
 > So that brings us to jemalloc. As far as integration goes: Mozilla has
 > merged in jemalloc 4, but it seems to have a lot of bugs filed against
 > it. Some try results seemed to pass on 4.1.1 but failed on 4.2.  It
 > seems the best thing to do to figure out it's stability is to sit down
 > with Mike Hommey and ask: if we want to enable jemalloc 3, or 4; how
 > stable is it?

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

Re: [tor-bugs] #20957 [Applications/Tor Browser]: Get DieHarder working with Tor Browser

[Tor Bug Tracker & Wiki]

#20957: Get DieHarder working with Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-hardened  |  Actual Points:
Parent ID:  #20955| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 A few comments:

 Are you sure this is using DieHarder as the regular allocator? It's my
 understanding that FF will use mozjemalloc (or jemalloc4) as the
 allocator, and would use the system allocator to allocate space for the
 jemalloc allocator. Which means DieHarder would be allocating memory for
 jemalloc which would be doing all the individual allocations. I think.

 I'll (try to) compare DieHard to PartitionAlloc/Copperhead:
 https://trac.torproject.org/projects/tor/ticket/10281#comment:49

 Some of the features I see in DieHard (I don't think this is exhaustive):
  - randomized freelist selection
  - randomized allocation placement (to some degree I assume)
  - random bytes written on free

 I don't believe they have any partitioning support. In general, it seems
 DieHarder is somewhat comparable to Coppherhead's allocator. It may have
 or lack a few small features that the other has. The lack of partitioning
 is the main strike against it.

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

Re: [tor-bugs] #20657 [Core Tor/Tor]: prop224: Implement service support.

[Tor Bug Tracker & Wiki]

#20657: prop224: Implement service support.
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #12424   | Points:  parent
 Reviewer:   |Sponsor:  SponsorR-must
-+

Comment (by dgoulet):

 Replying to [comment:7 asn]:
 > I also pushed a topspec branch `prop224-time-period` which addresses
 some spec issues that we identified in IRC. Please ACK it and I will merge
 upstream.

 Actually, after playing with the code I propose we back off on this. The
 get period num function needs to do some arithmetic with the period length
 and `time_t now` which if we use `uint32_t`, it gets unpleasant fast
 because `time_t` on x64 is on 8 bytes so we have to check for all
 over/underflow possibilities. Instead, if we keep it to `INT_8()`, we
 avoid this issue entirely and it makes us also much more resilient for the
 post-apocalypse 2038 :).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001) (was: Fix TROVE-2017-001)

[Tor Bug Tracker & Wiki]

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 The problem here is that nothing in our spec unambiguously prevents the
 components of versions being negative, and so the `if ((i = (a-b))) return
 i;` pattern we use in `tor_version_compare()` potentially underflows.

 This is bad when we may have -ftrapv or ubsan enabled: both of those turn
 signed underflow into a crash.  (And it's still undefined behavior in any
 case, which we should really try to prevent.)

 My branch `bug21278_024_v2` tries to fix this, with two approaches:
* `tor_version_compare()` now uses unsigned arithmetic to produce the
 same results while avoiding undefined behavior.  This should mean -- if I
 coded it right -- that we don't have any visible behavior differences form
 before (except "not crashing").
* `dirserv_get_status_impl()` now rejects incoming descriptors with
 negative versions, while leaving voting unchanged.  Changes to this
 function operate at a single authority, and don't require a change in the
 consensus method number.

 ---

 Additionally, I found two more cases where we use the `if ((i = (a-b)))
 return i;` pattern to implement a comparison function.  I believe that
 they are both safe, but somebody should look them over.  The fixes for
 those are in my `bug21278_024_v2_extra` branch, on top of my
 `bug21278_024_v2` branch.

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

Re: [tor-bugs] #21442 [Core Tor/Tor]: Update to February GeoIP2 database

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Merged to 0.2.4 and forward.  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] #21431 [Applications/Tor Browser]: Clean-up system extensions shipped in Firefox 52

[Tor Bug Tracker & Wiki]

#21431: Clean-up system extensions shipped in Firefox 52
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Kathy and I looked at the various system extensions that are present on
 Mozilla's current beta branch (52). Here is what we learned about each of
 them:

 '''aushelper'''
 Modifies app.update.url default pref value to include info for bug 1296630
 The add-on only has an effect on Windows.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1311515

 A similar issue for WebSense was handled via the "HotFix" add-on.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1298404
 and https://hg.mozilla.org/releases/firefox-
 hotfixes/file/tip/v20160826.01/bootstrap.js
 This revision of the HotFix add-on only has an effect on Windows.

 There is a bug open for moving the WebSense update URL modification code
 into the aushelper add-on:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1329692

 '''disableSHA1rollout'''
 Disable SHA-1 based certificates for 10% of beta channel users.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1328718

 '''e10srollout'''
 Enables e10s for a subset of users based on policies that account for
 which update channel the user is on, which add-ons are installed, etc.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1249845

 See also toolkit/mozapps/extensions/internal/E10SAddonsRollout.jsm

 '''flyweb'''
 Only included in Aurora and Nightly builds.
 Internet of Things related. See https://flyweb.github.io/

 '''formautofill'''
 Only included in Aurora and Nightly builds.
 Form Autofill. See https://bugzilla.mozilla.org/show_bug.cgi?id=990176

 '''pdfjs'''
 JavaScript-based PDF viewer.

 '''pocket'''
 Pocket client.

 '''webcompat'''
 Empty / stub extension to allow webcompat fixes to be deployed via the
 add-on update mechanism.
 See https://bugzilla.mozilla.org/show_bug.cgi?id=1268197

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

[Tor Bug Tracker & Wiki]

#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845:
select_entry_guard_for_circuit: Non-fatal assertion
!(!guard_has_descriptor(guard)) failed.
--+
 Reporter:  cypherpunks   |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 The warning here seems to be here, in select_entry_guard_for_circuit()...
 {{{
   SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *,
 guard) {
 entry_guard_consider_retry(guard);
 if (! entry_guard_obeys_restriction(guard, rst))
   continue;
 if (guard->is_reachable != GUARD_REACHABLE_NO) {
   if (need_descriptor && BUG(!guard_has_descriptor(guard))) {
 continue;
   }
 }}}

 And this, in turn, looks like a problem with our 21242 code. We're not
 supposed to be calling select_entry_guard_for_circuit() with
 need_descriptor set while
 guard_selection_have_enough_dir_info_to_build_circuits() is false, right?

 Though hm, that function only checks to make sure that the first
 num_primary possibly reachable guards all have descriptors.  If enough of
 them seem down, there's a decent chance that we'll turn to a position
 where we might have to update our 'can build circuits' flag.

 If that's so, then the right fix here is probably either to remove the BUG
 guard on the check.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21431 [Applications/Tor Browser]: Clean-up system extensions shipped in Firefox 52

[Tor Bug Tracker & Wiki]

#21431: Clean-up system extensions shipped in Firefox 52
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 Based on our research, Kathy and I think the only system extension we
 should consider shipping with Tor Browser is pdfjs (we did not review
 recent changes to pdfjs).

 For e10s, we will probably enable it for everyone or no one. For disabling
 of SHA-1 signatures, we already have the fix for #18042. The remaining
 system add-ons don't seem necessary.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

[Tor Bug Tracker & Wiki]

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Hm, still a bit confusing.  Let's think.

 We're reaching entry_guard_add_to_sample_impl() with an RSA id that's
 already a sampled guard in gs.

 So therefore (assuming that we're handling bridges right [1]) we're
 calling entry_guard_add_bridge_to_sample() with a bridge whose
 bridge_get_rsa_id_digest() is giving us an id we already have.

 That, in turn, implies that select_and_add_guard_item_for_sample() chose
 that bridge.

 And '''that''' in turn implies that get_eligible_guards() gave it to us as
 a possibility.

 But that implies that get_sampled_guard_for_bridge gave us NULL for that
 guard, which shouldn't be possible if we already know a bridge with that
 ID.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21432 [Applications/Tor Browser]: Make a plan on how to deploy e10s in Tor Browser

[Tor Bug Tracker & Wiki]

#21432: Make a plan on how to deploy e10s in Tor Browser
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff52-esr, TorBrowserTeam201702  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by mcs):

 My feeling is that we should keep things as simple as possible: once we
 make sure that the add-ons we bundle are working correctly with multiple
 processes, we should enable e10s by default for all Tor Browser users.
 Most of what Mozilla is doing is to accommodate add-ons that do not
 support e10s, but since we do not really support third party add-ons it
 seems reasonable for Tor Browser to use a simpler approach than Firefox.
 Also, if we believe https://wiki.mozilla.org/Electrolysis#Schedule then
 e10s mode will be on by default for all Firefox 52 users (I am not sure if
 something different will be done for the ESR though).

 If we adopt this approach, it means that someone who wants to use an add-
 on that is not compatible with e10s will need to turn off e10s mode via
 about:config. Mozilla has used several different prefs to control e10s
 (which has led to some confusion), so we will need to ensure that we
 provide good instructions on how to disable it.

 There is also a chance that we will discover that e10s mode in ESR52 is
 too slow or not stable enough to turn on by default.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21027 [Core Tor/Tor]: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816: entry_guard_add_to_sample_impl: Non-fatal assertion !(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (o

[Tor Bug Tracker & Wiki]

#21027: tor_bug_occurred_(): Bug: src/or/entrynodes.c:816:
entry_guard_add_to_sample_impl: Non-fatal assertion
!(have_sampled_guard_with_id(gs, rsa_id_digest)) failed. (on Tor 0.3.0.0
-alpha-dev 8b75261b6dc341de)
-+-
 Reporter:  asn  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-guards-revamp,|  Actual Points:
  regression |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Oh. Now I think I get it.  There's a possibility that the same bridge is
 listed twice among our bridges in bridge_list_get().  If that happens, if
 we go to add two bridges at a time for some reason, we'll add that bridge
 twice.

 Does my branch `bug21027_testing` branch make this bug go away?  Or does
 it change the warning at all?

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

Re: [tor-bugs] #21420 [Core Tor/Tor]: Link certificate start date in the future

[Tor Bug Tracker & Wiki]

#21420: Link certificate start date in the future
--+
 Reporter:  mmcloughlin   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * keywords:   => 029-backport


Comment:

 Hm.  It looks like we started using that approach in 0196647970a91d, but
 I'm not at all sure that's right.  I think we wanted to do something like
 choosing a start time at the start of a day, between this most recent
 midnight, and up to cert_lifetime in the past, but making sure that we
 don't wind up with an expiration time in the past.

 My branch `bug21420_029` in my public git repository [1] tries to fix
 this.  I've marked it as a possible backport to 0.2.9, but I believe it's
 safe to leave this as-is in existing tors, since
 check_cert_lifetime_internal() is called with a 30-day future tolerance.

 [1]
 
https://gitweb.torproject.org/nickm/tor.git/commit/?h=bug21420_029&id=d839f798a5812fc81fcc5b4b06604ed08dc2e558
 for the HTML version;
 https://git.torproject.org/nickm/tor.git for the repository itself.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 Fyi, I merged a changes entry to 0.2.[4567] so we are sure to remember to
 include it in the upcoming changelogs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21369 [Core Tor/Tor]: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832]

[Tor Bug Tracker & Wiki]

#21369: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < 
INT_MAX
failed in write_to_buf at ../src/or/buffers.c:832]
--+
 Reporter:  svengo|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Critical  | Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 My branch `bug21269_check` adds some testing code to check some possible
 causes of this bug.  If you can reproduce the bug with this code enabled,
 that would be great.

 It's also worth reviewing this for merge into 0.3.0, to see if it helps
 prevent or locate 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

Re: [tor-bugs] #21369 [Core Tor/Tor]: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832]

[Tor Bug Tracker & Wiki]

#21369: Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < 
INT_MAX
failed in write_to_buf at ../src/or/buffers.c:832]
--+
 Reporter:  svengo|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.9
 Severity:  Critical  | Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 err, that should be `bug21369_check`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21116 [Core Tor/Tor]: fix building on raspbian wheezy

[Tor Bug Tracker & Wiki]

#21116: fix building on raspbian wheezy
--+
 Reporter:  hein  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I'll merge as-is ; my lint script will catch that for me. :)

 Thanks, all!

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

Re: [tor-bugs] #21206 [Core Tor/Tor]: Measure client up/down bandwidth for directory requests, split by type

[Tor Bug Tracker & Wiki]

#21206: Measure client up/down bandwidth for directory requests, split by type
--+
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:  #21205| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 I've updated my branch to support keeping information on the number of
 sent and received `RELAY_DATA` cells. This should allow us to calculate
 the following overheads as mentioned above:

 - The number of bytes sent/received in the payloads.
 - The number of cells containing data that have been passed over the
 directory connection.

 We should therefore be able to estimate:
 - Relay cell headers.
 - Padding bytes.

 I'm unsure how we should measure/estimate the TLS record sizes and the
 circuit headers/cells needed to setup the directory connection. I'll have
 to dig into that to be sure.

 I've left the two additional `unsigned data_cells_received` and `unsigned
 data_cells_sent` members on `dir_connection_t` as unguarded, since their
 lifetime is relatively short. If we do not want to have them around unless
 for very specific builds I'll wrap them in a guard.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21447 [Core Tor/Tor]: Rename 'make fuzz'

[Tor Bug Tracker & Wiki]

#21447: Rename 'make fuzz'
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 21:25 < nickm> 'make fuzz' should get renamed, I think.
 21:25 < nickm> It only looks at static inputs, which you might not even
 have

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21447 [Core Tor/Tor]: Rename 'make fuzz'

[Tor Bug Tracker & Wiki]

#21447: Rename 'make fuzz'
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #21420 [Core Tor/Tor]: Link certificate start date in the future

[Tor Bug Tracker & Wiki]

#21420: Link certificate start date in the future
--+
 Reporter:  mmcloughlin   |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I think you're right that commit 0196647 is the problem here.

 I suspect you're right that fixing the underlying math is the right
 answer.

 However, I'm unable to follow the math here:
 {{{
 -  start_time = crypto_rand_time_range(now - cert_lifetime, now) +
 2*24*3600;
 +  const time_t min_real_lifetime = 2*24*3600;
 +  time_t earliest_start_time = now - cert_lifetime + min_real_lifetime;
 +  if (earliest_start_time < now)
 +earliest_start_time = now;
 +  start_time = crypto_rand_time_range(earliest_start_time, now);
 }}}

 Maybe some more comments to explain what we're computing, and *why*, would
 help?

 Looking at the origin commit, it seems maybe I wanted to say "- 2 days",
 not "+ 2 days". Would that resolve everything here?

 Maybe I am deeply confused, but won't
 {{{
 +  if (earliest_start_time < now)
 +earliest_start_time = now;
 +  start_time = crypto_rand_time_range(earliest_start_time, now);
 }}}
 trigger the assert in crypto_rand_time_range() that min < max, since we'll
 be passing it "now, now"?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21439 [Core Tor/Tor]: Add a configure option to disable safety features that make fuzzing harder

[Tor Bug Tracker & Wiki]

#21439: Add a configure option to disable safety features that make fuzzing 
harder
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 now ready for 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] #21420 [Core Tor/Tor]: Link certificate start date in the future

[Tor Bug Tracker & Wiki]

#21420: Link certificate start date in the future
--+
 Reporter:  mmcloughlin   |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:5 arma]:
 >
 > Maybe some more comments to explain what we're computing, and *why*,
 would help?

 Okay, will do.

 > Looking at the origin commit, it seems maybe I wanted to say "- 2 days",
 not "+ 2 days". Would that resolve everything here?

 I thought about it, but if you had done that, it would be possible to have
 the start time be "now - lifetime - 2 days".  And the end time would be
 "start + lifetime", which would result in an already-expired certificate.

 > Maybe I am deeply confused, but won't
 > {{{
 > +  if (earliest_start_time < now)
 > +earliest_start_time = now;
 > +  start_time = crypto_rand_time_range(earliest_start_time, now);
 > }}}
 > trigger the assert in crypto_rand_time_range() that min < max, since
 we'll be passing it "now, now"?

 ohhh, yeah. Better fix that too.

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

Re: [tor-bugs] #20894 [Core Tor/Tor]: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http (TROVE-2016-10-001)

[Tor Bug Tracker & Wiki]

#20894: Resolve read-off-end-of-buffer on atoi in fetch_from_buf_http
(TROVE-2016-10-001)
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.3.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-03-unspecified-201612  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Can `headers+headerlen` can wrap here?

 If so, we also need:
 `tor_assert(headers < SIZE_T_MAX - headerlen);`
 Before every time we do `headers+headerlen`.
 (And before:
 `p = (char*) tor_memstr(headers, headerlen, CONTENT_LENGTH);`
 which effectively does `headers+headerlen`.)

 Please credit AFL in the changes file:

 Discovered by fuzzing using AFL: http://lcamtuf.coredump.cx/afl/

 Replying to [ticket:20894 teor]:
 > It would be nice to email the maintainer with this ticket number and let
 them know, so they can add it to their gallery.

 I emailed the AFL maintainer today and CC'd tor-team.
 This bug is now linked from http://lcamtuf.coredump.cx/afl/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

[Tor Bug Tracker & Wiki]

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 0a2abb3780:

 The function comment change does not describe what the function now does:
 it only returns 0 or 1. And it says "renturn".

 4e720ad736:

 else has an extra space in:

 {{{
 +  if (a->git_tag_len)
 + return fast_memcmp(a->git_tag, b->git_tag, a->git_tag_len);
 +   else
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

[Tor Bug Tracker & Wiki]

#21448: Identify what build flags we should be using for security, and use them
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I think we are probably forgetting some configure/compiler/linker flags in
 Tor Browser that can improve security. Let's figure out what those are and
 add them. I would suggest child tickets for each new flag, so we can do
 this step by step.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

[Tor Bug Tracker & Wiki]

#21448: Identify what build flags we should be using for security, and use them
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Using about:buildconfig, the browser reports compiler flags and configure
 arguments for our tor-browser.git builds. Are these a complete list of the
 compiler flags actually used? I don't know. In any case, here are the
 current reports:

 Linux TBB 6.5:
 {{{
 target
 x86_64-unknown-linux-gnu

 Build tools
 CompilerVersion Compiler flags
 gcc 5.1.0   -Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare
 -Wtype-limits -Wno-unused -Wcast-align -frandom-seed=tor -std=gnu99
 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread -pipe
 c++ 5.1.0   -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare
 -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -frandom-seed=tor -fno-
 exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno
 -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os
 -fomit-frame-pointer

 Configure arguments
 --enable-application=browser --enable-optimize --enable-official-branding
 --enable-tor-browser-update --enable-update-packaging --enable-signmar
 --enable-verify-mar --disable-strip --disable-install-strip --disable-
 tests --disable-debug --disable-maintenance-service --disable-
 crashreporter --disable-webrtc --disable-eme --disable-loop --with-tor-
 browser-version=6.5 --enable-update-channel=release --enable-bundled-fonts
 }}}

 Windows TBB 6.5:
 {{{
 target
 i686-w64-mingw32

 Build tools
 CompilerVersion Compiler flags
 i686-w64-mingw32-gcc -mwindows  5.1.0   -Wall -Wempty-body -Wpointer-to-
 int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -Wno-format
 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -mms-bitfields
 -mstackrealign -fno-keep-inline-dllexport -fno-math-errno -pipe
 i686-w64-mingw32-g++ -mwindows  5.1.0   -Wall -Wempty-body -Woverloaded-
 virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align
 -Wno-format -fno-exceptions -fno-strict-aliasing -mms-bitfields
 -mstackrealign -fno-keep-inline-dllexport -fno-rtti -fno-exceptions -fno-
 math-errno -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -g -O -fomit-frame-
 pointer

 Configure arguments
 --enable-application=browser --target=i686-w64-mingw32 --enable-default-
 toolkit=cairo-windows --disable-debug --enable-optimize --enable-strip
 --enable-official-branding --enable-tor-browser-update --enable-update-
 packaging --enable-signmar --enable-verify-mar --disable-sandbox
 --disable-eme --disable-crashreporter --disable-maintenance-service
 --disable-webrtc --disable-tests --disable-loop --with-tor-browser-
 version=6.5 --enable-update-channel=release --enable-bundled-fonts
 }}}

 Mac TBB 6.5:
 {{{
 target
 x86_64-apple-darwin

 Build tools
 CompilerVersion Compiler flags
 /home/debian/build/tor-browser/clang/bin/clang -target x86_64-apple-
 darwin10 -mlinker-version=136 -B /home/debian/build/tor-
 browser/cctools/bin -isysroot /home/debian/build/tor-
 browser/MacOSX10.7.sdk 3.8.0   -Qunused-arguments -Wall -Wempty-body
 -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -std=gnu99
 -fno-strict-aliasing -fno-math-errno -pthread -DNO_X11 -pipe
 /home/debian/build/tor-browser/clang/bin/clang++ -target x86_64-apple-
 darwin10 -mlinker-version=136 -B /home/debian/build/tor-
 browser/cctools/bin -isysroot /home/debian/build/tor-
 browser/MacOSX10.7.sdk   3.8.0   -Qunused-arguments -Qunused-arguments
 -Wno-unused-local-typedef -Wall -Wempty-body -Woverloaded-virtual -Wsign-
 compare -Wwrite-strings -Wno-invalid-offsetof -Wno-inline-new-delete -Wno-
 unused-local-typedef -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-
 unknown-warning-option -Wno-return-type-c-linkage -fno-exceptions -fno-
 strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x
 -pthread -DNO_X11 -pipe -DNDEBUG -DTRIMMED -g -O3 -fomit-frame-pointer

 Configure arguments
 --target=x86_64-apple-darwin --with-macos-private-
 frameworks=/home/debian/build/tor-
 browser/MacOSX10.7.sdk/System/Library/PrivateFrameworks --enable-
 application=browser --enable-strip --enable-official-branding --enable-
 optimize --disable-debug --enable-tor-browser-data-outside-app-dir
 --enable-tor-browser-update --enable-update-packaging --enable-signmar
 --enable-verify-mar --disable-crashreporter --disable-maintenance-service
 --disable-webrtc --

Re: [tor-bugs] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

[Tor Bug Tracker & Wiki]

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Also, from arma:

 4e720ad736:

 {{{
 This bug is harmless, except when Tor has been build with
 }}}

 s/build/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] #21449 [Core Tor/Tor]: Make tor version parsing and version spec consistent

[Tor Bug Tracker & Wiki]

#21449: Make tor version parsing and version spec consistent
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-spec
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+--
 In tor_version_compare, the git logic is a bit weird, because git tags are
 hashes: the ordering we apply isn't their true order. So the function
 comment should probably become:

 {{{
 /** Compare two tor versions; Return <0 if a < b; 0 if a ==b, >0 if a >
 * b. Git tags are sorted by length, then value. */
 }}}

 But this doesn't match version-spec.txt:

 {{{
 The EXTRA_INFO is also purely informational, often containing information
 about the SCM commit this version came from. It is surrounded by
 parentheses
 and can't contain whitespace. Unlike the STATUS_TAG this never impacts the
 way
 that versions should be compared.
 }}}

 We should try to ignore the git tag, or at least be very careful how we
 compare it. Due to bugs like #20492, the following versions are
 equivalent:
 {{{
 Tor 0.2.9.9 (git-56788a2489127072)
 Tor 0.2.9.9
 }}}

 (But these are not equivalent to any other git tag on Tor 0.2.9.9, which
 should never happen anyway.)

 This is important when we try to exclude versions, like in #20509, because
 we need to exclude the version with and without the git tag.

 This fix might require a new consensus method.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21449 [Core Tor/Tor]: Make tor version parsing and version spec consistent

[Tor Bug Tracker & Wiki]

#21449: Make tor version parsing and version spec consistent
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 The svn logic in tor_version_as_new_as doesn't work for git tags:
 {{{
   /* Here's why we don't need to do any special handling for svn
 revisions:
* - If neither has an svn revision, we're fine.
* - If the router doesn't have an svn revision, we can't assume that it
*   is "at least" any svn revision, so we need to return 0.
* - If the target version doesn't have an svn revision, any svn
 revision
*   (or none at all) is good enough, so return 1.
* - If both target and router have an svn revision, we compare them.
*/
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201612, review-group-15 |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 This issue is affected by #21449, so we actually need to exclude versions:
 {{{
 0.3.0.0-alpha-dev <= version < 0.3.0.1-alpha-dev
 }}}
 which is equivalent to checking for this version regardless of git tag:
 {{{
 0.3.0.0-alpha-dev <= version <= 0.3.0.1-alpha-dev (git-
 )
 }}}

 The 0.2.9 check is correct - it includes all of 0.2.9.4-alpha-dev
 regardless of git tags.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20509 [Core Tor/Tor]: Directory authorities should take away Guard flag from relays with #20499 bug

[Tor Bug Tracker & Wiki]

#20509: Directory authorities should take away Guard flag from relays with 
#20499
bug
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.9
 Severity:  Normal   | Resolution:
 Keywords:  028-backport, easy,  |  Actual Points:
  TorCoreTeam201612, review-group-15 |
Parent ID:   | Points:
 Reviewer:  teor, arma   |Sponsor:
-+-

Comment (by teor):

 The best way of doing this is to use tor_version_same_series().

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21449 [Core Tor/Tor]: Make tor version parsing and version spec consistent

[Tor Bug Tracker & Wiki]

#21449: Make tor version parsing and version spec consistent
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Here's how to do an equality check right:
 (Every check must be a range check, not an equality check.)
 https://trac.torproject.org/projects/tor/ticket/20509#comment:39
 https://trac.torproject.org/projects/tor/ticket/20509#comment:40

 I think all the current tor code is ok, but it's easy to mess up these
 comparisons.

 We should add a comment to tor_version_compare() recommending using
 !tor_version_as_new_as(next version) or tor_version_same_series(), to
 avoid the git tag 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

Re: [tor-bugs] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

[Tor Bug Tracker & Wiki]

#21448: Identify what build flags we should be using for security, and use them
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 For comparison, here are the current Firefox release build flags:

 Linux Firefox 51.01

 {{{
 target
 x86_64-pc-linux-gnu
 Build tools
 CompilerVersion Compiler flags
 /builds/slave/m-rel-l64-/build/src/gcc/bin/gcc
 -std=gnu99   4.8.5   -Wall -Wempty-body -Wignored-qualifiers -Wpointer-
 arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-
 uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds
 -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -fno-strict-
 aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread
 -pipe
 /builds/slave/m-rel-l64-/build/src/gcc/bin/g++
 -std=gnu++11 4.8.5   -Wall -Wc++11-compat -Wempty-body -Wignored-
 qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-
 limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wno-error
 =maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-
 bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -fno-
 exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-
 sections -fno-exceptions -fno-math-errno -pthread
 -D_GLIBCXX_USE_CXX11_ABI=0 -pipe -g -fprofile-use -fprofile-correction
 -Wcoverage-mismatch -O3 -fomit-frame-pointer -Werror
 Configure options

 MOZ_AUTOMATION=1 --enable-update-channel=release
 
PKG_CONFIG=/builds/slave/m-rel-l64-/build/src/gtk3/usr/local/bin
 /pkg-config --enable-js-shell --enable-default-toolkit=cairo-gtk3 --with-
 mozilla-api-keyfile=/builds/mozilla-desktop-geoloc-api.key --with-google-
 api-keyfile=/builds/gapi.data MOZ_PGO=1
 CC=/builds/slave/m-rel-l64-/build/src/gcc/bin/gcc
 CXX=/builds/slave/m-rel-l64-/build/src/gcc/bin/g++
 --enable-rust
 RUSTC=/builds/slave/m-rel-l64-/build/src/rustc/bin/rustc
 CARGO=/builds/slave/m-rel-l64-/build/src/cargo/bin/cargo
 MAKE=/usr/bin/gmake --enable-crashreporter --enable-elf-hack --enable-
 official-branding --enable-release --enable-stdcxx-compat --enable-verify-
 mar
 }}}

 Windows Firefox 51.01:
 {{{
 target
 i686-pc-mingw32

 Build tools
 CompilerVersion Compiler flags
 
c:/builds/moz2_slave/m-rel-w32-/build/src/vs2015u3/VC/bin/amd64_x86/cl.EXE
 19.00.24213 -TC -nologo -wd4091 -D_HAS_EXCEPTIONS=0 -W3 -Gy -Zc:inline
 -arch:SSE2 -FS -wd4244 -wd4267 -wd4819 -we4553
 
c:/builds/moz2_slave/m-rel-w32-/build/src/vs2015u3/VC/bin/amd64_x86/cl.EXE
 19.00.24213 -TP -nologo -wd5026 -wd5027 -Zc:sizedDealloc-
 -Zc:threadSafeInit- -wd4091 -wd4577 -D_HAS_EXCEPTIONS=0 -W3 -Gy -Zc:inline
 -arch:SSE2 -FS -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4800 -wd4819
 -wd4595 -we4553 -GR- -Zi -GL -wd4624 -wd4952 -O1 -Oi -Oy

 Configure options
 MOZ_AUTOMATION=1 'MOZILLABUILD=C:\mozilla-build' --enable-update-
 channel=release --enable-js-shell --enable-eme=+adobe --with-mozilla-api-
 keyfile=c:/builds/mozilla-desktop-geoloc-api.key --with-google-api-
 keyfile=c:/builds/gapi.data MOZ_PGO=1
 
WINDOWSSDKDIR=c:/builds/moz2_slave/m-rel-w32-/build/src/vs2015u3/SDK
 --enable-rust
 
RUSTC=c:/builds/moz2_slave/m-rel-w32-/build/src/rustc/bin/rustc
 
CARGO=c:/builds/moz2_slave/m-rel-w32-/build/src/cargo/bin/cargo
 --enable-jemalloc
 MAKE=c:/builds/moz2_slave/m-rel-w32-/build/src/mozmake.EXE
 --enable-crashreporter --enable-official-branding --enable-release
 --enable-require-all-d3dc-versions --enable-verify-mar
 }}}

 Mac Firefox 51.01:
 {{{
 target
 x86_64-apple-darwin11.2.0

 Build tools
 CompilerVersion Compiler flags
 /usr/local/bin/ccache
 /builds/slave/m-rel-m64-/build/src/clang/bin/clang
 -arch x86_64 -std=gnu993.8.0   -Qunused-arguments -Wall -Wempty-body
 -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits
 -Wunreachable-code -Wclass-varargs -Wloop-analysis -Werror=non-literal-
 null-conversion -Wstring-conversion -Wthread-safety -Wno-error=deprecated-
 declarations -Wno-error=array-bounds -isysroot
 /Developer/SDKs/MacOSX10.7.sdk -fno-strict-aliasing -ffunction-sections
 -fdata-sections -fno-math-errno -pthread -pipe
 /usr/loca

Re: [tor-bugs] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

[Tor Bug Tracker & Wiki]

#21448: Identify what build flags we should be using for security, and use them
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * keywords:   => tbb-security


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21450 [Core Tor/Tor]: Consistently parse tor versions regardless of word size

[Tor Bug Tracker & Wiki]

#21450: Consistently parse tor versions regardless of word size
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 We use strtol() in tor_version_parse(), but longs are different sizes on
 32-bit and 64-bit.

 Casting long to int means that some versions that look different on 64-bit
 platforms could be truncated and look the same on 32-bit platforms. And
 some versions that parse on 64-bit platforms fail to parse on 32-bit
 platforms (particularly after #21278, because the cast makes some of them
 negative).

 This fix does not need a new consensus method, because we reject router
 descriptors with version components that don't parse in #21278.

 Here's my patch:
 {{{
 diff --git a/src/or/routerparse.c b/src/or/routerparse.c
 index 58b9a22438..9d8ef11ac7 100644
 --- a/src/or/routerparse.c
 +++ b/src/or/routerparse.c
 @@ -4840,6 +4840,7 @@ tor_version_parse(const char *s, tor_version_t *out)
  {
char *eos=NULL;
const char *cp=NULL;
 +  int ok = 1;
/* Format is:
 *   "Tor " ? NUM dot NUM [ dot NUM [ ( pre | rc | dot ) NUM ] ] [ -
 tag ]
 */
 @@ -4855,7 +4856,9 @@ tor_version_parse(const char *s, tor_version_t *out)

  #define NUMBER(m)   \
do {  \
 -out->m = (int)strtol(cp, &eos, 10); \
 +out->m = (int)tor_parse_uint64(val, 10, 0, INT32_MAX, &ok, &eos); \
 +if (!ok)\
 +  return -1;\
  if (!eos || eos == cp)  \
return -1;\
  cp = eos;   \
 }}}

 This might also need a torspec patch saying that INT_MAX is the limit, or
 that implementations can place limits on version 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] #21278 [Core Tor/Tor]: Avoid signed integer underflow when comparing versions (Fix TROVE-2017-001)

[Tor Bug Tracker & Wiki]

#21278: Avoid signed integer underflow when comparing versions (Fix 
TROVE-2017-001)
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  029-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Also, I think we should patch the 64-bit to 32-bit truncation bug in
 #21450 at the same time as this.

 It means that 32-bit and 64-bit tors treat version components >= INT32_MAX
 differently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

[Tor Bug Tracker & Wiki]

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:4 karsten]:
 > Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-20765-2&id=fd54cffa9335cac2f8c09398da34b85d4fabfd5d
 this commit] for the first half of the changes above.  Shared randomness
 follows later today, I hope.

 Tests and checks pass.
 For checking the upper limit it would be a little more readable to use
 `0x1__L` instead of 4294967296L.
 (Just a thought, should `Number` be used instead of `Long` as the protocol
 numbers have unsigned int range?)

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