На 16.09.2015 в 23:05, Kaleb S. KEITHLEY написа:
On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote:
"AT" == Alexander Todorov <atodo...@redhat.com> writes:
AT> offending packages. You can find links to the script and execution
AT> log here:
AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
BTW to see if any packages you own are on the list, you can do:
wget
https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log
for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$"
checksec.log|uniq; done
GlusterFS packages have seven "No canary found" [1]. I get the same
results with gcc-5.1.1 on f22.
However GlusterFS _is_ built with '%global _hardened_build 1' and I have
confirmed that all its sources are compiled with -fstack-protector-strong.
As I read the gcc man page for -fstack-protector,
-fstack-protector-strong, and -fstack-protector-all, it's clear that
with just -fstack-protector-strong it's entirely plausible that these
DSOs would not have the call to __stack_chk_fail, i.e. the canary.
If I compile them with -fstack-protector-all then the resulting .o and
.so files _do_ have the call to __stack_chk_fail.
Off hand I'd say that checksec's test for the canary is wanting.
The glusterfs packages need to be excluded. Or change _hardened_build to
use -fstack-protector-all.
Hi Kaleb,
thanks for pointing this out.
Can somebody comment on the -fstack-protector-all vs -fstack-protector-strong
issue ? Do we want to change the default for %__global_cflags in
/usr/lib/rpm/redhat/macros ?
--
Alex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
