Hi Guillem, 2016-11-23 2:30 GMT+01:00 Guillem Jover <guil...@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
