[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] The PIE unholy mess

Would prefer that all dpks would load when extracted, or be sent to a save file, like gzip. But I am only a beginner in coding.

Daniel T. Hasbrouck
On Jan 17, 2017 8:38 PM, "Guillem Jover" <guillem@debian.org> wrote:
> Hi!
> I'd like to get some feedback from porters and package maintainers,
> given that this affects at least both groups. Some background first.
> One of the reasons PIE has in the past not been enabled by default in
> dpkg-buildflags, is because it introduced some slowness on some arches,
> although this has somewhat changed recently. But also because
> unconditionally setting it, breaks at least PIC builds. So PIE got
> enabled recently by default in gcc, as it could easily control when it
> is relevant. Although this has been done only for release architectures.
> At about the same time this was being considered, I realized that dpkg
> could enable this "safely" by using gcc specs files. But this is in
> any case also required to be able to disable PIE when it is implicitly
> enabled by default in gcc. So we'll need specs files no matter what,
> at least for now.
> While adapting dpkg-buildflags to cover for the new gcc defaults, I
> unintentionally enabled PIE by default on all architectures, and when
> I noticed, it seemed to make sense to leave it like that, because:
>   * All previous build flags from dpkg-buildflags have always been
>     enabled globally and only blacklisted completely when they have
>     been non-functional.
>   * It's a more consistent interface for packages, as they get built
>     with the same flags everywhere. Otherwise we'd get PIE enabled by
>     default in release arches, disabled by default elsewhere, and
>     enabled or disabled depending on the package requesting so.
>   * It will mean that PIE coverage reporting will be shadowed in
>     lintian, because the tags only cover i386 and amd64, so maintainers
>     will probably stop enabling them globally.
> Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
> requesting to not enable PIE globally from dpkg-buildflags, and pretty
> much immediately added a patch into gcc [P] to ignore dpkg-buildflags
> not enable PIE explicitly (I only fully understood the request after
> seeing the gcc patch).
>   [P] <https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-6/debian/patches/ignore-pie-specs-when-not-enabled.diff?revision=9202&view=markup>
> Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
> does not even need to be exported from debian/rules, nor from the
> dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
> --export=configure or --export=cmdline. It's also a layer violation.
> It also breaks unrelated stuff as now gcc emits notes when it thinks
> the -specs option should not be passed. And while I could certainly
> have started an arms-race by adding counter-measures by randomizing
> the filenames or something similarly ugly, that'd be pretty much silly
> and childish.
> For better or worse, this does not affect the release architectures,
> so by extension it should not affect the release, but it still sucks.
> So, I'd like to know how people feel about the requested interface
> (i.e. not enabling PIE globally from dpkg-buildflags). If there's
> consensus that porters and maintainers want that, I'll just change
> dpkg-buildflags to do this, even though I think it's a very
> suboptiomal behavior.
> Alternatively, porters could as well request PIE be enabled by default
> in gcc on their port, which could make this also globally enabled.
> Thanks,
> Guillem

Reply to: