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

[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...

Cheers,
Balint

>
> 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