Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:09 UTC (Wed) by ms-tg (subscriber, #89231)
In reply to: Increasingly hard to see how Brad Spengler is/was in the wrong by riel
Parent article: Ripples from Stack Clash

Yes, but...

Isn't the "missing part", that they are making patch sets that end up acceptable for upstream approval, but not necessarily approved by PaX as being complete and fully understanding the problem, and accounting for every detail that is changed from the original solution and why that doesn't violate any assumptions about the threat model?

In other words, isn't the problem that there's no formal role assigned here for PaX itself? And wouldn't they be willing to play that role if
(a) they were paid for it, probably by Red Hat
(b) they're job was to approve the interpretation of the patches, or clearly explain what was still not right
(c) they were clearly credited for originating the understanding of the vulnerability and/or hardening solution?

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:15 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

That sounds like the most likely outcome of that would be zero progress. grsecurity has a commercial interest in *not* getting this stuff into core. Several people associated with grsec have a communication style clearly aimed at not resulting in actual cooperation. They don't approve of working on things incrementally. Why would it be a good idea to give them veto powers - and that's pretty much what you're suggesting.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:27 UTC (Wed) by pizza (subscriber, #46) [Link]

> Isn't the "missing part", that they are making patch sets that end up acceptable for upstream approval, but not necessarily approved by PaX as being complete and fully understanding the problem [...]

You're missing a crucial point -- In many ways, there are fundamental conflicts between the needs of upstream and the needs of a hardened patchset. Implications include API changes, performance regressions, maintainability, and so forth. I'm not saying that either side is inherently _wrong_; just that there are legitimate areas of disagreement that could easily result in incomplete bits being mainlined.

Another thing that the core kernel maintainers have repeatedly (and IMO correctly) prioritized is a maintainer's ability to play well with others. None of them exist in a vacuum.