[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#796562: lintian: Please identify lack of sanitation compiler/linker flags



Hi,

Jakub Wilk wrote (22 Aug 2015 17:32:52 GMT) :
> Could you clarify what exactly you want Lintian to check for?

The scope of my request was: possibly all checks that
`DEB_BUILD_MAINT_OPTIONS = sanitize=+all' enables. Possibly only some.
That's up for discussion. I personally lack the expertise to evaluate
the different options we have here (hence keeping Jacob Cc'd).

> I you meant to say that you think that all packages should be built
> with -fsanitize=address, and Lintian should complain about binaries that weren't
> compiled that way, then I disagree. On the contrary, I think we shouldn't ship
> binaries built with with ASAN enabled, except maybe in special cases, for a variety
> of reasons: [...]

Thanks for sharing! A couple of these shortcomings were unknown to me
(I'm not a low-level / C person myself). Most of them seem to be
definitely worth it for specific programs, e.g. those whose security
track record is bad, and that are known of being regularly used as
attack vectors in the wild. I guess these were maybe part of the
"special cases" you are referring to.

With all this info in mind, I'm not arguing in favour of treating the
lack of sanitation options as an error than one must "fix" in every
package.

However, I believe that Lintian could have an educational role here:
I suspect that lots of maintainers of security-sensitive packages are
not aware that dpkg-dev (>= 1.17.14) now provides this easy way to
build their package with these options, and thus have perhaps never
tried it; if, additionally, upstream has never done that either, then
we may have situations in which only potential attackers have
discovered a bunch of security issues... thanks to tools that we ship
in Debian, but don't use ourselves.

So, the current state of my thoughts is:  Lintian could encourage
package maintainers to try these sanitation options out *locally*
first, report bugs upstream if needed, and to actively and consciously
decide if their package is worth compiling+linking this way in the
archive, with all the drawbacks you mentioned in mind. And if they
decide that these options are no good for their package, then they can
man this explicit by adding a Lintian override. This would make me
feel more comfortable wrt. "lacking" these compilation/linking options
in packages: I could trust their maintainers to having made the best
decision they could, rather than being in the position I'm currently
in, that is: wondering if they ever have considered this option
at all.

In the end, it feels like that finding an agreement could mostly be
a matter of phrasing, and of carefully picking the best Lintian
severity for these checks. What do you think?

Now, perhaps this is out of the scope of Lintian's mission, as
perceived by its maintainers. If that would be the case, then let me
know, and I'm happy to think about other ways to handle this in
Debian, in coordination with other people who are already working on
this topic.

Cheers,
-- 
intrigeri


Reply to: