1 |
On Sun, Apr 15, 2018 at 08:04:43PM -0400, Anthony G. Basile wrote: |
2 |
> The question then is, do we remove all this code? As thing stands, its |
3 |
> just lint that serves no current purpose, so removing it would clean |
4 |
> things up. The disadvantage is it would be a pita to ever restore it if |
5 |
> we ever wanted it back. While upstream doesn't provide their patch for |
6 |
> free, some users/companies can purchase the grsecurity patches and still |
7 |
> use a custom hardened-sources kernel with Gentoo. But since we haven't |
8 |
> been able to test the pax markings/custom patches in about a year, its |
9 |
> hard to say how useful that code might still be. |
10 |
|
11 |
Aside from potential breakage of pax-enabled systems due to lack of |
12 |
(ability to perform) testing, is there any burden to keeping it? |
13 |
|
14 |
Unless there's specific benefit to be had by removing the code, I'd be |
15 |
inclined to keep it in-place to facilitate Gentoo users who do subscribe |
16 |
to GRSecurity and use their patchset, granted with the disclaimer that |
17 |
we can't test. Removing the machinery to support it would just drive |
18 |
users to different platforms. |
19 |
|
20 |
Alternatively, perhaps someone from GRSec could help maintain it, since |
21 |
they would obviously be in a position to actually test. Though, I'm not |
22 |
sure how viable it is to have someone maintaining functionality to |
23 |
support a patchset that the majority of us cannot access... |
24 |
|
25 |
-- |
26 |
Sam Jorna (wraeth) |
27 |
GnuPG Key: D6180C26 |