On 2013-05-23 09:40, Russ Allbery wrote: > Niels Thykier <ni...@thykier.net> writes: > >> Assuming you were using 2.5.11 for test, you may want to retry with >> 2.5.12. The latter did another false-positive -> false-negative >> trade-off (memset and memmove). > > Looks like that won't help for libkopenafs1: > > % hardening-check --verbose /usr/lib/libkopenafs.so.1 > [...] > > That's the one built with hardening-wrappers installed. > > Also looks like that's not the issue for xml-security-c-utils: > > % hardening-check --verbose xmlsec-xklient > [...] >
Indeed. Sadly there is nothing on the Lintian side (or in hardening-check) that allows us to get any more information to improve the accuracy (without doing something drastic like decompiling the binary and analysing that - but even then). To be honest, I have been considering if we should reduce and disable this tag like we did with the stack-protector tag. In terms of accuracy, blhc beats hardening-check/lintian by miles. Even if people/upstreams tend to mistake C{,XX}FLAGS vs. CPPFLAGS, I suspect we would be better off by disabling this tag (e.g. less frustation from our users). The tag would still be available via the debian/extra-hardening profile, so people can opt-in. NB: I would still keep hardening-no-relro, which has very few false-positives to my knowledge (most overridden tags appear to be non-free packages, so probably caused by the binaries not being re-buildable). > (Thanks for the note about --verbose!) > You are welcome. :) It happens to be the way we implement the fp->fn trade-offs. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org