Bug#709415: lintian: false positive for hardening-no-fortify-functions

[Niels Thykier <niels@thykier.net>]

On 2013-05-23 09:40, Russ Allbery wrote:
> Niels Thykier <niels@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