Hi! On Thu, 2016-11-24 at 14:52:33 +0000, Thorsten Glaser wrote: > clone 845193 -1 > reassign -1 dpkg > retitle -1 dpkg: please do not add -specs= flags only on some architectures > thanks
I'm afraid I'll have to wontfix this because it is not really implementable. See below… :/ > Guillem Jover dixit: > >Those specs files should make it possible to build stuff with PIE > > Yes, but they *do* break anything that > - acts on the CFLAGS (and LDFLAGS) variables > - uses klcc or other compiler wrappers that don't understand -specs > - uses clang or pcc or whatever other compilers The default dpkg build flags have always been tied to the specific language compiler version currently marked as the default (for C that would currently be gcc-6). > Worse, they break *differently* on whether… > > >Precisely to make the behavior consistent on all architectures, dpkg > >enables PIE (conditionally if no other flags marks it as to be > >disabled) on all architectures were gcc has not enabled this by > >default. > > … that. And that is just plain wrong. Either dpkg should inject > -specs= stuff on all architectures or on none. Differing like this > just invites hidden and hard to track down bugs. As long as gcc enables PIE on a subset, there will be need to inject some form of specs on either subset of those arches, either on hardening=+pie or on hardening=-pie, pick yout poison. :( Injecting just the raw -fno-PIE and -no-pie does not work, so when you need to disable those we need to pass via specs files. > Please get an agreement with the GCC maintainer on how to proceed > from here. > > Personally, I’d still prefer for GCC to behave as on other systems, > i.e. not to enable PIE by default, and to have it done completely > within dpkg, but I can *also* live with it being done exclusively > in GCC. > > Either are *much* better than the current way. Well you and me both, I'm just adapting the dpkg-buildflags to the current gcc situation. :/ > >Also BTW the gcc maintainer asked that porters > >interested could request PIE to be enabled by default in gcc. > > What difference does it make on whether GCC or dpkg enables PIE? It means it should at least get the same behavior from gcc as all official ports, it is more transparent and should not suffer from unbalanced passing of CFLAGS w/o LDFLAGS or the other way around, for example. Of course that does not mean that package might still not fail, in case they try to link PIE code into a shared library or similar. > The two last quote sections make it clear that any architecture > that currently has PIE enabled in dpkg should have it enabled in > GCC in the first place. Enabling new build flags in dpkg has always been done globally, except for specific blacklists on things that were completely broken in the toolchain, which have then been enabled eventually when they got fixed. Having a subset of architectures is a pain for maintainers as they get different resulting objects depending on the architectures, it also changes the semantics from before the gcc default change, as previously explicitly enabling PIE was global, and now would be for a subset. Or worse, the new semantics would need to be that by default you get PIE on a subset but if you pass hardening=+pie on each package you get it enabled globally? Pretty unintuitive IMO. > (Did dpkg enable that on porters’ requests? > It does not look like that to me. This smells like overstepping > boundaries.) If porters are unhappy about this, I'll revert PIE for those ports in dpkg, but this will not make the situation less of a mess, hardening=-pie will still need the specs files on ports were gcc enables it by default, and hardening=+pie might need them on the ones that do not… > tl;dr: I don’t care as much _which_ of GCC xor dpkg does it, > as long as only one does it. FFS, just enable it on all of them > unless known to absolutely not work; that’d still be better than > the current mess. Well I think we should be enabling all hardening flags directly in gcc, but now that we have the specs files I guess it would not be too bad to enable them just in dpkg, but I agree either would be preferable. :/ Thanks, Guillem
