Hi Guillem, 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>: > 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.
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
