2016-12-15 23:26 GMT+01:00 Matthias Klose <d...@debian.org>: > On 15.12.2016 13:27, Guillem Jover wrote: >> Hi! >> >> On Wed, 2016-12-14 at 12:54:41 +0100, Matthias Klose wrote: >>> Package: dpkg-dev >>> Version: 1.18.15 >>> Severity: important >>> Tags: sid stretch >>> >>> This is seen on all architectures where pie is not enabled by default. These >>> specs should not be passed when pie is not in effect. >> >> I assume you mean enabled by default by gcc. > > No, this particular build log doesn't show any -fPIE/-pie flags, so it is > neither enabled by dpkg-buildflags nor by gcc. > >>> Seen only when looking at the python2.7 ftbfs on x32. And verified that >>> the python2.7 build succeeds again when the specs are not passed. >> >> If python2.7 does not build with the PIE spec files on x32 that means >> that either there's a portability issue on x32 in python2.7, or that >> there's a more fundamental problem with x32 and PIE (f.ex. openssl1.0 >> also only fails on x32 with PIE specs, see #845193, although openssl >> builds fine there). >> >> If the latter, I'd be fine with blacklisting PIE on x32 as "not yet >> working", so that it cannot be enabled at all from the dpkg side. >> (It also might well be that these packages would fail anyway in case >> gcc enabled PIE by default on x32.) Otherwise I guess I'll merge this >> and the other report and probably either reassign to gcc or close. >> >> >> The rationale for ending up enabling this globally in dpkg, was that >> enabling this partially in gcc means handling this in packaging is an >> inconsistent mess. >> >> We'd have some packages building with PIE in some architectures and >> not on others (default hardening build flags option), packages building >> with PIE enabled everywhere using gcc default or dpkg PIE enabling specs >> (with hardening=+pie), or PIE disabled everywhere using PIE disabling >> specs or nothing where gcc does not enable it. >> >> So we'd need specs files in some places no matter what. And the option >> of just never using specs files, and not making it possible to disable >> PIE for example or enable it on other arches explicily would be >> inconsistent and a pain for maintainers.
Porters could opt-in for PIE and architectures not opted-in are left out. Please don't enable PIE for architectures not opted-in because those are the architectures with typically fewer users and less manpower to fix issues. I would love to see PIE enabled for all arches, but this needs more work than the available manpower. > > Well, Balint asked to enable the pie defaults in GCC. I wasn't aware that more > work regarding the specs was needed. Ideally these changes should be done in > one place, not in two. Yes, I tested and asked for enabling PIE in GCC because this is the low risk method. It is used by Ubuntu and GCC parameter parsing makes enabling it from dpkg basically does not work. Setting it through spec files is fragile and it is not tested well. Please simply drop using spec files for both setting and disabling PIE. You may be able to figure out a good solution with full archive rebuilds for Stretch+1, but there is no time for that now. The solution of enabling PIE for a subset of arches through GCC and not enabling it for the rest of the arches has Release Team's blessing thus please don't divert from that. > >> We've also never enabled hardening flags partially, all hardening >> flags are always enabled as long as they work, otherwise they are just >> globally blacklisted on certain arches, even if the packages requests >> them. > > The pie flags are the first ones which have a performance impact, and probably > were never tested on our non-linux targets. So yes, I'm careful to apply these > on each target. Please live with it that defaults may differ. > > I don't think that dpkg-buildflags should have any business passing spec files > for cases where these spec files are not needed. This is monkey-patching GCC > for unrelated or convenience reasons. This did go wrong as seen with #843791, > #843826, and now with at least the python2.7 x32 build. For the latter it is > not important that the build can/should be fixed or being worked around, but > that just passing these specs is causing side effects. The GCC packages don't > divert dpkg-buildflags either, and I see this in the end as a diversion as > well. > And I can't find any docs about what these specs are supposed to do. > > For the upload of the GCC 6.3.0 release candidate I'm ignoring these spec > files > when they are not needed. I think this is the least invasive option for the > upcoming stretch release. A 'note' message is printed when these options are > ignored, so this shouldn't be an issue with any -Werror option either. > >> I find the current situation pretty suboptimal TBH. :/ > > Balint and the release team asked to enable this. I raised concerns that this > would be too late for the release cycle, but my concerns were ignored (sorry, > can't find this email in a bug report, must be on some ML). I'm fine to undo > the pie enabling for stretch and work on a better solution for buster if > anybody > requests this. There are plenty of bug reports where people are not happy > with > the pie defaults in GCC. The concerns were reasonable, we were late, but not too late. They were listened to and acknowledged that this change involved risks and needed work but both the risks and the amount of work involved were acceptable. IMO the Release Team made the right call here. Please don't revert the GCC changes, the reversion would delay Stretch more and frankly Stretch without PIE is not a release I would recommend to anyone. If dpkg stops passing spec files we are basically done with the PIE changes. Upstreams already need to live with GCC-s with PIE enabled by default due to Ubuntu's 16.10 thus maintainers following new upstream releases will be covered, the rest is being helped out. > > Ideally I'd like to see a solution where no spec file changes are required and > the the appropriate changes are integrated in GCC upstream. Me too. I asked GCC upstream to make PIE easy to disable but it does not seem to happen: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464 Cheers, Balint
