Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
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.
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
Reply to: