Re: [gentoo-dev] Regarding the State of PaX in the tree

[Ulrich Mueller]

>>>>> On Mon, 16 Apr 2018, Michał Górny wrote:

> W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik
> Anthony G. Basile napisał:
>> The question then is, do we remove all this code? As thing stands,
>> its just lint that serves no current purpose, so removing it would
>> clean things up. The disadvantage is it would be a pita to ever
>> restore it if we ever wanted it back. While upstream doesn't
>> provide their patch for free, some users/companies can purchase the
>> grsecurity patches and still use a custom hardened-sources kernel
>> with Gentoo. But since we haven't been able to test the pax
>> markings/custom patches in about a year, its hard to say how useful
>> that code might still be.

For Emacs, hardened support was quite a headache in the past, due to
its unexec mechanism; see bugs 285778, 411439, 426394, 456970, 497498,
515122, 529172, their duplicates, and the upstream bugs linked from
them. We cannot safely assume that any new (hardened kernel, or Emacs)
version will work out of the box. Therefore, I am inclined to either
remove the pax_kernel flag from my ebuilds, or to package.use.mask it
at least, in order to make clear that this is no longer a supported
configuration.

> One thing Hardened project should do is make a clear statement to
> other developers -- i.e. indicate whether I should CC hardened@ when
> someone has PaX problems and doesn't provide a patch, or just close
> the bug saying that we can't solve it without a patch.

I would even go one step further and tell people to sort things out
with upstream. First, because I cannot reasonably upstream patches for
an unsupported configuration that I cannot test. Second, since they
have purchased the grsecurity patches, they should also ask grsecurity
for support. Why should I as an unpaid volunteer spend my time on it?

Ulrich