Hi! On Mon, 2017-02-27 at 22:45:24 +0000, Thorsten Glaser wrote: > Guillem Jover dixit: > > This is wrong in so many levels, as we'll have discrepancies between > > architectures, the interface towards maintainers is inconsistent, and > > updating the PIE support needs touching and coordinating two places. But > > Not quite: it *only* needs changing in GCC now that dpkg keeps its > hands off the default PIE setting.
Nope, because as long as gcc still uses a very restricted whitelist of arches where to enable PIE by default, dpkg still needs to adapt to pass or not the PIE flags, on those arches. :( > > it's certainly the current lesser evil. > > That, yes. It additionally is the better way to do this because the > -specs= stuff was inherently broken (consider compiler wrappers for > other libcs which do their own specs stuff) and otherwise fragile, > while the “PIE is enabled by default in GCC” mechanism is used by > all architectures now and better understood (and having some arch > not defaulting to PIE is a safe (even if less “secure”) failure mode. I'm not sure I follow. The specs stuff is libc independent, gcc uses internally builtin specs to drive the frontends. specs files are also necessary to be able to disable PIE even on packages that build both programs and libraries, otherwise we get FTBFS (and it's the reason the specs files got introduced in the first place). Also, as stated above, nope PIE is still not enabled globally in gcc, and worse the very broken gcc patch overriding the dpkg build flags might or might not disable these depending on how the variables are exported… On Wed, 2017-03-01 at 13:20:19 +0000, Thorsten Glaser wrote: > Dixi quod… > >Thank you for this change — now I can probably remove all the > >special CFLAGS handling from my packages again… > > Unfortunately, this is NOT enough! > > If some package declares hardening=+all then dpkg will STILL > inject the -specs= stuff into various flags, breaking e.g. > gpgme1.0 (or anything else using Qt) in the process (because > it must be built with PIC, not PIE). Using hardening=+all,-pie > works around this but ⓐ needs maintainer interferences and ⓑ > is another architecture inconsistency. If we were not using specs files, and passing straight -fPIE -pie, or even -fno-PIE -no-pie the fallout would be greater, as the spec files try to make sure not to use PIE when PIC, static or shared linking has been specified. So maintainers would need to do way more manual intervention then. Why do you state that the specs file are completely broken? How many arches are affected? After the initial fallout, I've only seen x32 being broken here, and as I stated on the openssl bug, it seems the cause is generally somewhere else. > Guillem, _please_, the only way out of this mess is to never > inject the -specs=* stuff at all, See above. Replacing specs with straight flags would be way worse, and would regress release arches, which I'm not planning on doing at this point in the release cycle. Removing them completely means we cannot enable/disable PIE at all, which would seem obvious is unacceptable? > or (probably opening up a > new mess) to always inject it on all architectures (then you’d > see just how broken it is). As stated above, I'm not going to introduce changes at this point in the release cycle which affects release architectures. The biggest issue here is still the broken handling of PIE within gcc, by using a whitelist… > Sometimes, it’s better to use a more pragmatic solution instead > of a more “correct” one. Here the specs files is actually the pragmatic solution! Using straight flags breaks stuff. The correct solution would be to actually just enable PIE globally in gcc and make dpkg never pass specs nor flags to enable them. > (Also, why is this even affecting x32… > I thought Doko enabled PIE on all architectures now?) Both because PIE is *not* enabled globally, and because x32 seems to have some issues IMO, either in the toolchain or in specific packages, etc. If you want your arch to get out of this mess, file a bug against gcc to get it to enable PIE by default. It still sucks, because it has to be requested per-arch, and then coordinated with dpkg, but at this point, that's really the best you can do. :( Thanks, Guillem
