Hi Guillem, 2016-12-17 3:14 GMT+01:00 Guillem Jover <guil...@debian.org>: > On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote: >> 2016-12-13 9:29 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>: >> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>: >> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guil...@debian.org>: >> >>> 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. > > But you didn't do the requested archive-wide autopkgtest run (because > "it was hard"), and even though the coverage is not great it would > be better than nothing. Requested in this case because bindnow changes > the *run-time* behavior, which is not visible or noticable in normal > circumstances by just *building* packages.
I'm surprised you raise the autopkgtest run question. Have you missed my email about this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12 2016-10-10 14:06 GMT+02:00 Balint Reczey <bal...@balintreczey.hu>: > Dear Guillem, > > On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey <bal...@balintreczey.hu> > wrote: > ... >> Dear Guillem, >> >> As a continuation of the discussions [1][2] on debian-devel I'm >> attaching the simple patch that implements enabling the bindnow >> hardening flags. >> >> I'm continuing with the rebuild/autopkgtest tests according to >> the Dpkg FAQ, hence the moreinfo tag. > > The rebuild (with PIE and bindnow enabled) resulted ~1000 FTBFS > cases from which all seem to be related to enabling PIE by > default [3]. > > ~70 of the filed related bugs [4] are still open. > > Since the rebuild was run with tests enabled this seems to be a > good indication that we can expect very few breakages from > enabling bindnow by default. > > Running autopkgtest would need more work as AFAIK there is no > automated method for doing it like rebuilds [5]. > > I'm wondering if you find the autopkgtest round necessary for > this change. You never answered, but I thought you read the whole bug history. I asked for clarification then because the on 13 Aug you added the following line to dpkg FAQ which does not seem to be a strong requirement: * For flags that change run-time semantics, ideally an additional run of the autopkgtest for packages that ship them (although this cannot be deemed conclusive as our coverage is not great yet). ( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=28&rev2=29 ) I would say it would have been really nice to provide a feedback about your position two months ago because I could set up something to run the aforementioned autopkgtest run in addition to the archive wide rebuild which included all build-time tests, but you can still add your answer to the bug report. > >> >> 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? > > I've not seen any reply from the release team, no. And as explicitly > mentioned before multiple times now, this has the potential to impact > the release by introducing subtle and possibly hard to spot errors at > *run-time*, which might be triggered by simple a upload or a binNMU w/o > the maintainer being in the loop and knowing they have enabled bindnow. > So I want the release team to be involved in ACKing this potentially > release breaking change. I would like to kindly ask the Release Team to share its position on the bindnow question since Guillem don't seem to let this move forward without that. Thanks, Balint > > I guess this is "The current PIE situation is already an unholy mess" > (which I'll cover in another mail), so let's make the mess bigger > approach to releasing the distribution… > >> > 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. > > … seriously I'm not sure why I bothered with this thread really? And > this makes no sense whatsover. The currently uploaded dpkg 1.18.16 does > *not* contain the change, and neither will subsequent uploads, as long > as the conditions stated in my initial mail on this thread are not met, > I'm not going to merge this change for Stretch. > >> >>> 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. > > Whatever, > Guillem
