[tor-bugs] #15197 [Tor Browser]: Rebase Tor Browser patches to ESR 45

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Apr 4 17:44:44 UTC 2016


#15197: Rebase Tor Browser patches to ESR 45
--------------------------------------------+------------------------------
 Reporter:  gk                              |          Owner:
     Type:  task                            |  arthuredelstein
 Priority:  Very High                       |         Status:
Component:  Tor Browser                     |  needs_revision
 Severity:  Critical                        |      Milestone:
 Keywords:  ff45-esr, TorBrowserTeam201604  |        Version:
Parent ID:                                  |     Resolution:
 Reviewer:                                  |  Actual Points:
                                            |         Points:
                                            |        Sponsor:  SponsorU
--------------------------------------------+------------------------------

Comment (by bugzilla):

 Replying to [comment:18 gk]:
 > 79a6c2a9971a596511b5902b44e074b825c5f465 and
 {{{tbb-hardened}}} is separated from others, thus that patch wasn't
 squashed. That's no good, and the whole conception should be revised:
 separation of hardened and testing/debug versions is required - hardening
 features such as DEP/ASLR are on all versions, but debug features such as
 Sanitizer/Wrap (from GCC manual) are on hardened that is not secure
 (http://www.openwall.com/lists/oss-security/2016/02/17/9). Next, some
 debug facilities can be used only one after another and not together, so
 several configs are required, but ASan can be combined with some others,
 so special config for ASan is not needed.
 {{{
 # Mandatory flags for ASan
 export ASANFLAGS="-fsanitize=address -Dxmalloc=myxmalloc -fPIC"
 }}}
 {{{-fPIC}}} can't harm, but if after adding it something (hashes)
 changes...
 Mozilla thinks the same: https://developer.mozilla.org/en-
 US/docs/Mozilla/Testing/Firefox_and_Address_Sanitizer
 {{{-fsanitize-trap-on-error}}} could be used if you have problems with
 libraries.
 > +# We need to add -ldl explicitely due to bug 1213698
 > +export LDFLAGS="-fsanitize=address -ldl"
 For this awful crap Mozilla's apologizes should be added:
 ># Additionally, we need the ASan flag during linking. Normally, our
 C/CXXFLAGS would
 ># be used during linking as well but there is at least one place in our
 build where
 ># our CFLAGS are not added during linking.
 ># Note: The use of this flag causes Clang to automatically link the ASan
 runtime :)
 So, here is your "bug 1213698" comes from: compiler options for ld???
 (undocumented? or useless), GCC 5+ starts to pass all requirements for
 linking to ld, thus it passed "no ASan" for parts without CFLAGS...
 Bottom change for Ubuntu Lucid can be removed.
 > 4b81ffadd3ccdc95b208b9594231c5d8b09ff09d => into one .mozconfig related
 commit?
 Better to remove than to merge. See #17983.
 > ae367aad222b70d37e5de936dd594e9cdc554ef1 -- could you put the block in
 AsnycResolveExtended() again after `if (mNotifyResolution) {}`? Might be
 helpful for debugging things (observer notification gets still fired even
 if DNS resolution does not get through)?
 {{{
 12:12:25.697 [Exception... "Component returned failure code: 0x804b002a
 (NS_ERROR_UNKNOWN_PROXY_HOST) [nsIDNSService.asyncResolve]"  nsresult:
 "0x804b002a (NS_ERROR_UNKNOWN_PROXY_HOST)"  location: "JS frame ::
 chrome://browser/content/browser.js :: gKeywordURIFixup :: line 11572"
 data: no]1 browser.js:11577:0
 }}}
 Is this from that patch? Is this correct to end with exc?
 > 094a68930f2d0f17ddc7a50339cc19a4bae44e6c -- okay but it seems to be not
 needed anymore, see: https://bugzilla.mozilla.org/show_bug.cgi?id=962334,
 no?
 It doesn't interfere with anything, so it can be removed when that feature
 will be removed.
 > 850e2636cd7526cf9631ac629b1f5c45148e98c1 -- okay (why is this still
 needed after
 > https://bugzilla.mozilla.org/show_bug.cgi?id=429070 got fixed years
 ago?)
 Because it's a "bugfix" for
 https://bugzilla.mozilla.org/show_bug.cgi?id=790732 :)
 As #2874 was filed as "Block Ci", Mozilla's new bug or feature "Ci shim"
 (for compatibility only or not? They didn't state!) was addressed in that
 ticket too. Maybe, filing or stating "regression" could be helpful.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15197#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list