On Wed, Mar 20, 2019 at 09:52:02AM +0530, Huzaifa Sidhpurwala wrote: > On 3/15/19 9:49 PM, Richard W.M. Jones wrote: > > On Fri, Mar 15, 2019 at 04:15:58PM +0000, Richard W.M. Jones wrote: > >> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/HardenedCompiler > >> > >> I'm not opposing this, but is it possible we could do this without > >> breaking clang at the same time? > >> > >> In the past (and currently) the Fedora compiler flags need some hairy > >> editing so they work with clang, eg: > >> > >> https://src.fedoraproject.org/rpms/american-fuzzy-lop/blob/master/f/american-fuzzy-lop.spec#_110 > >> > >> (Actually this is not the latest iteration - latest clang 7 and gcc 9 > >> and Fedora 30+ needs even more editing, but I didn't push it yet since > >> there are other issues with this package.) > >> > >> It would be nice if there was a way we could avoid this. > > > > So after rereading the proposal more carefully it seems as if the > > proposal is to change the defaults in GCC so no flags would need to be > > specified. Would we consequently remove those flags from the command > > line (which would solve my problem above)? > > The flags in my proposal will be removed from the command line during > the Fedora build process, since they are now default. Only people who > dont want to use these flags due to some reason will need to unset them > (I am assuming there are not a lot of packages like that) > > Currently based on Jakub's suggestion i am also planning to remove to > fortify_source flag and keep others. > > The plan is to start some where and each release work with glibc and > other teams so that we make more such security flags as default and also > work with packages which break due to inclusion of such flags. ^^^^^^^^ The original proposal had: -Wformat -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O IIUC, the proposal now would be: -Wformat -Wformat-security -fstack-protector-strong -O As was stated multiple times in this thread, this change does not apply to *packages* which follow the packaging guidelines, because various flags are already set in %{optflags}. This change would only affect mispackaged packages and locally compiled programs. The effect of "-Wformat -Wformat-security" without -Werror is only more warnings. Unfortunately -Wformat will generate spurious warnings if the code is not careful to give additional information to the compiler with __attribute__((__format__(printf))) and friends. And even that sometimes not enough, and explicit #pragma GCC diagnostic ignored "-Wformat-nonliteral" is needed. So all in all, it is totally expected that code which is not written with recent gcc in mind will generate spurious format warnings, even if the code is completely OK. So turning this on will make builds more noisy, and possibly break projects which use -Werror. The effect of "-O" is not nice, because it's often useful to compile without any optimization whatsoever for debugging, so that the binary code corresponds as closely as possible to the source. I'm sure people will not know that '-O' has been made the default and will be confused. "-fstack-protector-strong" is the only one that has a clearly beneficial effect. But then there's the overall counterargument from Jakub that we start deviating from upstream defaults and some users will need to add counter-options to go back to the compiler defaults. I feel like the possible benefits from enabling "-fstack-protector-strong" are not big enough to justify the change. For serious hardening, one would enable way more flags, and just turning on one or two is enough for the downsides to kick in, but not enough to have serious benefits. I think that instead of playing with compiler defaults like this, it would be more productive to investigate *packaged* software and to check if it really follows the packaging guidelines and is hardened effectively. With annobin enabled, it should be possible to do this programatically. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
