>>>>> 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
pgp0RHuAa3UKg.pgp
Description: PGP signature
