| 1 |
Hi! |
| 2 |
|
| 3 |
On Tue, May 02, 2017 at 09:58:18PM +0200, Daniel Cegiełka wrote: |
| 4 |
> This means that any future solution will not be compatible with current |
| 5 |
> PaX support. |
| 6 |
|
| 7 |
It doesn't means that. That may happens, or not - if someone will bother |
| 8 |
about compatibility, for example. |
| 9 |
|
| 10 |
I also think it makes sense to keep paxmarking in ebuilds, for now. |
| 11 |
If not for technical reasons, then just to avoid adding more damage. |
| 12 |
GrSec/PaX is not going anywhere, at least not immediately, there are a lot |
| 13 |
of systems which still use hardened-sources and may continue using current |
| 14 |
versions for long enough time - and they'll need that paxmarking for |
| 15 |
current and new versions of ebuilds. Plus there is a non-zero chance next |
| 16 |
solution will replace GrSec/PaX in more or less compatible way. And thus |
| 17 |
until it became clear next solution doesn't require similar paxmarking at |
| 18 |
same places or supporting paxmarking in existing ebuilds will require any |
| 19 |
noticeable effort - there is no good reason to destroy something what just |
| 20 |
works now. |
| 21 |
|
| 22 |
> Again: years of work and PaX support ends in the trash. |
| 23 |
|
| 24 |
Yeah, we already know you feel it this way. Any reason to repeat this |
| 25 |
again and again? How this will improve anything? |
| 26 |
|
| 27 |
-- |
| 28 |
WBR, Alex. |
Archives