Hello folks, I'm looking at this feature: https://fedoraproject.org/wiki/Changes/Harden_All_Packages <quote> How To Test Running checksec should always report only Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH otherwise a tracking bug should exist for the respective packages </quote> On a current Rawhide installation I'm seeing lots of potential failures, for example: Partial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Question is how to deal with these because they appear to be in the hundreds ?

I will do my best to filter out any false negatives and group the results per package but this still leaves quite a big number of bugs to report. How do you feel about reporting all of these offences automatically ? Are there any known exceptions which should be mentioned in the wiki page above ?

>> >> Question is how to deal with these because they appear to be in the hundreds ? > > How many, exactly? We have around 20000 SRPMs in the distribution.

On 09/16/2015 10:24 AM, Alexander Todorov wrote: > From today's Rawhide snapshot my script counted around 4500 offending > packages. You can find links to the script and execution log here: > http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/ > > > Please let me know which packages need to genuinely be excluded and what > should we do with these packages ? Some will probably be fixed once they are > rebuilt but that may take a while. > > Any package maintainers out there - please fix your packages in Rawhide so we > don't have to file bugs for all of them. I think we may have an issue with libtool throwing away the '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' option: /bin/sh ../libtool --tag=CC --mode=link gcc -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -O -fomit-frame-pointer -finline-functions -O2 -g -pipe -Wall -Werror=format-s ecurity -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -version-info 10:1 :0 -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libhdf5.la -rpath /usr/lib64 H5.lo.... H5Ztrans.lo -lz -ldl -lm libtool: link: gcc -shared -fPIC -DPIC .libs/H5.o ... .libs/H5Ztrans.o -lz -ldl -lm -O -O2 -g -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -Wl,-z -Wl,relro -Wl,-soname -Wl,libhdf5.so.10 -o .libs/libhdf5.so.10.0.1

>>>> "AT" == Alexander Todorov <atodorov(a)redhat.com&gt; writes:

Including fedora-devel on this topic. На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа: >>> >>>Question is how to deal with these because they appear to be in the hundreds ? >> >>How many, exactly? We have around 20000 SRPMs in the distribution. > From today's Rawhide snapshot my script counted around 4500 offending packages. You can find links to the script and execution log here: http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/

>>>>> "AT" == Alexander Todorov <atodorov(a)redhat.com&gt; writes: AT> How do you feel about reporting all of these offences AT> automatically? Please don't. Post lists and let people work on things and develop a base of information before going and clogging bugzilla. Only end up at bugzilla after the easy things have been fixed and you have some documentation written to which you can link in the tickets you file. At this point if you filed tickets against most packages, people would have no idea at all what to do with them and many would either be ignored or simply closed. I know Kevin had a document about this but now that I need it I can't find a link.