Hi All, 2016-12-13 9:29 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>: > 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...
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
