Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
Hi Guillem,
2016-12-19 1:34 GMT+01:00 Guillem Jover <guillem@debian.org>:
> On Sat, 2016-12-17 at 09:20:40 +0100, Bálint Réczey wrote:
>> 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>:
>> >> >> 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.
>
> I mentioned it explicitly on a private mail Lucas sent to me, Niels and
> Kurt, which prompted me to update the dpkg FAQ, and then again a week
> after in <https://lists.debian.org/debian-devel/2016/08/msg00384.html>.
>
> In addition on that private conversation I also mentioned this:
>
> And this still leaves many packages that might fail at run-time (not
> to mention the startup slow down), so this option seems potentially
> dangerous to enable globally. OTOH at least both Gentoo and Fedora
> seem to have done so:
>
> <https://wiki.gentoo.org/wiki/Hardened/Toolchain>
> <https://fedoraproject.org/wiki/Changes/Harden_All_Packages>
>
> And some known issues:
>
> <http://www.zsh.org/mla/workers/2015/msg02981.html>
> <https://bugzilla.redhat.com/show_bug.cgi?id=1199775>
> The Gentoo wiki also mentions that X is not happy about this, but
> I'm not sure how current that is.
>
> Which then updated <https://wiki.debian.org/Hardening> with some of
> those relevant links, but maybe that was too subtle.
Note that you did not list autopkgtest as a strong requirement:
https://lists.debian.org/debian-devel/2016/08/msg00384.html
...
From dpkg PoV enabling both, would at least require a full-archive
rebuild, for bindnow ideally also a full autopkgtest run (as the
updated dpkg FAQ states now, after Lucas Nussbaum approached me some
weeks ago mentioning he was willing to do such archive-wide rebuild).
...
Note the word "ideally".
Those emails were the exact reasons why I asked a proper clarification on
10 October to be able to at least give autopkgtest a try in time:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12
>
>> 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 )
>
> It certainly is not going to be conclusive as a way to verify it correct,
> as even with no failures would not mean there's no potential problems;
> this would merely apply the principle of "falsificationism" to the
> proposal. So it might be helpful as an additional data point to try to
> gauge the possible fallout, but not as a way to say "everything ok, no
> problems found". Which I guess does not play in your favor, I'll
> update the FAQ to makes this more clear.
I agree with that.
>
>> 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.
>
> BTW, in contrast to PIE, to be able to use bindnow globally on your
> system you don't even have to recompile anything. You can simply add
> LD_BIND_NOW=1 in your /etc/environment for example (man ld.so(8)).
It may work for a some systems but this would also set bindnow for
programs not working properly with bindnow in contrast to enabling bindnow
in dpkg globally and disabling it per problematic package.
>
> Also according to the release schedule, it appears to me people still
> have up to 10 days before 2017-02-05 to enable bindnow in their
> packages?
True, I have updated my blog post with that later date. Thanks for
pointing that out.
>
> And in any case, I've written down to propose enabling this at the
> beginning of the dpkg 1.19.x release cycle (which will match the buster
> release cycle) in <https://wiki.debian.org/Teams/Dpkg/RoadMap>.
Thanks. If I could perform the autopkgtest run with bindnow this year would it
be convincing enough given only a small amount of breakages to enable
bindnow early in January?
Thanks,
Balint
>
> Regards,
> Guillem
Reply to: