--enable-expensive-hardening broken with clang

When passing -fsanitize=address, clang internally defines _FORTIFY_SOURCE=0. This conflicts with the _FORTIFY_SOURCE=2 we like to set beforehand, so we don't enable -fsanitize=address at all. Perhaps we should try to use fsanitize-address, if it fails try again with _FORTIFY_SOURCE remoeved, and only then resolve that it isn't available.

I am calling this 0.2.7 territory for now, but if the fix turns out to be easy we could conceivably backport it.

changed milestone to %Tor: 0.2.8.x-final

added 027-backport 2016-bug-retrospective component::core tor/tor milestone::Tor: 0.2.8.x-final priority::high resolution::fixed severity::normal status::closed type::defect labels

https://code.google.com/p/address-sanitizer/issues/detail?id=247

Ok, my idea above was not a good one. We should prefer FORTIFY_SOURCE over AddressSanitizer. Will have to use gcc I guess unless there's a great idea for this somewhere

Is FORTIFY_SOURCE really better than asan?

According to the link it is, and I thought deferring to the asan people on this was smart.

Trac:
Cc: N/A to gk

I'm starting to re-evaluate my opinion if we shouldn't just get rid of FORTIFY_SOURCE=2 if it breaks -fsanitize=address. I've recently patched my configure script to allow just that very frequently to track down a bunch of bugs. In production builds which don't use expensive hardening we still have the FORTIFY_SOURCE

Trac:
Status: new to assigned

Marking triaged-out items from first round of 0.2.7 triage.

Trac:
Keywords: N/A deleted, 027-triaged-1-out added

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Given the bugginess of some of GCC's hardening options, I think, we should look harder at this.

Trac:
Severity: N/A to Normal
Priority: Medium to High
Milestone: Tor: 0.2.??? to Tor: 0.2.8.x-final
Sponsor: N/A to N/A

ug, apparently clang 3.7 broke everybody by messing up autotools builds, so that clang only builds its sanitizers correctly with cmake. So first I had to fix that on my desktop.

Then I managed to figure out that the only compilation problems were related to strcmp() and to some parenthesis in test_util.

And then I realized that it's going to complain a lot about leaks in the tests unless I say ASAN_OPTIONS=detect_leaks=0 .

And I found a couple of actual bugs with the tests, so I'm going to open tickets for those. But for now, the branch bug14821 could be what we need here. The part of this not applying to test_util.c could be an 0.2.7 backport but I'm a bit nervous.

Trac:
Keywords: 027-triaged-1-out deleted, 027-backport added

Trac:
Status: assigned to needs_review

Backported to 0.2.7 as 67e5d49d8a995c6d3b8bf4177046271a7d4dd157 ; part left in master as 1318c1611fed301f44d69a2d6e4f012efd94c9cc.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Mark more tickets for severe bug retrospective, based on Priority and date and hand-inspection.

Trac:
Keywords: N/A deleted, 2016-bug-retrospective added

closed

mentioned in issue #17508 (moved)

moved to tpo/core/tor#14821 (closed)

mentioned in issue tpo/applications/tor-browser#17508 (closed)