Grsecurity goes private
The grsecurity patch set is intended to harden the kernel against a wide range of potential attacks. Its mitigations range from simple techniques like making important data structures read-only to relatively advanced defenses like RAP. Over the years, the developers involved have certainly broken new ground and come up with some novel solutions; as a result, these patches are appreciated by a fair community of users — a community that has lost free access to this work in the future.
Grsecurity and the mainline
These patches have not, as a whole, found their way into the mainline kernel, for a number of reasons. One is the simple fact that the kernel development community historically has not fully appreciated the need for kernel hardening. There was an increasingly unwarranted level of confidence in the kernel's inherent security and a lack of desire to face the trade-offs that often come with hardening patches. As a result, Linux fell behind the state of the art in this area, and external patches like grsecurity were the best way to increase the kernel's resistance to attacks.
Over the last couple of years or so, there has been a shift in the kernel community that has made it more open to hardening work; the ongoing efforts of the grsecurity developers certainly deserve some credit for this change. As a result, a number of technologies, most inspired by the grsecurity work, have made their way into the mainline, though the code has often changed significantly (or been entirely rewritten) along the way. Current kernels have address-space layout randomization, post-init read-only memory, hardened user-space access routines, GCC plugins for the build process, reference-count hardening, virtually mapped kernel stacks, and more. There have been numerous complaints and snide comments, especially from the grsecurity camp (example), on how these features have been implemented, and it may well be that many of them are not as strong as one would like. But they represent progress nonetheless.
Why not just merge the grsecurity patches outright? Because that is not how the kernel community works. Changes to the kernel are split into small, reviewable changes, (sometimes) documented, and each is debated on its own merits. The grsecurity patches are not split in this manner and, in many cases, they do not meet the kernel community's standards in their current form. Like it or not, there are trade-offs to be made with any patch, including security patches, and those trade-offs, which may include performance and long-term maintainability issues, must be discussed.
Security patches tend to be discussed more fiercely than others, partly because some kernel developers see a relatively small advantage to them for a relatively large cost. The value of kernel hardening is more apparent to some than to others. But security is not unique in this way; getting invasive changes of just about any type into the core kernel is never an easy task. The grsecurity developers have had little interest in doing the work to get their patches into the mainline; the same is true of the bulk of those who use the grsecurity patch set.
Nothing obligates any of these people to put in that effort, but the implication is that this work will fall to others who are interested in seeing these patches upstreamed. Finding developers willing to take that task on and deal with the ensuing discussions has not always been an easy task, but the pace of upstreaming has increased in recent years anyway. Much of this work has been done under the aegis of the Kernel Self-Protection Project (KSPP), an informal group of whom founder Kees Cook is the most visible member.
Why grsecurity went away
The withdrawal of the public grsecurity patch set has led to a certain amount of finger pointing and recrimination, with many blaming KSPP or just about anybody except the grsecurity developers themselves for the change. Consider, for example, this statement from a group that calls itself "HardenedLinux" (or "h4rdenedzer0"):
Or this post from Mathias Krause:
Both claims are somewhat difficult to back up.
The Linux Foundation does not control kernel development and does not run KSPP. What the Linux Foundation has done is to fund, via the Core Infrastructure Initiative, some of the work to bring grsecurity features into the mainline. Paying for work on free software, intended to improve the security of the Linux kernel, does not seem like a particularly blameworthy activity, so it's not entirely clear why the Linux Foundation is being faulted here. There is talk of too many press releases; these do exist, including one issued on May 4, but it seems strange to expect that the Linux Foundation should not highlight the work it is doing.
The claim that KSPP is somehow making life harder for grsecurity is also hard to justify. Those developers need not participate in this upstreaming work, and they need not accept the results of that work if they prefer their own patches. They do have to keep up with the pace of kernel development in general if they want the work that the rest of the community has been doing, but KSPP has not created that issue — that is a well-known cost of maintaining an out-of-tree patch set. The upstreaming work has also brought benefits to grsecurity, demonstrated by the fact that grsecurity has incorporated that work into its own patch set, as outlined in detail by Cook.
Much of the discussion seems based on the notion that the kernel community somehow owes something to the grsecurity developers for their work. That viewpoint overlooks something important: the entire reason Open Source Security Inc. is in business in the first place is that it gets an entire kernel, for free, that is actively maintained and extended by about 4,000 developers every year. It is a huge gift for a group of developers who, say, want to create a security consulting company. They can never repay the value of that gift; indeed, even the largest contributors to the kernel get more from it than they put in. That is why they are contributors in the first place.
In a sense, all users of the kernel owe a debt to everybody who has contributed over the years. And every one of us who has contributed has made a gift to all Linux users. The value of the grsecurity patches is significant, but it pales in respect to the value of the kernel as a whole. Grsecurity is not special in relation to the vast body of other contributions on which it is built.
So public access to grsecurity was not withdrawn due to workload, and it was not withdrawn because its developers have been somehow cheated by the development community. There is a much more likely explanation here: the movement of hardening features into the mainline kernel poses challenges to the developers' business model, which depends on providing security features not found there. Closing off access is meant to slow that movement and preserve the differentiation of the grsecurity patch set. This decision is within their right to make, as long as they stay within the terms of the GPL (and there have been no serious claims that they have done otherwise), but it should be seen as what it is: a business move intended to keep their work proprietary in spirit.
The existing patch set will continue to exist, of course, and it may well
be that some suitably motivated developers will work to keep it updated
with future kernel releases. Meanwhile, the work to bring more security
features into the mainline kernel will continue. The kernel will get more
secure over time, even without the minimal involvement of the grsecurity
developers. Hopefully they will be successful in their business and will
draw some satisfaction that, through the process of upstreaming, their
older work will eventually improve the security of hundreds of millions of
kernel users.
| Index entries for this article | |
|---|---|
| Kernel | Security/Security technologies |
| Security | Linux kernel |
Posted May 5, 2017 9:12 UTC (Fri)
by dany (guest, #18902)
[Link] (18 responses)
Posted May 5, 2017 9:29 UTC (Fri)
by tlamp (subscriber, #108540)
[Link] (16 responses)
But yeah I get what you mean.
I have to say, while not heavily involved with Kernel dev and security, I get a worse and worse picture by them and PaX.
Kees Cooks reply to the opinion that KSSP is to blame for this is really worth a read:
I have no understanding for people blaming anyone else than the grsecurity Team itself for closing their source.
I wish them their luck and hope that they do well. I also hope that their talent may help the whole Linux Community someday again, as the Linux Community's talent does now help them.
Posted May 5, 2017 17:49 UTC (Fri)
by faramir (subscriber, #2327)
[Link] (15 responses)
Would that be anything like the mockery and arrogance that
Posted May 5, 2017 19:52 UTC (Fri)
by MatejLach (guest, #84942)
[Link] (14 responses)
Just wanted to point out that the 'mockery and arrogance' relates to code that if shipped in the kernel you're running right now, would likely result in having a bad time. It is mostly tolerated because we all want a quality kernel and are most of us are glad that somebody is watching over it to ensure that and secondly, it is tolerated because Linus attacks code, not people.
Posted May 6, 2017 2:59 UTC (Sat)
by roc (subscriber, #30627)
[Link] (13 responses)
That applies to almost any significant project.
> it is tolerated because Linus attacks code, not people.
A number of examples to the contrary are included here:
I think the real reason his behavior is tolerated is because Linux is a very successful project and Linus is perceived (probably correctly) as being essential to it. Just like the legendary assholism of Jobs, Gates, Ballmer and Ellison was tolerated because they ran very successful companies.
We'll never know whether Linux would have been more or less successful if Linus was less prone to abusive language, but I think he sets a poor example.
Posted May 6, 2017 7:23 UTC (Sat)
by niner (subscriber, #26151)
[Link] (5 responses)
The examples that actually were about people were:
So far it does indeed sound like Linux attacks people. But if you follow the links in the article and read up on the details, the picture changes.
What about David Howells?
The original quote about comment syntax is: "Can we please get rid of the brain-damaged stupid networking comment syntax style, PLEASE?". So the style is brain damaged. No word about people.
The only instance where he actually was talking about a person is the quote about Kay Sievers. By now this looks much more like the exception than the rule.
All that said, I would hopefully use a different way to communicate if I were in Linus' place. But since I am not I cannot be sure.The swearing, the language, aggressiveness, they are usually a sign of desperation. I'm sure you know how it is to sense that something is just correct or very very wrong, the "this solution is so beautiful, it drives me to tears" or the "oh this is wrong on so many levels, it makes me cringe". When you develop software long enough, your gut feeling becomes much quicker than your reasoning. So you know something's terribly wrong on a glance, but to get other people to see this, via email nonetheless, can be most difficult and frustrating and an unlimited source for desperation. So even if I do not condone Linus' behavior, I can certainly understand it.
Now to get back on topic, I wonder if the same could be said about Open Source Inc.
Posted May 6, 2017 17:06 UTC (Sat)
by drag (guest, #31333)
[Link]
Posted May 8, 2017 20:31 UTC (Mon)
by roc (subscriber, #30627)
[Link] (2 responses)
Furthermore, people don't always carefully parse profane attacks to distinguish whether those attacks are against them or something they said, in order to make a rational decision as to offended to be.
Here's a fact: in the great majority of workplaces, schools, families and even in LWN comments, Linus-style discourse would be completely unacceptable.
> When you develop software long enough, your gut feeling becomes much quicker than your reasoning. So you know something's terribly wrong on a glance, but to get other people to see this, via email nonetheless, can be most difficult and frustrating and an unlimited source for desperation.
Sure, I have tons of experience with this myself. But gatekeepers in other projects, and even the majority of Linux kernel gatekeepers, are able to overcome these issues without Linus-style diatribes.
Posted May 18, 2017 15:41 UTC (Thu)
by Zolko (guest, #99166)
[Link] (1 responses)
Posted May 19, 2017 2:41 UTC (Fri)
by bronson (subscriber, #4806)
[Link]
Posted May 11, 2017 11:15 UTC (Thu)
by dag- (guest, #30207)
[Link]
Thanks for that :-)
Posted May 6, 2017 8:29 UTC (Sat)
by flussence (guest, #85566)
[Link] (6 responses)
I personally would prefer getting a Linus-style “this code you wrote is f**king awful, _and here's why_” response any day, to what I've seen members of large software projects engage in all too often: derailing any conversation they feel at threat of “losing” into a war of attrition through obsequiousness and nitpicking. That's puerile office politics, and for FOSS most people on the receiving end of it aren't being paid by the hour to work at the office in question.
Posted May 6, 2017 12:16 UTC (Sat)
by jrigg (guest, #30848)
[Link] (4 responses)
Same here. I think it's interesting that Linux has been around for over 20 years, but it's only relatively recently that people have started commenting on this. It feeds into the seemingly fashionable habit of taking someone's comment out of context and twisting it to make it sound more personally directed than it actually is (either for humorous effect, as in the Register, or because the person doing it derives some satisfaction from being offended).
Posted May 6, 2017 12:25 UTC (Sat)
by liw (subscriber, #6379)
[Link] (3 responses)
I contributed code to the Linux kernel in 1991, before the first release. The code is still there, with some modifications. Soon after I decided I didn't want to be involved with the kernel at a code level because I didn't like being roasted by Linus. It's not a recent phenomenon.
Posted May 6, 2017 12:34 UTC (Sat)
by jrigg (guest, #30848)
[Link] (2 responses)
Posted May 7, 2017 14:07 UTC (Sun)
by jond (subscriber, #37669)
[Link] (1 responses)
Posted May 8, 2017 10:44 UTC (Mon)
by jrigg (guest, #30848)
[Link]
Posted May 8, 2017 20:36 UTC (Mon)
by roc (subscriber, #30627)
[Link]
> I personally would prefer getting a Linus-style “this code you wrote is f**king awful, _and here's why_” response any day, to what I've seen members of large software projects engage in all too often: derailing any conversation they feel at threat of “losing” into a war of attrition through obsequiousness and nitpicking.
Those aren't the only two choices; this is a false dichotomy.
Posted May 15, 2017 15:19 UTC (Mon)
by ortalo (guest, #4654)
[Link]
Posted May 5, 2017 10:22 UTC (Fri)
by armijn (subscriber, #3653)
[Link] (3 responses)
Posted May 6, 2017 3:57 UTC (Sat)
by citypw (guest, #82661)
[Link] (2 responses)
http://openwall.com/lists/kernel-hardening/2017/05/04/10
http://openwall.com/lists/kernel-hardening/2017/05/04/20
The fact is fact. No one can denied.
Posted May 6, 2017 7:34 UTC (Sat)
by niner (subscriber, #26151)
[Link] (1 responses)
The Linux kernel, as mentioned in this very article, is what PaX and Grsecurity are based on and where those pull thousands of patches from with every rebase. And those patches include a lot of work done and paid for by Intel. And that's what those big corps contribute to PaX/Grsecurity.
Posted May 18, 2017 17:16 UTC (Thu)
by tuna (guest, #44480)
[Link]
Posted May 5, 2017 13:35 UTC (Fri)
by SLi (subscriber, #53131)
[Link] (32 responses)
1. Previously there has been a gigantic patch released for each supported upstream kernel version, publicly available on the grsecurity site.
Right?
But it's fairly clear they may distribute the patch either under GPLv2 or not at all, so what prevents one of those paying customers from posting the patch publicly? Or do they somehow rely on the customers' unwillingness to do so?
Posted May 5, 2017 13:41 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (29 responses)
Posted May 5, 2017 15:14 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (26 responses)
Posted May 5, 2017 15:59 UTC (Fri)
by tlamp (subscriber, #108540)
[Link] (21 responses)
Just write a mini code processor which changes whitespaces in indentation here and there, use different variable names, use different code structure add some hidden unicode symbols, ...
An Leaker could naturally scramble it too, but the chance that he misses something is still there.
Also a third party leakage could be compromised, how do you verify that? `Open Source Security Inc.` may not help you there.
A bit joking but also a bit serious with this.
Posted May 5, 2017 16:42 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (2 responses)
> Also a third party leakage could be compromised, how do you verify that? `Open Source Security Inc.` may not help you there.
Someone with a subscription will tell you...
Posted May 5, 2017 18:28 UTC (Fri)
by tlamp (subscriber, #108540)
[Link] (1 responses)
Then you also trust them, else the could be the one who leaked the compromised patchset.
Also even if you trust them you could make it hard to verify the validness of the leaked patch set, *if* they would release a code with a signature (I still doubt they would do that, this is merely a thought experiment). Comparing semantics is not always trivial, especially if you have thousands of thousands diffs on kernel code. Even if you are experienced kernel hacker you will still need quite some time if you really want to ensure nothing slips.
I never ever would apply a leaked security patch set to anything worth a dime for me.
If you have a trusted contact with a subscription the easiest way would be to just use their copy and stay silent.
Posted May 7, 2017 14:11 UTC (Sun)
by jond (subscriber, #37669)
[Link]
I'm not sure, but I don't think ballombe's hypothetical end-game was end-users blindly applying security patches themselves, rather the continuation of getting the useful bits mainlined.
Posted May 5, 2017 17:26 UTC (Fri)
by xtifr (guest, #143)
[Link] (10 responses)
Not that I'm suggesting anyone should violate a valid contract...
On the other hand, I would note that anyone who distributes a grs-ified kernel will be legally required to distribute their source as well. Which means they've now limited their market to those whose use of the kernel is entirely in-house. Or those willing to violate copyright. (Technically, violating the GPL, but that really means the same thing.)
Posted May 5, 2017 18:12 UTC (Fri)
by excors (subscriber, #95769)
[Link] (2 responses)
Posted May 6, 2017 0:28 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
including changes for the sake of having unique source trees for every customer sounds like a maintenance disaster.
If you aren't shipping different binaries, then the source no longer matches the binaries and you aren't in compliance.
Posted May 7, 2017 3:30 UTC (Sun)
by songmaster (subscriber, #1748)
[Link]
Assuming that each patch file is applied to a specific version of the upstream kernel I don't see any maintenance issues.
Posted May 5, 2017 18:22 UTC (Fri)
by tytso (subscriber, #9993)
[Link]
More to the point, it means that grsecurity can't be used for cell phones or IOT, or any use case where the grsecurity subscriber is not the end user. That's because the moment grsecurity shows up in a consumer device, anyone who has purchased such a device can demand source code from the manufacturer of the device, and the manufacturer would have to give them a copy of the sources, and hence, a copy of the grsecurity code. And if the manufacturer then loses all future updates to grsecurity, that's not tenable --- which means that no device manufacturer with an ounce of sense would pay $$$ for the grsecurity patches.
This means grsecurity has made it self pretty much irrelevant to the vast majority of the Linux ecosystem, and all of the Linux upstream development. This is their right to do, of course. But at this point it makes them no different than say, how Oracle is completely irrelevant to Open Solaris and its derivatives.
Posted May 5, 2017 18:41 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (5 responses)
A valid contract can't tell you that you can't distribute the code. That would be a violation of the GPL.
A valid contract can't tell you that you have to notify grsecurity if you distribute the code. That is also a violation of the GPL (by adding extra conditions on the distribution of the code).
A valid contract can't even say that if you distribute the code your contract will be terminated (at least, that's my IANAL opinion) because that is also clearly an added condition on distribution.
So, basically, you can voluntarily notify them that you distributed the code if you want to, or they can discover on their own that you did so, or suspect it or whatever. And, the next time your contract is up for renewal in the normal course of business they can elect to not renew the contract, at their prerogative, for any reason (well, other than civil rights violations etc.) They don't have to tell you why they declined renewal.
There is absolutely nothing wrong with redistribution: the GPL 100% guarantees your right to do it, and thousands of people have put in literally billions of dollars' worth of effort into Linux based on the understanding that this just fine. Under no circumstances should anyone who redistributes feel like they are cheating anyone or doing anything underhanded or unethical.
Posted May 5, 2017 19:47 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link] (3 responses)
Actually that's doable and it's been discussed many times through the years.
It's also not dissimilar from what Red Hat does with their binaries (they distribute the source, but redistributing the binaries can lead to termination of your support agreement).
Posted May 5, 2017 22:02 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (2 responses)
I'd be interested to see any such discussions that are directly applicable to that situation. If you're allowed to attach conditions that directly penalize the act of redistribution then you can have a contract that says "if you distribute the source you must pay $500 billion US", or other requirements that are equivalent to making redistribution of the source code illegal.
The Red Hat situation as you describe it is different: they aren't restricting distribution of the source code. The GPL doesn't talk about limitations on the distribution of binaries, only source code. The binaries Red Hat provides may contain other restricted works such as trademarks etc.
Posted May 5, 2017 23:39 UTC (Fri)
by zlynx (guest, #2285)
[Link]
Posted May 6, 2017 8:29 UTC (Sat)
by paulj (subscriber, #341)
[Link]
Posted May 6, 2017 8:24 UTC (Sat)
by paulj (subscriber, #341)
[Link]
There are a number of companies with this business model....
Posted May 5, 2017 19:46 UTC (Fri)
by boog (subscriber, #30882)
[Link] (1 responses)
Before leaking ensure that code from two sources has the same hash. Possible process to equalise white space etc to achieve that aim.
Posted May 5, 2017 20:39 UTC (Fri)
by tlamp (subscriber, #108540)
[Link]
Whitespace is by far the easiest, just remove them altogether where possible and let only one left where not possible.
But that doesn't help you against variable renames, structure renames, reordering, function signature changes.
Normalizing is easier said than done, remember that you can implement same semantics in different ways and even a single character can make the kernel compromised if place correctly...
Now than I think seriously about this, to check that is equal to the halting problem.
Posted May 6, 2017 0:10 UTC (Sat)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
Just write a mini code processor which changes whitespaces in indentation here and there, use different variable names, use different code structure add some hidden unicode symbols, ... I think this would be a violation of the GPL, which requires that the code be redistributed in the preferred form for making modifications. It shouldn't be hard to argue that the preferred form for making modifications is the form the coders actually use when they're working on it, so that any attempt to watermark the code the way you're describing violates that term of the GPL.
Posted May 6, 2017 0:18 UTC (Sat)
by sfeam (subscriber, #2841)
[Link] (1 responses)
Posted May 6, 2017 1:23 UTC (Sat)
by rgmoore (✭ supporter ✭, #75)
[Link]
It's not a question of the copyright status of the code. Nothing a code mangling algorithm does would count as original authorship, which would be required to have copyright implications. The question is about compliance with the terms of the GPL, which requires that code be redistributed in the preferred format for modification. Mangling the code- and the grandparent went well beyond whitespace changes to things like changing variable names and even code structure- is at least arguably changing the code from the preferred form for making modifications to something else. Somebody who was actually going to sue over GPL compliance would be foolish not to include that in their complaint.
Posted May 7, 2017 13:18 UTC (Sun)
by misc (subscriber, #73730)
[Link] (1 responses)
Posted May 7, 2017 17:41 UTC (Sun)
by rgmoore (✭ supporter ✭, #75)
[Link]
It's a grossly unfair comparison. Everyone knows that getting code pushed upstream is a long-term effort. Even in the best of circumstances it can take months, and when there are important kernel developers who are skeptical of the code it can take years. Writing a tool to watermark code by making non-critical changes is the kind of thing that could be whipped up in a day or two by anyone who cared to try. Tracking who got which watermarked version of the code would be a little more effort on top of that, but nothing drastic.
Posted May 7, 2017 13:11 UTC (Sun)
by flussence (guest, #85566)
[Link] (2 responses)
On the other hand, grsec only has to bully *one* of their customers too far and they may decide to redistribute their copy of the commercial version to KSPP, with a small monetary contribution to cover the cost of mainlining the bits they want. It would probably work out far cheaper than the $17000 per year figure I've seen mentioned in one of these threads.
Posted May 7, 2017 18:30 UTC (Sun)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted May 7, 2017 21:16 UTC (Sun)
by bronson (subscriber, #4806)
[Link]
Posted May 7, 2017 14:10 UTC (Sun)
by jond (subscriber, #37669)
[Link]
Sadly (IMHO), Wikileaks is not so interested in facilitating the leaking of anything that does not fit their current agenda/priorities. A lot of interesting stuff that used to be available via them is no longer, ever since the Manning leaks.
Posted May 5, 2017 19:13 UTC (Fri)
by dmoulding (subscriber, #95171)
[Link] (1 responses)
Posted May 5, 2017 21:47 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link]
They're not doing that at all. Not only are you unconditionally free to use and distribute the patches under the terms of the GPL, you wouldn't even be violating any separate agreement you had with grsecurity by doing so. They just won't sell their future patches to anyone who has been known to distribute them in the past, which is well within their rights.
With all due respect to RMS, I think he's wrong on this one. It's a stupid and self-destructive move, as others have already pointed out, but not a violation of the GPL.
Posted May 5, 2017 14:44 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted May 5, 2017 18:55 UTC (Fri)
by madscientist (subscriber, #16861)
[Link]
So I don't see how using a GCC plugin allows escape from the GPL. You've only switched copyright holders from the Linux kernel community to the Free Software Foundation (sole copyright holders on GCC).
Now, if/when the kernel is able to be compiled with LLVM/Clang then certain completely proprietary plugins for that compiler can be made available under essentially any license.
Posted May 5, 2017 13:59 UTC (Fri)
by madhatter (subscriber, #4665)
[Link] (21 responses)
Richard Stallman thinks that Grsecurity are violating the GPL. I'm not saying that he's automatically right, but it strikes me as a serious claim to the contrary.
Posted May 5, 2017 17:51 UTC (Fri)
by xtifr (guest, #143)
[Link] (18 responses)
If their argument is simply "sure, we allow you to distribute, as the GPL requires, but if you do so, we'll terminate your contract, completely separately from the GPL", then the problem is that they *can't* separate that from the GPL. Like many "obvious" ways to "get around" the GPL, it assumes the law is a Literal Genie which can only interpret words in their narrowest and most strict sense. This is not at all true--the law can and does take intent into account. And the *intent* here is clearly to restrict redistribution. Which is a violation of the GPL.
(Of course if, as someone suggested above, they're only going to be distributing a gcc plugin, and not kernel patches, then this *might* not be an issue.)
Posted May 5, 2017 19:04 UTC (Fri)
by linuxrocks123 (guest, #34648)
[Link] (17 responses)
They're under no obligations to sell their work to customers they don't like, for whatever reason. They could, if they wanted, refuse to sell their work to a customer because the customer publicly supported a political candidate they don't like. I think they're in the clear.
Posted May 5, 2017 20:07 UTC (Fri)
by xtifr (guest, #143)
[Link] (10 responses)
What might make it harder is if they *never admit* their reasons for not doing business with certain customers. That would switch the burden of proof. But even that would be a risky strategy, since it would be fairly obvious what they were actually doing.
Stallman's pretty experienced with people trying to weasel their way around the GPL. If he says it's a violation, I'd consult my lawyer before suggesting otherwise.
Posted May 5, 2017 21:57 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link]
If so it's a lousy way to go about it, since it doesn't actually *prevent* anyone from distributing anything. There will be a cost, of course, if you wanted their ongoing cooperation in the future in the form of new patches, but the choice is still yours whether to distribute or not. If you choose to distribute you are not violating any contract and do not lose anything to which you previously had any legal right. After all, there is no guarantee that there would *be* future patches for you to purchase, and even if they are created the authors are under no obligation to sell them to you whether you distributed the prior patches or not.
I could go around offering people a million dollars cash on the condition that they don't distribute any GPL'd code, without ever distributing GPL'd code myself. The *intent* of that offer would clearly be to reduce the distribution of GPL'd code (though not actually *preventing* it), but that doesn't mean that I've violated the GPL by making the offer.
Posted May 6, 2017 20:10 UTC (Sat)
by paulj (subscriber, #341)
[Link] (7 responses)
Posted May 8, 2017 22:30 UTC (Mon)
by mattrose (guest, #19610)
[Link] (6 responses)
Name one.
Posted May 9, 2017 20:35 UTC (Tue)
by paulj (subscriber, #341)
[Link] (5 responses)
BTW, the GPL is perfectly OK with charging money for source code, and/or for binaries.
The only thing is that if you distribute binaries without source at the same time, then you must make the source available on reasonable terms. You can charge as much as you want for source and/or binaries, with that restriction...
Posted May 10, 2017 12:40 UTC (Wed)
by mattrose (guest, #19610)
[Link] (2 responses)
Section 6 says: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
RedHat complies by giving the source code away, and just charging for the convenience of pre-compiled binaries, and limiting access to those binaries, which the GPL says nothing about.
Look at it this way. I could have access to RedHat sources even if RedHat itself wanted nothing to do with me. For access to the source code for the grsecurity version of the linux kernel, I need to pay money to grsecurity. What grsecurity is doing is very much not only against the text of the GPL, but against the spirit of Linus's original license decision.
Linus put the kernel under the GPL because he wanted all of the modifications to it to become publicly available. All other contributors have contributed to Linux with the same condition. If Linus had wanted people to be able to fork off their own version and not contribute back, he would have licensed it differently.
And the fact that you are not willing to name one publicly kinda proves my point.
Posted May 10, 2017 13:33 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted May 19, 2017 4:29 UTC (Fri)
by Garak (guest, #99377)
[Link]
Posted May 18, 2017 20:15 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
Except, that once you have distributed the binaries, you can NOT charge as much as you want for the source ...
I believe the GPL itself explicitly says you can charge a *reasonable* fee, and $1M for an hour's work for an engineer to copy the source to a CD is clearly not reasonable...
Cheers,
Posted May 19, 2017 7:34 UTC (Fri)
by paulj (subscriber, #341)
[Link]
If you have distributed in binary-only form, you must honour the §3 commitments to provide source on reasonable terms, for _finite_ amount of time.
That does not, per se, prevent one from primary distribution in source form, at whatever price. (Though, anyone who is aware the distributor is also obligated to provide source under §3 terms, or is aware to ask, obviously may prefer the §3 terms).
Posted May 10, 2017 1:00 UTC (Wed)
by linuxrocks123 (guest, #34648)
[Link]
In the US, again, anti-retaliation laws are the exception, not the rule. You can't be fired for blowing the whistle on your company to the government, like by reporting it to the EPA or whatever, because there's a specific law against companies' doing that. You can't be fired or not hired for being black because, again, there's a specific law against companies' doing that. In some but not all US jurisdictions, you can't be fired or not hired for being gay, because there's a specific law against companies' doing that; in other places, there's no such law, so a company can only hire straight people and refuse to serve gay customers if it wants to, and can fire an employee for coming out, even though it's definitely not illegal to come out.
In the law, and not just the US but pretty much everywhere, anything not prohibited is permitted. If your assertion is that the law in whatever jurisdiction you're in prohibits a company from retaliating against customers for doing a thing, you'll need to find the specific law stopping the company from retaliating against the customer for doing that thing, not just confirm that the thing the customer did isn't itself illegal to do. Just because I have the right to go on the news and talk about how horrible McDonald's is doesn't mean McDonald's still has to employ me or serve me as a customer after I do that.
Posted May 6, 2017 7:26 UTC (Sat)
by madhatter (subscriber, #4665)
[Link] (5 responses)
That seems an over-simplified analysis, to me, at least in the context of England and Wales. Cases like this one have established that, at least once you engage in business, you do not have an overriding right to refuse to make a contract with someone, that there are some reasons which the law does not permit you to use to justify a refusal so to do, and that a court may make inferences about your real reasons if you refuse without giving a justification.
Let me be clear that I'm not saying that a customer's patch re-distribution is an unlawful reason for refusal in the way that a customer's homosexuality clearly is. I'm merely starting by pointing that out that unlawful reasons for refusal to enter into a contract do exist.
So one could argue that, Grsecurity having accepted a licence which forbids them to place restrictions on the GPL-compliant redistribution activities of inter alia their customers, they do not have the right to refuse to enter into a new contract with an ex-customer simply because that customer has engaged in behaviour which (s)he was perfectly entitled to do. I have no idea if such an argument would be persuasive, but it would need a better counter-argument than "Grsecurity don't have to enter into a contract with anyone if they don't want to", because that's simply not true.
Posted May 6, 2017 7:57 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
There are certain limitations like local utilities and other regulated monopolies, and some cases of tortious interference, but they don't really apply here.
Discriminating against individuals is somewhat more complicated, the law in the US recognizes several enumerated "protected classes" ( https://en.wikipedia.org/wiki/Protected_class ). But "political opinions", for example, are not a protected class - it was absolutely legal for Hollywood to blacklist "communist supporters" during the McCarthy era.
Posted May 6, 2017 8:00 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted May 6, 2017 8:48 UTC (Sat)
by madhatter (subscriber, #4665)
[Link] (2 responses)
The second comment's argument is again, to me, over-simplistic. You may wish to consider whether the court in Wilkinson would have found the B&B owner/operator's conduct less infringing if she had said "your room will not be £59.90, it will be £100,500 a night" instead of "no room for you"; my guess is they would have been equally unimpressed. All attempts to treat one customer differently to another are things a court may examine; the US-style position that I run my business how I like and I'll deal with customers how I like isn't always permitted elsewhere.
Posted May 7, 2017 9:27 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted May 7, 2017 10:19 UTC (Sun)
by karkhaz (subscriber, #99844)
[Link]
I don't think this was ever challenged in a UK court, and wonder how it would have gone down. And if that would have changed if they discriminated the other way (offering the discount to people named Hugo or Spencer).
https://www.directski.com/shazandkev
Posted May 6, 2017 12:59 UTC (Sat)
by CChittleborough (subscriber, #60775)
[Link] (1 responses)
Posted May 6, 2017 13:08 UTC (Sat)
by madhatter (subscriber, #4665)
[Link]
Posted May 6, 2017 5:59 UTC (Sat)
by citypw (guest, #82661)
[Link] (3 responses)
With all due respect, I really appreciate you've been bring us high quality technical articles/reviews and the up-to-date conference/community news. Do you really believe what you wrote in this article? If that's what your thought, I think we may have very different philosophical ideas formed us into the different kind of ppl. Getting things upstream is good but "everything should be mainlined" is a religious faith. In case of PaX/Grsec, KSPP is a very good starting point but the fact I have to face in my daily life is there are "massive" exploitations in the wild can not be mitigated by the current version of KSPP. Who was the victim in those days of "one null-ptr deref exploit can rule them all"? Of course it's both community user and commercial users. Some commercial users even thought SELinux can help back in old days but we both know what really happened. Did RedHat ever made some compensation to RHEL users who paid? I don't think so. As a security consultant, I've been trying to avoid those "histories" from repeating in my life. Some ppl are taking the consequences of LF/CII's PR and I explained what I saw here:
http://openwall.com/lists/kernel-hardening/2017/05/04/10
btw, I still believe LF is zero integrity to me:
http://openwall.com/lists/kernel-hardening/2017/05/04/20
LF has different ways to treat different ppl. They treat you nicely maybe only because you are a reporter and they can get some benefit from your report. But most of ppl are just nobody and irrelevant to them. Btw, you didn't answer my previous question:
https://lwn.net/Articles/721253/
Are you seriously think they will talk to individual or small business?
Posted May 6, 2017 7:47 UTC (Sat)
by niner (subscriber, #26151)
[Link]
Posted May 6, 2017 11:35 UTC (Sat)
by karkhaz (subscriber, #99844)
[Link]
Where did anybody say that "everything should be mainlined"? I think corbet was fairly balanced about this, pointing out that maintaining patches OOT is expensive, but that grsec have no obligation to upstream stuff if they don't want to.
Posted May 6, 2017 13:55 UTC (Sat)
by corbet (editor, #1)
[Link]
"Everything should be mainlined" does not appear in this article. But mainlining code is the best way to have a kernel that is coherent as a whole and maintainable going forward. Need I point out that, had all this code been upstream, your ability to make use of it for free in your role as a security consultant could not have been taken away from you by the grsecurity developers in this way?
I still don't understand why you think that a business decision made by the developers involved is somehow the Linux Foundation's fault. I'm known to be a slow person, so hopefully you'll understand if I just can't follow a couple of steps in the logic.
Posted May 6, 2017 21:50 UTC (Sat)
by jgrip (guest, #95564)
[Link]
Would at a first thought make it next to unusable in sold products.
Posted May 8, 2017 5:56 UTC (Mon)
by prasannatsm (subscriber, #109835)
[Link] (1 responses)
Posted May 8, 2017 9:58 UTC (Mon)
by ber (subscriber, #2142)
[Link]
Posted May 8, 2017 8:31 UTC (Mon)
by samth (guest, #1290)
[Link] (1 responses)
Posted May 8, 2017 10:59 UTC (Mon)
by itvirta (guest, #49997)
[Link]
Posted May 9, 2017 4:36 UTC (Tue)
by ncm (guest, #165)
[Link]
Yes, kernel code will be improved, but will the rate of improvement exceed that of the addition of new code? It seems unlikely. Since new security holes arrive in new code, while improvements generally target the most familiar code, the natural tendency of security, even with earnest effort, is not upward.
If the kernel community were to adopt rigorous standards and checklists to vet new code, the trend might be reversed, but I don't know what those would look like. Anyway it is absurd to think kernel developers would buy into what would be needed to actually be effective; and even that would be only part of a serious program.
Security weaknesses mostly arise as an accumulation of small weaknesses, each innocuous enough by itself. The kernelers have traditionally sneered at any weakness that was not a full exploit, all on its own, or anyway demonstrated to be a link in a complete exploit. That attitude is not compatible with getting or keeping a secure kernel.
So, they will muddle along, and we will make do, and console ourselves imagining how much worse it could be, and has been.
Posted May 11, 2017 1:35 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (4 responses)
Posted May 11, 2017 9:36 UTC (Thu)
by jubal (subscriber, #67202)
[Link]
Posted May 11, 2017 9:50 UTC (Thu)
by dunlapg (guest, #57764)
[Link]
what exactly benefits *grsecurity* (you know, what you defined
as a kernel patch)[...] I wish you could understand how this kind of thing completely undermines any credibility you might have. If you're either unable or unwilling to to comprehend the meaning of a simple and obvious sentence, how can I trust any characterizations or summaries you make about other people's statements or intentions in more complicated situations?
Posted May 11, 2017 13:54 UTC (Thu)
by corbet (editor, #1)
[Link]
I read through the entirety of your response — took a while — but I don't really see that it addresses much that was said in this article.
Posted May 11, 2017 15:02 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
Wow, this is *really* a new low...
And then you wonder, why some people don't want to work with you?
*Plonk*
Posted May 18, 2017 10:59 UTC (Thu)
by ledow (guest, #11753)
[Link]
- If grsecurity WANT it upstream, you have to play by upstream rules.
But just saying "Hey, look, we fixed that problem but only in a way entirely incompatible with the kernel development / testing process, and we'll never upstream it" and then moaning that upstream are always "behind" is a bit petty. Especially when you have no interest in fixing the non-security problem in a random third-party PCIe hardware driver that's also coming in, and necessary, but which you then include in your works after upstream do that for you.
What's happened is actually the latter of the two scenarios - upstream take the security concerns on board, and would love a series of patches to fix it, but are effectively starting down the long road of duplicating all the effort involved on their own and without assistance because they're the only ones who actually want to play ball, and get the code into the kernel, and because it's many years down the line and nobody else has yet managed to pull anything back towards the kernel. And that's, quite clearly, a slower process to go through because it's NOT the only obligation on those people to pull in those patches, they have other things to do.
Ripping out, starting again, and doing everything your own way is quite obviously easier to do than working with a large project to get code accepted, as there's nobody to question, veto, convince or approve things like changing API or ABI, modifying the way critical functions work, or anything else.
The "extra work" of putting that stuff into the kernel seems to lead to the KSPP complaint too. "How dare they impose the same kernel submission processes on us as on every other developer, we're grsecurity, we should just get free reign and our all-ranging code modifications pulled in without question." And with security, that worries me.
Someone has to take the time and effort to pull security changes into the kernel. The larger and more wide-ranging the change, the harder the work and the longer it takes. The kernel people can do it. But it will be slow as they have other stuff to do and take account of. The grsecurity people could do it. But they don't, despite it being their biggest concern, most vocal complaint and their "only job" (in effect) is to get security code that works with the kernel.
And it seems to be because they cannot work to anyone else's requirements whatsoever, or discover a third-party who's willing to work with both sides to do the work. There are thousands of companies contributing to the kernel, and lots of "go-betweens" because the most horribly-closed of commercial projects and the open kernel processes. But not one can be found to negotiate the middle ground between the kernel and grsecurity.
To me, that doesn't bode well for any kind of development. Especially security-related development that requires discussion, is likely to break user experiences, touches on every part of the kernel, may well require quick fixes at critical moments, and which everyone has to understand if it's to work properly.
We seem to always be in this same circle with grsecurity, and I'm not at all sure that we aren't benefiting from that stalemate.
If this code was in-kernel, and grsecurity had everything they needed inside the kernel, and they were working on new defences, we'd still end up with the same conversation again for those. And, presumably, for updates of any new grsecurity patch, bugfix or whatever as it needs to be pulled back into the kernel.
And when there's no end in sight because of not following the process, the code is effectively dead from a kernel point of view.
Posted May 19, 2017 14:26 UTC (Fri)
by sergey (guest, #31763)
[Link] (6 responses)
> Paying for work on free software, intended to improve the security of the Linux kernel, does not seem like a particularly blameworthy activity, so it's not entirely clear why the Linux Foundation is being faulted here.
Grsecurity is the author of the work and they claim they don't get any of these payments.
> There is a much more likely explanation here: the movement of hardening features into the mainline kernel poses challenges to the developers' business model, which depends on providing security features not found there.
Their business model is not far different from any antivirus vendor and hinges on the kernel's and attackers' constant evolution. What can take it away is if attackers stopped inventing exploits or Linux stopped releasing new versions. Hardening patches are result of their very specialized, and highly regarded, expertise. Grsecurity doesn't appear to excel at interpersonal relations and this move is clearly to spite the community for diverting compensation they thought they deserve (correctly, I think) and has little to do with what their clients pay them for.
Posted May 19, 2017 15:07 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
Why aren't you also proposing that everyone who works on the scheduler have their financial backing investigated? What about new filesystems? Lustre is really suspicious, you know, it's obviously being funded by disk manufacturers to increase demand for their drives! (... which might indeed be part of the motivation, but increasing demand for your drives by making better filesystems that can use big collections of drives better is, again, not suspicious, but actually good customer service which should be encouraged.)
Posted May 21, 2017 17:05 UTC (Sun)
by flussence (guest, #85566)
[Link]
I have to wonder, but I'm not particularly interested in an answer: who *is* going to pay them now?
Their product is now behind a paywall so the little people can't use it, and they punish large orgs who *could* afford it by killing the contract if they “leak” the source and charging costs to reinstate it reminiscent of RIAA lawsuit plea bargains.
If you're actually a FOSS-friendly company, as opposed to a scummy TiVo/Allwinner type, there's no reason to use or fund grsec because they've stated plainly they will screw you for daring to comply with the letter and spirit of the kernel's GPL.
Posted May 19, 2017 15:21 UTC (Fri)
by corbet (editor, #1)
[Link] (3 responses)
— Kees Cook, May 11
Posted May 21, 2017 21:40 UTC (Sun)
by PaXTeam (guest, #24616)
[Link] (2 responses)
Posted May 22, 2017 11:45 UTC (Mon)
by flussence (guest, #85566)
[Link]
Maybe your only purpose is to serve as a warning to others.
Posted May 23, 2017 14:58 UTC (Tue)
by bronson (subscriber, #4806)
[Link]
Grsecurity goes private
Grsecurity goes private
Not really because the closed down, but rather their behavior in the past. They produced a lot of mockery and arrogance against people who really try to upstream security/hardening to the Kernel, which *is* hard, instead of helping them.
https://lwn.net/Articles/721750/
Grsecurity goes private
the kernel's benevolent dictator engages in on a semi-regular basis? Large swaths of the "kernel community" seem to have no problem with that kind of mockery so I don't see why this would be a problem.
Grsecurity goes private
>the kernel's benevolent dictator engages in on a semi-regular basis?
Grsecurity goes private
https://www.theregister.co.uk/2016/08/26/linus_torvalds_c...
Grsecurity goes private
* "calls own lawyers a 'nasty festering disease'"
* "David Howells was informed that he was "f*cking moronic""
* "Kay Sievers was dismissed as a "f*cking prima donna"" and
* "anyone who didn't follow his particular comment syntax style was "brain-damaged.""
What he actually said was: "this arguing for lawyering has become a nasty festering disease". He calls the behavior a disease, not the people.
The actual quote is: "Not without a lot more discussion first. Quite frankly, this is f*cking moronic." Again "this is", not "you are" as theregister would make you believe.
Grsecurity goes private
Grsecurity goes private
The distinctions between "what you said is fucking moronic", "you are being fucking moronic", and "you are a fucking moron" are very fine.
actually, they're not. I teach my children not to say "you're an idiot" but to say "you did something idiotic". Or not to say "you're a liar" but to say "you lied". In one case, you condemn the person as a such and forever, in the other case you point out that the person did something bad, implicitly also saying that the next time that person shouldn't do that (bad) thing.
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
I was referring to the public comments about it, not the phenomenon itself. I have only noticed widespread public discussion of it recently.
Grsecurity goes private
Grsecurity goes private
That was my point. I find the apparent cultural shift interesting. People seem more likely now to interpret an irritable (but not personally directed) remark as an ad hominem attack when that was not the intent behind the words. Note that I am not condoning genuinely abusive behaviour here - I just don't think Linus' criticisms count as such.
Grsecurity goes private
Grsecurity goes private
Anyway, "What'in a name? That which we call a rose.."
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Does something prevent distributing the patches?
2. From now on, they will only provide the patch to individuals and organizations who pay.
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Having two subscriptions could be helpful here, but the subscriptions are quite expensive AFAIK.
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
It is really really easy to add a signature to code.
But hard to make one that won't show up for diff if two people cooperate to release the code. :)
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
They're patchsets are huge (yuge!) and they are far from stupid and far from non-creative, so they *could* do really a lot and make any tries to normalize the code not worth the try.
If this was doable, like you say, prove it formally and you have solved the halting problem and thus get a few prices, a few millions of $ and a really lot of recognition.
Does something prevent distributing the patches?
It is really really easy to add a signature to code.
Good luck on that one. You're seriously arguing that whitespace affects the copyright status of a work?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
Does something prevent distributing the patches?
That is how I understand the FAQ anyway.
Does something prevent distributing the patches?
This decision is within their right to make, as long as they stay within the terms of the GPL (and there have been no serious claims that they have done otherwise)
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
open source code gone dark
Linus put the kernel under the GPL because he wanted all of the modifications to it to become publicly available. All other contributors have contributed to Linux with the same condition. If Linus had wanted people to be able to fork off their own version and not contribute back, he would have licensed it differently.
I'm guessing that there are plenty of instances of people and businesses that modify GPLd code, and use it, often commercially, without making those modifications publicly available. It's just that those instances don't involve the distribution of those modifications publicly. I.e. one can readily imagine the NSA and CIA and Google hardening (some of) the kernels that they and their cohorts use without those modifications ever seeing any public light of day. Sorry to get pedantic about the nuance, but this does seem to be the place for it. Probably the CIA/NSA use some god-mode of legaleze to get around whatever they want, but there is clearly nothing illegal about making a business out of the fact that your secret unreleased/undistributed security enhancements give your IT infrastructure an edge over competitors. I.e. imagine a dozen hypothetical GMail competitors running modified linux kernels on their servers. The ones that get hacked the least make the most $$ in the long run. Obviously the hypothetical breaks down in the real world for lots of reasons, but I do imagine there are plenty of high profile businesses running servers with various secret sauce hardenings. Which is pretty much what this is all about AFAICT.
Grsecurity goes private
Wol
Grsecurity goes private
Grsecurity goes private
They're under no obligations to sell their work to customers they don't like, for whatever reason.
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
No problem. We have a very special price for your new contract: $100500 for each line of code that we deliver. Very cheap! Please send pre-payment checks to: .....
Cyberax, I think the points in your first comment are excellent. I'm certainly not suggesting the English approach is persuasive everywhere, and the B2B vs. B2C distinction is well-worth closer examination (though if it were found to hold water, putting up an individual as a single protected transactor who could then redistribute without fear of comeback might well be something the community thought to do). I'm merely noting that linuxrocks123's argument is over-simplistic, and may not work everywhere.
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
and advertising flyer:
https://www.cheapflights.co.uk/news/wp-content/uploads/20...
Grsecurity goes private
That is not entirely surprising, as his comment is from mid-2016. Nevertheless, the posting that reports it (from Jun 2016) notes that "GRsecurity is preventing others from employing their rights under version 2 the GPL to redistribute (by threatening them with a non-renewal of a contract to receive this patch to the linux kernel.)", which looks to me exactly like the situation under discussion. So it looks to me like Grsecurity didn't decide this out of the blue, and RMS's comment was on the start of the process which they have now finished. I could be wrong, though.
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Yes, I believe what I wrote.
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
Grsecurity goes private
grsecurity and Linux security in general (including here on LWN comments), has not been
up to what I consider the usual standards of civilized discourse between engineers looking
to solve a problem.
"More secure over time"?
Grsecurity goes private
…that above, old chap, is a serious accusation, and one that usually should be proven by the accuser; care to give us some facts (and I mean facts, not your usual happy excrement throwing routine)?
Grsecurity goes private
Grsecurity goes private
Finally, even if you can somehow disregard the thousands of upstream changes benefiting grsecurity[...]
You remind me of my state's esteemed Republican senator, who likes to say that the people showing up at his town halls are paid by some shadowy entity to be there. For the record, LWN has never accepted payment to write or publish an article.
Who paid for it
Grsecurity goes private
Grsecurity goes private
- If upstream WANT it, they will take the time/effort to take your code and change it to work by their rules.
Grsecurity goes private
Grsecurity goes private
KSPP clearly claim they're fixing (or "fixing," depending on who's talking) grsecurity as part of their work, hence they admit to doing upstreaming rather than just borrowing ideas. The authors of the code want to port patches on their terms and get paid for it, and their estimate of thousands of hours doesn't seem far off the mark so we're talking about a potential commitment of a ~$1M here. There's an obvious conflict because whoever is sponsoring this chose KSPP developers, a 3rd party, and not the authors. Good journalism would be to follow this money and get to the bottom of such decision.
Are you seriously suggesting that wanting security improvements without having to deal with the grsecurity developers' charming personalities is so suspicious that a financial investigation should be launched? If security were being worsened you might be right, but I don't think security improvements (that grsecurity has been loudly lauding for years) are exactly a sign of corruption or malfeasance, any more than performance improvements or support for new hardware are.
Grsecurity is the author of the work and they claim they don't get any of these payments.
Given that they have explicitly refused to accept payment from any of the bodies willing to pay for it, this is not particularly surprising nor a sign of anything but obstreporousness on the part of the grsecurity developers.
Grsecurity goes private
Following the money
"If a financial arrangement is desired, I believe
my employer continues to be willing to explore it now just as they
have in the past."
Following the money
Following the money
Following the money