Re: [RFC PATCH] dpkg-buildflags: Switch to -fstack-protector-strong
On Thu, Jun 26, 2014 at 7:57 AM, Romain Francoise wrote:
> Hi,
>
> On Wed, Jun 25, 2014 at 07:29:09PM -0400, Michael Gilbert wrote:
>> Especially when some of them already export either CC=gcc-4.8 or
>> CXX=g++-4.8 in debian/rules (like chromium, oxref, and spek), which
>> would make it rather convenient to detect the compiler in use.
>
> I've already touched upon this elsewhere in this thread, but my personal
> feeling is that we don't want to go down that road. Detecting which
> compiler is used and parsing/comparing version numbers is bound to be
> fragile and require a lot of maintenance over time.
Version comparison is something computers do incredibly well and
incredibly reliably all the time, so it isn't obvious why it would
suddenly fall apart here. dpkg-buildflags is in perl, but thinking
about it in shell for simplicity, the implementation would be as
simple as
flags=$others
if [ gcc_major = 4 -a gcc_minor < 9 ]; then
flags += -fstack-protector
else
flags += -fstack-protector-strong
fi
>> Other packages in that set don't do that but patches could be proposed
>> for those packages so they don't have this problem in the future.
>
> If we have to touch any packages we might as well do the flag
> substitution directly.
That's a temporary fix for this particular flag change, not a
permanent fix that will be handled automatically in the future.
>> Plus, there will be future situations like this, and if this is
>> already implemented, a bunch of similar problems will be avoided. So
>> in general, it's just good hygiene.
>
> If these hypothetical future problems can be worked around just by
> comparing version numbers, which is far from being a given...
The chance is almost nil that gcc will add new flags without also
incrementing part of the version.
> I don't think that breaking 15 packages out of 10938 is a big deal, we
> can patch those and move along. The rest of the archive will benefit
> from stronger security.
The benefit is going to happen either way, this way just requires a
little more work upfront. It will save you at least 8 nmus right
away.
It would also be nice to start thinking about adding
-fsanitize=undefined to the default buildflags, which is also
introduced in 4.9.
Best wishes,
Mike
Reply to: