> for everything else this merely results in unnecessary bloat and slowness.
If you care about performance, then surely you have benchmarks to show the detrimental effects of these build options.

> If you care about performance, then surely you have benchmarks to show the detrimental effects of these build options.

or, to put it in different way, where were benchmarks that pie and ssp no not result in bloat when these options were introduced in the first place?
Where are proofs, that these options really increase security?

Searching the mailing lists will turn up plenty of testing.

As for proof that the options increase security, if you had any idea at all of what those options did, you wouldn't be asking that question.

I know very well what those options do and I disagree that they should be universally used. These are mitigations for buffer overflows, which while still not uncommon, are only a problem in a small number of apps that work with untrusted data. A web browser may get some benefit from them, or a pdf viewer. But for everything else, there is no benefit whatsoever. That's no benefit for perhaps 99% of the packages installed. Why would anyone in their right mind think it's worth it?

The options increase executable size by 5-10% and proportionally contribute to general sluggishness of applications. I don't know if there is a benchmark to measure that. And yes, I can, and have gone into all my projects and added -fno-stack-protector and -no-pie; but why did you impose this extra work on me?

The main issue here is your gall to think you know better than I how my projects should be compiled and the conceit to unilaterally force this opinion on all of us as a system-wide policy in an underhanded and tedious to reverse manner. If you want to change global policy, put these flags into the default makepkg.conf where those of us who do know better what we want can remove them.

> Searching the mailing lists will turn up plenty of testing.

> As for proof that the options increase security, if you had any idea at all of what those options did, you wouldn't be asking that question.

Assertion is not a proof. The burden of proof lies on those, who proposed to add pie and ssp in the first place.

Yes, tests were performed: https://github.com/pid1/test-sec-flags/wiki

You can find info about this at Archlinux frontpage:https://www.archlinux.org/news/test-sec-flags-call-for-assistance

Nobody impose any extra work for anyone. If you want binaries you have to accept the way they're build. That's the deal. Otherwise you're free to fetch sources. AFAIK most if not all major distros are build this way so you're demanding that Arch should deviate from modern standards.

Adjusting global flags instead isn't the same as not all packages respect them during build and Arch had to hack it by using hardenig-wrapper tool (but it was rarely used anyway).

BTW: when you open an issue the burden of proof lies on you and only you not everyone else.

Explicit clarification: I am asking for these security flags to be moved to the default makepkg.conf, where global policy belongs, instead of being enforced by gcc. This way Arch gets its dubiously "hardened" binaries, while those of us who compile our own can remove the flags and restore sanity. A win-win situation, as I see it.