Date: Thu, 4 May 2017 06:47:08 +0000 (UTC) From: Lionel Debroux <lionel_debroux@...oo.fr> To: Kees Cook <keescook@...omium.org>, Shawn <citypw@...il.com> Cc: Rik van Riel <riel@...hat.com>, Mathias Krause <minipli@...glemail.com>, Daniel Cegiełka <daniel.cegielka@...il.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: It looks like there will be no more public versions of PaX and Grsec. Hi, (I hope that silly webmail is not going to butcher my e-mail's layout, this time...) > It'd be nice if I could convince you otherwise (see my reply to > Mathias), but upstream hasn't "created more work" for grsecurity. > [...] > (since again, upstreaming doesn't increase their work) Uh, do you really mean that ? Because on the contrary, it's a (real) _fact_ that upstreaming something directly taken from, or inspired by, the PaX/grsecurity work _does_ increase their work, through at least three well-identified mechanisms: * adjusting their work to match upstream's changes. That's relatively simple if the changes are pure renames, but as we know, upstream changes are not always (not often, even, they'd probably say) that simple - and do not always come without drawbacks on complexity or protective abilities, either. spender has been posting (complaining) multiple times about that, giving specific examples - which you may have seen by yourself. * helping upstream perform the integration in the first place. They had to spend much time helping the mainlining process of some bits. See it indirectly in spender's posts questioning mainline's ability to perform _sustained_ maintenance of the integrated features (even if they received some minor fixes on some GCC plugins in return for the integration, as you mentioned). Don't let spender's usual writing style (not necessarily more abrasive than Linus', BTW) shadow the technical reasons behind his complaints, some are arguably valid. * unapplying, one by one, the hunks mentioned earlier for improvements related to (mostly) CONSTIFY, RANDSTRUCT, RAP. They've been carrying these patches for years, with very little maintenance: the vast majority of these hunks didn't change from one upstream version to the next one. We've already discussed at length the non-technical reasons why nobody picked them up. To tell the truth, the fact that upstreaming said changes does, as a matter of fact, increase their work load was the second, auxiliary reason why, after several patches in 2010 and 2012, I didn't spend more of my free time mainlining some of these small, scattered changes, rather than on other endeavours. I find myself caring quite a bit less about that second reason now that the patches have become private, but the main reason of the dishearteningly expensive mainlining process largely remains valid... I do understand the need for reviews in general, but CONSTIFY or RANDSTRUCT-related hunks are arguably special. > And even if you still believe that, making their patches private > doesn't reduce the amount of work they have to do. It just forces > people to pay them. Yes, that is true. Arguably, in some ways, since making their patches private increases the incentive to mainline hunks thereof, it _increases_ their work over some areas in the short and mid-term. Bye, Lionel.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.