On 3/11/19 11:48 PM, Florian Weimer wrote: > * Ben Cotton: > >> '''-Wformat -Wformat-security -fstack-protector-strong >> --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O''''' > > --param=ssp-buffer-size=4 will not affect anything because > -fstack-protector-strong uses a completely different heuristic. > >> == Benefit to Fedora == >> We provide better security both for our packages and for >> applications/programs which users are building. > > We can check using annocheck if there are packages missing hardening and > fix them. What's the current level of coverage we have? > The intention is to have a secure compiler defaults. I have not taken a survey of what is the current coverage, but that is not really the goal here. Also having secure defaults help with user applications and not only fedora packages. > Have the Red Hat Enterprise Linux 8 packaging changes been upstreamed? > We were aiming for nearly-complete coverage there. > Not sure about this, but again this is not the aim. >> == Scope == >> * Proposal owners: Patch gcc to enable these options by default. Patch >> should be very simple, since the compile/link code isnt actually >> touched. > > -D_FORTIFY_SOURCE=2 by default needs patching of glibc because of the > pesky warning it prints without optimization. What is the amount of work this requires? Can we aim this for F31? Also these are warnings and not errors i assume? > > What about PIE by defauld and non-lazy binding by default? These two > are probably the two hardest to get right with CFLAGS/LDFLAGS injection. > (PIE is the reason for the -specs= hack.) > I am aiming this for F32, The intention is to add small number of secure defaults to GCC for each release. I am open to add PIE by default though, if you feel its not going to break large number of packages. > PIE-by-default compilers are very common already, although there are > many StackOverflow questions from peopel who use them and follow older > training material. > > Thanks, > Florian > -- Huzaifa Sidhpurwala / Red Hat Product Security Team _______________________________________________ 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
