Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
Hi Guillem,
2016-12-17 3:14 GMT+01:00 Guillem Jover <guillem@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 <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.
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 <balint@balintreczey.hu>:
> Dear Guillem,
>
> On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey <balint@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
Reply to: