Bug#709415: lintian: false positive for hardening-no-fortify-functions
On 2013-05-23 10:09, Russ Allbery wrote:
> Niels Thykier <niels@thykier.net> writes:
>
>> 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.
>
> I'm at least seeing a lot of false positives for a tag that's marked
> possible. We could drop it to wild-guess, which IIRC would make it
> info-level instead of a warning, which feels about right for the level of
> false positive vs. false negative tradeoff we have at the moment.
>
Granted, I have demoted the certainty accordingly.
>>> (Thanks for the note about --verbose!)
>
>> You are welcome. :) It happens to be the way we implement the fp->fn
>> trade-offs.
>
> It would be neat to include the list of unprotected functions as
> additional data for the tag.
>
In the tag description or the tag "extra"? For the former, the problem
might be that the list is (or could be) architecture dependent. For the
latter, it would need some changes to hardening-info{,-helper} +
c/binaries. But also some consideration to handle 5+ unprotected
functions. Example even the following is getting rather lengthy
... hardening-no-fortity-functions path/to/file func1, func2, func3, ...
~Niels
Reply to: