Control: reassign 837368 hardening-includes Hi Simon,
Thanks a lot for your explantion below. I am forwarding this bug to package hardening-includes, which provides hardening-check. To hardening-includes maintainers: Simon is the upstream of the blhc. Regards, Eriberto 2016-09-10 21:48 GMT-03:00 Simon Ruderich <si...@ruderich.org>: > On Sat, Sep 10, 2016 at 09:15:43PM -0300, Joao Eriberto Mota Filho wrote: >> Hi, >> >> When building my package magicrescue in Sid, lintian says: >> >> I: magicrescue: hardening-no-fortify-functions >> usr/lib/magicrescue/tools/safecat >> >> Using hardening-check, I can see: >> >> # hardening-check >> /tmp/magicrescue-1.1.9/debian/magicrescue/usr/lib/magicrescue/tools/safecat >> Position Independent Executable: yes >> Stack protected: yes >> Fortify Source functions: no, only unprotected functions found! >> Read-only relocations: yes >> Immediate binding: yes >> >> However, blhc --all says nothing. It is a false positive from hardening check >> or a blhc bug? > > Hello, > > TL;DR everything is fine. No bug in neither blhc nor > hardening-check and all hardening flags are applied. > > After looking at the build logs this is a false positive in > hardening-check (that's impossible to fix for now). > > -D_FORTIFY_SOURCE=2 is passed to all gcc calls in the build log > therefore blhc reports no errors. However hardening-check can > only look at the resulting binary. Now it looks like magicrescue > doesn't use any of the protected functions generated by > -D_FORTIFY_SOURCE=2 as gcc has converted all calls to the unsafe > version because it can prove that the arguments can't overflow. > hardening-check interprets this as possible missing hardening > flags and warns. As hardening-check has no access to the build > log it can't do any better. > > Regards > Simon > -- > + privacy is necessary > + using gnupg http://gnupg.org > + public key id: 0x92FEFDB7E44C32F9
