Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
Guillem Jover dixit: >> 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). Sure, but we do have other compilers and compiler wrappers in the archive, and packages are using them. >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. :( […] >> 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. :/ This sounds to me like we should reassign this to GCC (and remove all the… well, “offending”, no offence intended, code from dpkg). >Having a subset of architectures is a pain for maintainers as they True, so GCC should just enable it on all architectures where it at all works. >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. :/ OK, thank you. bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
Hi! On Thu, 2016-11-24 at 14:52:33 +, 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
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
clone 845193 -1 reassign -1 dpkg retitle -1 dpkg: please do not add -specs= flags only on some architectures thanks Guillem Jover dixit: >> I cannot build openssl1.0 any longer. Downgrading all binary >> packages from src:dpkg to 1.18.10 makes the build succeed. Interestingly enough, src:openssl (1.1) works, so… >So, I think I'll reassign this to openssl1.0, if no other feedback … this is probably legit. But I would *still* like to raise another point. >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 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. 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. >if no other feedback is provided showing that this is a problem in >dpkg itself, such as PIE not working at all there, and a request to >disable it for x32 in dpkg as non-functional. This can be done just as well on the GCC side. >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? 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. (Did dpkg enable that on porters’ requests? It does not look like that to me. This smells like overstepping boundaries.) 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. Thanks, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
