Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
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 <balint@balintreczey.hu>:
> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey <balint@balintreczey.hu>:
> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guillem@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.
> >> 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 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
Reply to: