Passing the Baton

> Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed?

Misinformed, or just using installer tools that have a slot for an EULA, so they just stick whatever license applies to the software even if it is expressly not intended to be a use license in without thought.

Brad has already answered this before.[1] In short: they have no interest in cooperating with an upstream that feel -- in many ways -- does not appreciate their work[2], and their view of their work is that it is a complete system and greater than the sum of individual parts, which upstreaming can't solve on its own.

Also, just picking out hundreds of bug fixes isn't really improving kernel security, in reality. It feels good, but it solves very little. It's playing cat-and-mouse, whack-a-mole. You churn 1.5 million lines of code every 3 months, every major release of Linux, add tons of new code, and play the game again. This approach is simply not sustainable in the long run. You also have to have actual mitigation and defense techniques too -- and not just one of them. You need a lot of them, working together.

In short, it's not just about a set of patches, or just fixing some infoleaks.. The entire development process needs to take part in this.

[1] https://unix.stackexchange.com/questions/59020/why-are-the-g...

[2] While I cannot find a link on me, I actually 'fondly' remember a recent memory somewhere from LKML, where someone (an ARM maintainer, I believe) actively lashed out at Kees Cook for "bothering" to do this work and attempting to upstream some of their work such as PAX_REFCOUNT. The reasoning? Because it's "bullshit" to worry about losers who do not upstream, and making their lives "easier" is a load of crap they shouldn't bother with, and it only benefits people "who do not contribute back". At one point they even started ranting about how people like Samsung similarly just 'take' and do not give back. It took several emails to explain, patiently, that in this scenario, it is not about making anyone's life easier, nor benefitting shitty people like Samsung -- it is about protecting users. And it's about having mitigations that will stop exploits today that don't get discovered until 5 years from now when millions of people are vulnerable with exposed devices. This isn't a simple disagreement about how a patch should be implemented -- it is a complete misunderstanding of defense in depth, and true mitigation.

But the backporting-security-patches thing is already done by every distro—just, not as well as grsec+pax do it. Said distro maintainers just need help to get their -stable kernels up to grsec/pax's standard—at which point the grsec/pax patchsets could be based directly on top of each distro's -stable kernel package, rather than having to do all the work of backporting again themselves.

Which would, of course, free up resources on the grsec/pax side to go toward protecting users; and, moreover, would also partially protect those users who just rely on their distro's -stable kernel, more than they're being protected today.

Perfect is the enemy of good; ideal security is the enemy of less vulnerable.

i don't quite get what you're arguing now... are you stating that when there're functional dependencies between components, we should somehow ignore them when incorporating them into a larger piece? say, the kernel should get a NIC driver before it got a network stack at all? if you're not arguing that then i don't see why different rules should apply to the security features we have...

as for your satire, it's just got one thing wrong, but that kinda kills the rest of it: we never said "take it if you want it" and thus we never embarked on the rest of that journey.

> as for invasiveness, you're only stating the obvious that there're more and less complex pieces of code yet both kinds (well, all kinds in the complexity spectrum really) can make it into the kernel. that is, this argument cannot be used against incorporating grsec on its own.

You asked for a definition, not an argument. Definitions are supposed to be obvious. Not every line of a reply has to be a rebuttal, just because one part is. :)

> which means the reverse process would reproduce these 'testable components'

The reverse process of how you built up the system (by committing changes), would break the the patchset down into commits. Commits might be patches, but they're sure not components.

A commit can change a line in the middle of a function in the middle of a random file anywhere in the kernel. A component is its own file/module/function that can be independently tested and verified and, most importantly, judged for how well the design-choices in its implementation solve the user-story they purport to solve, compared to other possible implementations.

A random one-line commit can certainly implement functionality—or can fix a bug—but it can't (usually) introduce a user-visible feature on its own. A series of one-line commits can, together, introduce a user-visible feature; but if they do, they need to be merged together into a single patch so that the design they implement can be seen, in order to be evaluated.

If you have take your codebase and just export all the commits as patches, each one might—as it probably originally did—just add one or two lines to the body of some function. But if all the commits necessary for a given feature end up combining into one big, monolithic blob of a patch—or end up extending several functions in the kernel into being large, monolithic functions—then the design of the feature is probably bad, and the patch will therefore probably be rejected.

What the kernel maintainers expect, in such a case, is for you to take your features and refactor them into independent subfeatures, such that each "patch that implements the feature" is fairly small. They expect you to do the same thing to your patchset that is done in a web-app when it is refactored into microservices: to make each component small enough, and non-interdependent-enough, that an argument over the design of the patch can involve each invested party writing their own version to demonstrate their idea; and where each component can be easily ripped out and replaced with one of the alternate designs, without affecting any of the other components.

For a good case of this already happening, look at OpenVZ. OpenVZ was a big, monolithic patch, that was never going to get upstreamed. It was refactored into the individual components of cgroups, the CPU freezer, memory quotas, and the addition of a number of namespace hierarchies. All of these components "add up to" something roughly equivalent to OpenVZ, but they're not OpenVZ. (In fact, they're effectively Docker; upstreaming them basically killed OpenVZ!)