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. Cheers, Balint [1] https://lists.debian.org/debian-devel/2016/05/msg00228.html [2] https://lists.debian.org/debian-devel/2016/08/msg00324.html
Dear Guillem, On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey <balint@balintreczey.hu> wrote: ... 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. Cheers, Balint [3] https://wiki.debian.org/Hardening/PIEByDefaultTransition [4] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906&users=balint%40balintreczey.hu;dist=unstable [5] https://wiki.debian.org/qa.debian.org/ArchiveTesting
Hi Guillem, For the record gcc-6/6.2.0-7 enabled bindnow for the architectures where PIE is enabled by default. I think enabling bindnow from dpkg would be better through the hardening flags because packages could disable it in a nicer and already established way. Cheers, Balint 2016-10-10 14:06 GMT+02:00 Balint Reczey <balint@balintreczey.hu>:
Hi! Hmm, I don't get why bindnow was enabled by default in gcc, while relro (I'd assume) is not enabled by default, or is that enabled by default now too? IMO either relro + bindnow should be enabled in gcc, or neither should. I'm fine either way, but I find having a hardened compiler is actually good, because it gives also hardened output for non-packaged builds! Thanks, Guillem
Hi, 2016-10-26 5:00 GMT+02:00 Guillem Jover <guillem@debian.org>: Default relro is enabled only on Ubuntu among other flags. Enabling bindnow was Matthias' change and we did not discuss it in advance. http://sources.debian.net/src/gcc-6/6.2.0-9/debian/rules.patch/#L134 I'm OK either way. IMO those can be enabled even for non-PIE arches BTW. In the original patches I wanted to follow Debian's practice of setting flags from dpkg, but there are pros and cons on each side. Setting relro + bindnow in GCC probably results less FTBS-s in packages where flags are not passed properly, while it makes harder to disable the flags from d/rules. I would like to see bindnow enabled in Stretch and the first phase of the freeze is near. Could you two (Matthias and Guillem) please find the variant which would please both of you? Cheers, Balint
Hi, 2016-10-26 13:46 GMT+02:00 Bálint Réczey <balint@balintreczey.hu>: For the record Matthias reverted setting bindnow in gcc-6/6.2.0-10, thus it seems dpkg can set both. Cheers, Balint
Hi Guillem, 2016-10-27 23:49 GMT+02:00 Bálint Réczey <balint@balintreczey.hu>: I saw you synced dpkg with GCC's default PIE settings in 1.18.11, thank you for that. Is there any particular reason for not enabling bindnow as well? Do you plan enabling it for Stretch? Cheers, Balint
Hi All, 2016-11-06 13:20 GMT+01:00 Bálint Réczey <balint@balintreczey.hu>: I have uploaded a fixed package with the attached patch to DELAYED/10. Cheers, Balint
that enables bindnow on any architecture whether pie is enabled or not. is this intended? Matthias
Hi Matthias, 2016-12-14 15:09 GMT+01:00 Matthias Klose <doko@debian.org>: Yes, relro is enabled by default on all architectures, too. Cheers, Balint
* Bálint Réczey <balint@balintreczey.hu> [161219 00:06]: Given dpkg/1.18.16 has entered sid, your upload will likely fail... Best,
2016-12-19 1:07 GMT+01:00 Christian Hofstaedtler <zeha@debian.org>: Yes, Guillem mentioned it in his email to debian-devel: https://lists.debian.org/debian-devel/2016/12/msg00416.html Cheers, Balint
Hi all, PIE made it into Strech. But bindnow is still open even after it was activated for a short time (and packages were build with it). May I ask for the planning for Buster? Thanks in advance! Dr. Markus Waldeck
Hi, For the record I'm not working on this anymore. Feel free to either close the bug or pick the work up from here. IMO there is not much to worry about enabling bindnow since Ubuntu enabled it in 16.10. Cheers, Balint [1] https://wiki.ubuntu.com/ToolChain%20/CompilerFlags/#A-Wl.2C-z.2Cnow Dr. Markus Waldeck <waldeck@gmx.de> ezt írta (időpont: 2017. aug. 17., Cs, 16:31):
With LTO being considered to be enabled by default [1] can this please also get another deliberation. [1]: https://lists.debian.org/debian-devel/2022/06/msg00092.html
Hi! If you want to see this enabled by default, please bring it up again on debian-devel. AFAIR last time there was push back. Thanks, Guillem
Hi. subscribers to
#835146 "dpkg: please enable bindow hardening flag by default"
This mail chain arises from some QA work in src:its-playback-time
about the recommendation in the wiki to set
DEB_BUILD_MAINT_OPTIONS=hardening=+all
Andreas, thanks for the reply. I appreciate your points.
This one I think could do with some more followup:
Andreas Tille writes ("Re: Bug#969093: Patch: Newer upstream version of its-playback-time"):
Well, I dropped that change, so now the rules file is doing nothing
special, and the blhc pipeline job passes.
question.
Wiki pages are far from authoritative and very easily get out of date,
especially if they are not monitored and maintained. In any case,
whowever put that on the wiki page may have been misguided.
And, I wouldn't blindly adopt suggestions from linters and QA tools.
They can have false positives, and/or make suggestions which are
inappropriate in context. (And sometimes I even disagree with a lint
in principle, although that doesn't seem to be the case here.)
My starting point is that our tooling should do the right thing by
default when used in the usual way. And that something ought
generally to be done a particular way, we should achieve that by
changing tooling defaults. The overrride options like
DEB_BUILD_MAINT_OPTIONS are there for situations where we need to
diverge from the usual behaviour.
That's certainly the philosophy in dh. And in this case it seems that
this text has remained unchanged since that text was added in February
2012, 14 years ago. I can find little rationale even then.
I did find this
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489771#154
where it seems the decision not to turn on pie (for example) was
apparently taken deliberately. Looking through the changelog and bug
list for src:dpkg I do see new hardening flags being added to the
default set. So the defaultse are being maintained.
Eventually, I found this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146
where it seems that the merits of enabling bindnow are disputed?
And this extensive thread from 2016:
https://lists.debian.org/debian-devel/2016/11/msg00808.html
It would be great if someone who understands the underlying situation
would edit the wiki page to at least add some of these references.
Ideally we'd either revise the advice there or add a rationale
explaining why we're recommending that everyone should be setting
non-default options.
Thanks, all.
Ian.