Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey <balint@balintreczey.hu>]

Hi All,

2016-12-13 9:29 GMT+01:00 Bálint Réczey <balint@balintreczey.hu>:
> Hi Guillem,
>
> 2016-11-27 23:11 GMT+01:00 Bálint Réczey <balint@balintreczey.hu>:
>> Hi Guillem,
>>
>> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guillem@debian.org>:
>>> Hi!
>>>
>>> This was discussed relatively recently, but it was not entirely clear
>>> to me what was the conclusion, if there was any(?), about enabling
>>> bindnow by default.
>>>
>>> And although this got enabled by default in gcc-6 6.2.0-7 when PIE
>>> also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
>>> out that enabling bindnow in gcc w/o enabling relro too didn't seem to
>>> make much sense, but then I didn't notice any rationale for the
>>> reversion, instead of say enabling relro too.
>>
>> GCC enabled bindnow only for architectures which also enabled
>> PIE by default, but unlike PIE there were no architecture-specific
>> objections against enabling bindnow.
>>
>> I think talking to Matthias (@Matthias: talking to Guillem) and
>> reaching a consensus would be badly needed for the project.
>>
>>>
>>>
>>> My mine concern is and has always been that bindnow changes the
>>> run-time behavior (instead of the build-time one) and could break
>>> things such as dlopen() on shared libraries or plugins and similar.
>>> And detecting problems becomes harder, and reverting this change
>>> iff we notice that it breaks too much might imply rebuilding an
>>> unspecified number of packages. So in a way it feels kind of like
>>> a transition?
>>>
>>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
>>> default in gcc for a long time, but also relro, stack-protector and
>>> fortify. Which would seem to imply this might not break that much?
>>> (I'm not sure why we are not enabling all those in gcc in Debian
>>> too, but that's probably a different conversation to have if at all.)
>>
>> Lucas already performed the archive-wide rebuild with bindnow
>> enabled by dpkg and we have not observed breakages specific to
>> bindnow. IMO this is mostly due to packages already disabling
>> bindnow through dpkg-buildflags.
>>
>> Considering that we are already in the transition freeze I suggest
>> going with enabling bindnow for all architectures in dpkg and
>> for Stretch+1 the responsibility of setting some hardening flags
>> could be transferred to gcc.
>> IMO this is not a transition because the change does not affect
>> package interdependencies.
>
> Is there any update on this?
>
> We are running out of time...

I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10
according to current NMU rules. If the Release Team increases the
severity of #835146 it can reach unstable earlier.

Cheers,
Balint

>>>
>>> So at this point, I guess I still have concerns, but only very mild
>>> ones, and would not mind one way or another, but would like input
>>> from at least the release team, because I don't feel like possibly
>>> deciding on this on my own, even more at this stage of the release.
>>>
>>> Thanks,
>>> Guillem