Important Notice Regarding Public Availability of Stable Patches(grsecurity.net)
grsecurity.net
Important Notice Regarding Public Availability of Stable Patches
https://grsecurity.net/announce.php
21 comments
I'm pretty sure Wind River Linux is using kernel versions grsecurity would approve of. https://forums.grsecurity.net/viewtopic.php?f=3&t=3938&p=139... seems more likely to indicate the problem company.
That's infuriating.
As a general rule, smaller companies that release their code under the GPL have almost no recourse against huge companies violating their copyrights. One of the big flash drive makers released their own portable browser based on PortableApps.com's Firefox Portable a few years back and distributed it on millions of drives with my name and all copyrights stripped off of it. This happened after I'd been in negotiations with them about using our software platform and fully informed their subsidiary in charge of their resulting software platform of the legal obligations of the GPL including a direct call with the subsidiary's CEO. The most I could do was send them a C&D.
To add insult to injury, the subsidiary released a hardware product years later and another company released a similar but different product in the same segment. The subsidiary sued the other company and had this PR story published about how the CEO was so offended by the "theft" and had to sue them to be able to look his kids in the face.
To add insult to injury, the subsidiary released a hardware product years later and another company released a similar but different product in the same segment. The subsidiary sued the other company and had this PR story published about how the CEO was so offended by the "theft" and had to sue them to be able to look his kids in the face.
This is not at all true. They are liable for significant monetary damages for violating copyright, and you can find a lawyer to take up the case if you own the copyright. There are a couple well known organizations who have gotten paid more than their expenses from lawsuits against gpl violating companies: sfconservancy.org, sflc.org., fsf.org.
In principle, yes. In practice, large companies have extensive legal resources and can afford to drag out a lawsuit far beyond the resources of a team volunteer/hobbyist developers.
It's great that groups like the FSF and Software Freedom Conservancy are using their funds to support legal action when necessary, but they can't be everywhere and enforce everything.
It's great that groups like the FSF and Software Freedom Conservancy are using their funds to support legal action when necessary, but they can't be everywhere and enforce everything.
In practice, yes. First of all, all those organizations have enforced the gpl on behalf of "a team volunteer/hobbyist developers" from large companies. In fact, it's the primary kind of enforcement they do. Second of all, individuals who have zero resources win lawsuits against large companies EVERY SINGLE DAY. Lawyers work on contingency and pro bono. Stop this hand waving crap saying the gpl can't "really" be enforced for volunteer efforts.
From the article we are discussing, you probably should recommend grsecurity a few lawyers.
Yeah, again, no it doesn't work that way. Again, the folks you mentioned generally only work for non-profits and individual hobbyist devs. They don't work with for-profit companies (even if the company isn't making a profit at present).
And the whole contingency thing... a lot less common than you think. Speaking as someone that's had his copyright ripped off multiple times and been injured due to negligence by the city of New York and/or Amtrak and looked into it with multiple attorneys in each case.
For the most part, the legal system serves those with means and those with means alone.
And the whole contingency thing... a lot less common than you think. Speaking as someone that's had his copyright ripped off multiple times and been injured due to negligence by the city of New York and/or Amtrak and looked into it with multiple attorneys in each case.
For the most part, the legal system serves those with means and those with means alone.
> it doesn't work that way. Again, the folks you mentioned generally only work for non-profits and individual hobbyist devs
"that way" which I said it worked, was for non-profits and hobbyist, and so was the comment I was replying to, so yes, it does work that way.
> those with means and those with means alone.
Your own comment explained says that it works for other people.
"that way" which I said it worked, was for non-profits and hobbyist, and so was the comment I was replying to, so yes, it does work that way.
> those with means and those with means alone.
Your own comment explained says that it works for other people.
The problem is the same for photographers as for coders. The law that prevent advertisement companies from lifting a image from flikr is the same that prevent companies from lifting some code and removing the license.
Every time and again I read news about some photographer than sued some company and got a million or so for the efforts. Its not easy, quite expensive and I guess many author do give up rather than push forward, but there is recourse against huge companies that violate copyright. The good thing about such lawsuits is that the burden of proof for having a license sits on the infringer, which means a judge don't actually need to understand that fine details of software licenses in order to find someone guilty of infringement.
Every time and again I read news about some photographer than sued some company and got a million or so for the efforts. Its not easy, quite expensive and I guess many author do give up rather than push forward, but there is recourse against huge companies that violate copyright. The good thing about such lawsuits is that the burden of proof for having a license sits on the infringer, which means a judge don't actually need to understand that fine details of software licenses in order to find someone guilty of infringement.
All that notwithstanding, it appears that pursuing one of these cases is terribly expensive. Does the avenue exist? Yes. Is it actually available to those who don't have a bunch of cash to burn? No.
As JohnTHaller said: "For the most part, the legal system serves those with means and those with means alone."
As you said: "Its not easy, quite expensive..."
As JohnTHaller said: "For the most part, the legal system serves those with means and those with means alone."
As you said: "Its not easy, quite expensive..."
Apple has been selling closed-source knock-off of my GPL app for 6 months after acknowledging they've received my takedown request. They've eventually took it down, but they haven't notified users and kept the money.
I've asked sfconservancy and fsf for help, but they wouldn't take the case.
I've asked sfconservancy and fsf for help, but they wouldn't take the case.
For most of us, it doesn't actually work that way. Folks like you've mentioned don't take on work unless you're a non-profit. And a pro-bono attorney generally won't touch a case like I mentioned, speaking as someone who asked multiple attorneys.
What about the DMCA? It seems like people cower in fear of it, but only with regards to the entertainment industry. Is that only because it's dangerous when the copyright holder is a huge corporation, but remains effectively toothless for those unable to support years of litigation?
The DMCA safe harbor applies to intermediaries. It essentially says nobody can sue YouTube for the copyright infringement of its users if they take down user content on request. The problem with it is that the intermediaries have no practical way of knowing whether the user who posted the content had a legal right to, so it causes everybody execute takedown requests regardless of merit.
People violating the GPL usually aren't intermediaries. If they don't get the safe harbor to begin with then they can't lose it by not following the takedown process.
I wonder if an intermediary could be found though. If an infringer is hosting their website on AWS, what happens when somebody sends a takedown notice to Amazon?
People violating the GPL usually aren't intermediaries. If they don't get the safe harbor to begin with then they can't lose it by not following the takedown process.
I wonder if an intermediary could be found though. If an infringer is hosting their website on AWS, what happens when somebody sends a takedown notice to Amazon?
The other thing about YouTube takedowns is that they're often technically not DMCA takedowns anymore. Technically, false DMCA claims open the claimer to penalties. But, if the Content ID match (even on a false positive) or one of YouTube's contractual obligations triggers, the content is flagged without going through the DMCA process.
https://www.eff.org/issues/intellectual-property/guide-to-yo...
https://www.eff.org/issues/intellectual-property/guide-to-yo...
Sounds like Verifone is one of the GPL violators. They are known for being "open" except when you want to innovate without permission.
http://global.verifone.com/products/software/v-os/ - Says its Linux Based.
http://www.verifone.com/products/hardware/multimedia/ - Have an MX 900 series of products.
http://www.verifone.com/products/hardware/petro-pos-systems/ - Have a Petro series of Products
NYSE:PAY - are a multi-billion dollar company.
Employee asking for help: https://forums.grsecurity.net/viewtopic.php?f=3&t=3938&p=139...
GRsec saying its verifone: https://twitter.com/grsecurity/status/450995354972864513
Thread indicating they are using an old unmaintained kernel: https://twitter.com/grsecurity/status/424914478912651264
Industry called out specifically: "Not only has the entire embedded industry as a whole not contributed a single dime toward our continued development and maintenance (despite our work being critical to the security of the millions of devices using our code: streaming media players, credit card processing systems, etc), the companies we've identified have actively violated the GPL and even our trademark. These transgressions have continued despite their awareness and our legal action."
http://global.verifone.com/products/software/v-os/ - Says its Linux Based.
http://www.verifone.com/products/hardware/multimedia/ - Have an MX 900 series of products.
http://www.verifone.com/products/hardware/petro-pos-systems/ - Have a Petro series of Products
NYSE:PAY - are a multi-billion dollar company.
Employee asking for help: https://forums.grsecurity.net/viewtopic.php?f=3&t=3938&p=139...
GRsec saying its verifone: https://twitter.com/grsecurity/status/450995354972864513
Thread indicating they are using an old unmaintained kernel: https://twitter.com/grsecurity/status/424914478912651264
Industry called out specifically: "Not only has the entire embedded industry as a whole not contributed a single dime toward our continued development and maintenance (despite our work being critical to the security of the millions of devices using our code: streaming media players, credit card processing systems, etc), the companies we've identified have actively violated the GPL and even our trademark. These transgressions have continued despite their awareness and our legal action."
"Since our lawyer has advised us not to mention the companies by name"
Yeah, uh, they're lawyers, they always say that, it's not a signal with any information in it.
As you said, this company can outspend you, and it's not worth it for you to try litigating. Public shaming is all you have! And, since the primary issue was them claiming their kernel has "grsecurity", public shaming is actually a great solution: try to make the technical community aware that this company's security hardening doesn't deserve the "grsecurity" description. You may even get more business from competitors who want to be able to say they worked with you on their grsecurity integration.
Yeah, uh, they're lawyers, they always say that, it's not a signal with any information in it.
As you said, this company can outspend you, and it's not worth it for you to try litigating. Public shaming is all you have! And, since the primary issue was them claiming their kernel has "grsecurity", public shaming is actually a great solution: try to make the technical community aware that this company's security hardening doesn't deserve the "grsecurity" description. You may even get more business from competitors who want to be able to say they worked with you on their grsecurity integration.
The lawyers say that because they're advising their clients not to set themselves up for a libel suit, not because they're buzzkills. In other news, doctors recommend you eat healthy, but don't they always say that?
ya know... my mother is a doctor, a Family Practitioner (FP). She's the type who's probably more frank with her patients than most. But she still would give slightly different advice to family than to patients. This is to manage risk of lawsuits, unreasonably angry patients, etc. It has to do with the balance of risk and blame. You can imagine the typical stuff - excessive tests, end-of-life decisions...
I suspect they are hoping the public will do it for them. They gave enough clues for that.
That way they said it, without actually saying it.
That way they said it, without actually saying it.
This is such a bummer! I just recently switched over to grsec (on Arch) and I could not be happier with the results; seriously, it has made such a huge increse in security so simple to navigate. The Grsec team does incredible work; that no lawyer is willing to pursue this case saddens me, but that's a secondary issue. The core problem here is the corporations with money have functionally unlimited legal authority. It is so far beyond me that society has allowed this to come to be and continues to do nothing to stop it.
To Brad and the PaX team directly (if you read this): You do incredible work and I sincerely hope this move leads to an inundation of sponsorship so that even more people can benefit from your hard work and innovation. Till then, know that there are those of us that stand behind you 100 percent!
To Brad and the PaX team directly (if you read this): You do incredible work and I sincerely hope this move leads to an inundation of sponsorship so that even more people can benefit from your hard work and innovation. Till then, know that there are those of us that stand behind you 100 percent!
This angers me. I mean, they're doing the right thing, but it should never have come to this.
volunteers shouldn't be shelling out thousands in copyright and licensing violations- even if they won in court, the amount awarded back would probably be a pittance compared to what these manufacturers make by using their code/trademarks.
I love what the pax guys do, almost every major exploit in the last year is mitigated in some form by grsec.. I wonder what becoming a sponsor entails.. I mean, I wish I could support all the FOSS I use, but I'd go broke pretty quick. :(
volunteers shouldn't be shelling out thousands in copyright and licensing violations- even if they won in court, the amount awarded back would probably be a pittance compared to what these manufacturers make by using their code/trademarks.
I love what the pax guys do, almost every major exploit in the last year is mitigated in some form by grsec.. I wonder what becoming a sponsor entails.. I mean, I wish I could support all the FOSS I use, but I'd go broke pretty quick. :(
> I mean, I wish I could support all the FOSS I use, but I'd go broke pretty quick. :(
Yeah I seem to have that a lot as well.
What I figured a while ago, in summary, is this: we will always use more than we can contribute back. As a silly example, I am grateful for the invention of the wheel but in no way could I pay someone back (living or dead) for every single thing like that. The important thing is that we do something. Contribute either with time and skill or with money to a few projects you care about and which you feel can actually use your help. That's still tricky, though, I wouldn't know which of the 2100 installed apt-get packages need my support the most, but realizing this (rather than feeling indebted) gives me some peace of mind.
(If anyone cares, I actually blogged about this: http://lucb1e.com/?p=post&id=121 )
Yeah I seem to have that a lot as well.
What I figured a while ago, in summary, is this: we will always use more than we can contribute back. As a silly example, I am grateful for the invention of the wheel but in no way could I pay someone back (living or dead) for every single thing like that. The important thing is that we do something. Contribute either with time and skill or with money to a few projects you care about and which you feel can actually use your help. That's still tricky, though, I wouldn't know which of the 2100 installed apt-get packages need my support the most, but realizing this (rather than feeling indebted) gives me some peace of mind.
(If anyone cares, I actually blogged about this: http://lucb1e.com/?p=post&id=121 )
Most, but not all, companies generally don't donate any money to server OSes and open source they deploy by the hundreds of thousands. It sucks but it's the current state of affairs. (I think more FOSS should be be less free and monetized more in the context of large-scale enterprise purposes, in order to keep developers' bills paid and support quality up. The honor system doesn't work because most corporate choose to "cheat" where possible.)
If a project releases open source totally for free, it cannot realistically expect sponsorship to magically appear.
If a project needs sponsorship to keep the lights on, the we're closing up shop, unless ... routine works.
If a project prefers to become a commercial product with a freemium option, they should do such.
Otherwise, don't slave away on a project and resent what you cannot afford to give away. Just don't do it, if you can't live with it being exploited by companies for free.
Punishing everyone for the sin of a few rogue companies is the kindergarteners routine and childish. It doesn't work and it just angers people without solving the licensing issue at a core level.
PS: Perhaps grsecurity may want to instead consider a sensible noncommercial license similar to somewhere between AGPL and something like what good ol' evil Oracle would license their DBMS, i.e., companies over X employees or Y revenue need a license; hobbyists, academics and individual developers exempted. Drama resolved.
If a project releases open source totally for free, it cannot realistically expect sponsorship to magically appear.
If a project needs sponsorship to keep the lights on, the we're closing up shop, unless ... routine works.
If a project prefers to become a commercial product with a freemium option, they should do such.
Otherwise, don't slave away on a project and resent what you cannot afford to give away. Just don't do it, if you can't live with it being exploited by companies for free.
Punishing everyone for the sin of a few rogue companies is the kindergarteners routine and childish. It doesn't work and it just angers people without solving the licensing issue at a core level.
PS: Perhaps grsecurity may want to instead consider a sensible noncommercial license similar to somewhere between AGPL and something like what good ol' evil Oracle would license their DBMS, i.e., companies over X employees or Y revenue need a license; hobbyists, academics and individual developers exempted. Drama resolved.
> PS: Perhaps grsecurity may want to instead consider a sensible noncommercial license similar to somewhere between AGPL and something like what good ol' evil Oracle would license their DBMS, i.e., companies over X employees or Y revenue need a license; hobbyists, academics and individual developers exempted. Drama resolved.
Being a set of Linux patches, it would be hard for them not to make their code available under GPLv2.
They can do the Red Hat thing of making code available only to paying customers, and terminating their customers' accounts if they redistribute things publicly. They mention that in the post.
Being a set of Linux patches, it would be hard for them not to make their code available under GPLv2.
They can do the Red Hat thing of making code available only to paying customers, and terminating their customers' accounts if they redistribute things publicly. They mention that in the post.
This isn't about money, this is about abuse of the trademark.
Ah Spender. Always the drama queen.
The real problem here is not companies abusing the GPL (good luck with that), but grsecurity not being integrated with mainline after more than a decade.
You see, if Spender really cared about security he would work with the kernel developers in order to get grsecurity into the kernel but of course being such a famewhore, he never did that. Everything is fine as long as he is the center of attention, actual security be damned.
Spender: I among many have little sympathy for you, you've long exhausted our patience with your antics. Grsecurity is a niche project with minimal actual security impact in the "real world", all because of the deranged way you choose to manage it. Your primary concern, your _ONLY_ concern should be getting grsecurity into the kernel, not companies ripping you off, not companies abusing your trademark, not companies "not playing nice". In the grand scheme of things, these are irrelevant.
The real problem here is not companies abusing the GPL (good luck with that), but grsecurity not being integrated with mainline after more than a decade.
You see, if Spender really cared about security he would work with the kernel developers in order to get grsecurity into the kernel but of course being such a famewhore, he never did that. Everything is fine as long as he is the center of attention, actual security be damned.
Spender: I among many have little sympathy for you, you've long exhausted our patience with your antics. Grsecurity is a niche project with minimal actual security impact in the "real world", all because of the deranged way you choose to manage it. Your primary concern, your _ONLY_ concern should be getting grsecurity into the kernel, not companies ripping you off, not companies abusing your trademark, not companies "not playing nice". In the grand scheme of things, these are irrelevant.
I can appreciate that it's been a bit like that, but isn't the truth really somewhere in between?
Oversized egos are a problem at the best of times in open source, especially in the kernel. Which has traditionally had a culture of casual indifference toward the security priorities of PaX/grsec, and some would say toward security generally (I don't buy that - there's a lot of concern for integrity in the kernel, and that at least buys you some security).
Whilst it would have been great if Spender could have completely changed his personality, outlook and perspective on the world so that he could commandeer the linux kernel from the outside-in toward his vision of a safer kernel, is that really compatible with the wider project? And so, it's equally depressing there hasn't been more recruitment from the kernel side - the side that actually has resources - to figure out a path toward getting PaX stuff mainlined from the inside-out.
I guess my point is: grsec has one focus, one priority. But the Linux kernel is a project that has a much more vast, broader scope of competing priorities to untangle, and I just can't see that such an enormous, busy and byzantine project ecosystem truly will ever see a clear mandate to get something as disruptive and single-minded as grsec mainlined.
Not only would Spender have to become a different person, but the core kernel teams as well.
In any case, I've reduced my patreon donations and put what little that is towards grsecurity. It's certainly that important and useful to me.
Oversized egos are a problem at the best of times in open source, especially in the kernel. Which has traditionally had a culture of casual indifference toward the security priorities of PaX/grsec, and some would say toward security generally (I don't buy that - there's a lot of concern for integrity in the kernel, and that at least buys you some security).
Whilst it would have been great if Spender could have completely changed his personality, outlook and perspective on the world so that he could commandeer the linux kernel from the outside-in toward his vision of a safer kernel, is that really compatible with the wider project? And so, it's equally depressing there hasn't been more recruitment from the kernel side - the side that actually has resources - to figure out a path toward getting PaX stuff mainlined from the inside-out.
I guess my point is: grsec has one focus, one priority. But the Linux kernel is a project that has a much more vast, broader scope of competing priorities to untangle, and I just can't see that such an enormous, busy and byzantine project ecosystem truly will ever see a clear mandate to get something as disruptive and single-minded as grsec mainlined.
Not only would Spender have to become a different person, but the core kernel teams as well.
In any case, I've reduced my patreon donations and put what little that is towards grsecurity. It's certainly that important and useful to me.
Do you mean Spengler, perhaps?
I think "spendy" is his irc nick.
And "spender" is his grsec machine nick https://www.grsecurity.net/~spender/
The test series, unfit in our view for production use, will however continue to
be available to the public
This is such a shit situation to be in. Hopefully this publicity gains them some traction with the companies and communities who do care about it.
I'm obviously misunderstanding something about this.
Since grsecurity is GPL'd (being modifications to the GPL'd kernel), anyone that is "a customer of any product that uses grsecurity in binary form, [is] entitled to the complete corresponding source code." Which means their stable patches will get requested and released by someone anyway.
Help me understand how this will have any effect on the actual availability of their stable series?
Since grsecurity is GPL'd (being modifications to the GPL'd kernel), anyone that is "a customer of any product that uses grsecurity in binary form, [is] entitled to the complete corresponding source code." Which means their stable patches will get requested and released by someone anyway.
Help me understand how this will have any effect on the actual availability of their stable series?
It basically just adds a level of indirection. Rather than going straight to the grsecurity folks, you now have to go to whichever downstream is disseminating the kernel based on that patch. Bummer.
Really, it's just weakening the brand they've created for themselves. It always sounds really great in theory, but it's almost never worth it. It's the GPL, they've literally signed up for this type of code (ab)use. I'm not sure why people have trouble understanding this concept.
(Though if they wanted to be really snarky, they'd relicense their code GPLv3 and watch these companies go into complete hysterics.)
Really, it's just weakening the brand they've created for themselves. It always sounds really great in theory, but it's almost never worth it. It's the GPL, they've literally signed up for this type of code (ab)use. I'm not sure why people have trouble understanding this concept.
(Though if they wanted to be really snarky, they'd relicense their code GPLv3 and watch these companies go into complete hysterics.)
The GPLv2 doesn't grant any trademark rights. The only mention of trademarks in the GPLv3 at all is a single clause explicitly allowing the grantor not to license trademark rights.
Licensing code under the terms of the GPL does not constitute signing up for trademark infringement. The article's primary focus was on trademarks, as it should be. Nowhere did the authors claim that this vendor was violating the terms of their code license.
Licensing code under the terms of the GPL does not constitute signing up for trademark infringement. The article's primary focus was on trademarks, as it should be. Nowhere did the authors claim that this vendor was violating the terms of their code license.
actually, yes they did...
"the companies we've identified have actively violated the GPL and even our trademark."
Did you read the announce? https://grsecurity.net/announce.php
"the companies we've identified have actively violated the GPL and even our trademark."
Did you read the announce? https://grsecurity.net/announce.php
But wouldn't they need to follow the Linux license, which is GPL2only?
Code will be available to sponsors and sponsors would be entitled to release it to the public, but presumably they will threaten to cut you from future updates if they did that, otherwise these is no point in raising the paywall. Unless you are willing to burn dozens of shell companies for each update there is no way of stopping them.
Is that actually allowed by the GPL? The text says:
> Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
(emphasis mine) Is it legal to penalize someone for exercising their redistribution rights, or would that count as a de facto restriction?
> Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
(emphasis mine) Is it legal to penalize someone for exercising their redistribution rights, or would that count as a de facto restriction?
> you may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Further restrictions probably aren't introduced if they packaged this the right way i.e. not bind the GPL license with whatever agreement they will come up with. Sponsors will still have the same rights they are now used to, but GPL never speaks obligations on the distributor having to provide updated versions.
Further restrictions probably aren't introduced if they packaged this the right way i.e. not bind the GPL license with whatever agreement they will come up with. Sponsors will still have the same rights they are now used to, but GPL never speaks obligations on the distributor having to provide updated versions.
That'd be the joy of their paralegal auditing team's life for the next year to figure out: does all of the code that they're building into their version of the kernel include the "either version 2 of the License, or (at your option) any later version" clause, such that the resulting binary can be a legal GPLv3 binary? I haven't a clue.
The GRsec people wouldn't care, their patch can be whatever GPLv2-compatible license it wants to be.
The GRsec people wouldn't care, their patch can be whatever GPLv2-compatible license it wants to be.
This helps clear things up for me, thanks.
The sponsors use it (Kernel+Grsecurity), they don't distribute it.
Since they don't distribute it, they also don't distribute the patches.
Since they don't distribute it, they also don't distribute the patches.
That assumes that the sponsors don't distribute operating systems or devices containing them, only services in the cloud (or user-space software).
And even still, they could re-distribute the grsecurity code if they wanted to. But they probably won't bother. So yes this private-patches policy will have a big impact on availability, at least on convenience.
And even still, they could re-distribute the grsecurity code if they wanted to. But they probably won't bother. So yes this private-patches policy will have a big impact on availability, at least on convenience.
Ah, that makes sense. I didn't look into what businesses the sponsors were in.
> We decided that it is unfair to _our sponsors_ that the above mentioned unlawful players can get away with their activity.
How is that unfair to them specifically? The purpose of this is to protect them by raising a paywall for anyone that isn't their 'sponsor'? (tangentially, that's why I prefer BSD/MIT, because people aren't as obsessed with other people doing dirty, nasty things with their free code.)
It's bad enough that these patches aren't integrated into the kernel like they ought to be or that they aren't included into mainline distros and are only ever present on custom built machines, now they are behind paywall as well. Damit, I don't want to move to OpenBSD.
How is that unfair to them specifically? The purpose of this is to protect them by raising a paywall for anyone that isn't their 'sponsor'? (tangentially, that's why I prefer BSD/MIT, because people aren't as obsessed with other people doing dirty, nasty things with their free code.)
It's bad enough that these patches aren't integrated into the kernel like they ought to be or that they aren't included into mainline distros and are only ever present on custom built machines, now they are behind paywall as well. Damit, I don't want to move to OpenBSD.
I think he means that it is unfair because the abusive companies are releasing an insecure and untested version of grsecurity, while using the grsecurity brand name in their advertising. This means that any vulnerabilities discovered will hurt the grsecurity brand, making customers trust it less, and hurting the actual legit sponsors using a real secure version of grsecurity.
It is similar to how any knock-off of a brand could hurt the brand; a crappier version of something that people will now associate with the real brand.
It is similar to how any knock-off of a brand could hurt the brand; a crappier version of something that people will now associate with the real brand.
Grsecurity has been here for a while and I don't think common people know of it at all, they hardly know of what Linux is and half of them run it on their phones. Those who know of it will also understand that running outdated versions on outdated kernels isn't a fault of Grsecurity. Grsecurity isn't really a brand or needs to be defended.
That defence of the "meaning" of the trademark is not up to you to decide, that's for the owners of Grsecurity.
Similarly, Google presents its derivative work as Android, and it exercises its rights vigorously to defend the perception of its marque.
Similarly, Google presents its derivative work as Android, and it exercises its rights vigorously to defend the perception of its marque.
> not up to you to decide
Obviously, I'm just pointing out the fact that there are different groups of users for both products and one group isn't likely to be influenced by how others use the trademarked goods. Android has common people for its clientele, Grsecurity has security professionals that will judge it based on its intrinsic merit and not on what some subsidiary of Intel once did with it. Grsecurity de facto doesn't need to be defended, even if de jure they are entitled to the protection. That's why this is nothing but a money grab, what bothers me though is that they try to package it into something that it is not.
Obviously, I'm just pointing out the fact that there are different groups of users for both products and one group isn't likely to be influenced by how others use the trademarked goods. Android has common people for its clientele, Grsecurity has security professionals that will judge it based on its intrinsic merit and not on what some subsidiary of Intel once did with it. Grsecurity de facto doesn't need to be defended, even if de jure they are entitled to the protection. That's why this is nothing but a money grab, what bothers me though is that they try to package it into something that it is not.
> Damit, I don't want to move to OpenBSD.
Why not? OpenBSD's awesome.
Why not? OpenBSD's awesome.
Because they feel bipolar on security sometimes. On one hand they go to the extremes with auditing and being early adopters of various security technologies but on the other hand they lack in other areas. Until recently they didn't sign binaries because the blessed method was to acquire patches via CVS which were signed. Iso files and their signatures are distributed via http because the blessed method of acquiring the signing key is to acquire and verify it over multiple networks, because PKI can't be trusted even though some of us check that https isn't being signed by a weird CA and companies like Verisign aren't likely to burn their CA business for anyone - so I'm forced to use Tor just to download an iso file complete with updating virtual machines hooked to Tor because who knows which exploits are being pushed from exit nodes... Then there is limited choice of packages and for everything else you are left to community ports and I don't trust randomers maintaining them. In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them, but it isn't prepackaged solution like Ubuntu is.
So true.
We would consider OpenBSD if it ran on AWS and stably supported ZFS. (We use FreeBSD with PF and ZFS.)
"NIH syndrome" resulted in signify rather than using normal, proven tools like GPG which Debian-base distros use for package management.
We would consider OpenBSD if it ran on AWS and stably supported ZFS. (We use FreeBSD with PF and ZFS.)
"NIH syndrome" resulted in signify rather than using normal, proven tools like GPG which Debian-base distros use for package management.
> We would consider OpenBSD if it ran on AWS
It probably could if Amazon wanted to support it. It does already run on Xen (which is what AWS is built on, IIRC).
> "NIH syndrome" resulted in signify rather than using normal, proven tools like GPG
Whoa there, pardner! Let's not be so quick to label every attempt at improving the selection of software in a given category as "NIH syndrome", eh? By that logic, "NIH syndrome" resulted in GnuPG rather than using normal, proven tools like the original PGP :)
GnuPG is great. Don't get me wrong. I use it all the time, even on OpenBSD. GnuPG is also a big program. It has a lot of features, and tends to be very complex. In the context of package signing, most of those features - like encryption, webs of trust, all that jazz - are way overkill; the OpenBSD folks just needed a tool that can apply a digital signature and verify that signature, and signify does that job pretty darn well.
There's also the fact that GnuPG is GPL-licensed, and OpenBSD has a pretty strict policy against including copyleft software. The implications of copyleft might not be important to you or me or the dog next door, but they're very important for the OpenBSD folks.
It probably could if Amazon wanted to support it. It does already run on Xen (which is what AWS is built on, IIRC).
> "NIH syndrome" resulted in signify rather than using normal, proven tools like GPG
Whoa there, pardner! Let's not be so quick to label every attempt at improving the selection of software in a given category as "NIH syndrome", eh? By that logic, "NIH syndrome" resulted in GnuPG rather than using normal, proven tools like the original PGP :)
GnuPG is great. Don't get me wrong. I use it all the time, even on OpenBSD. GnuPG is also a big program. It has a lot of features, and tends to be very complex. In the context of package signing, most of those features - like encryption, webs of trust, all that jazz - are way overkill; the OpenBSD folks just needed a tool that can apply a digital signature and verify that signature, and signify does that job pretty darn well.
There's also the fact that GnuPG is GPL-licensed, and OpenBSD has a pretty strict policy against including copyleft software. The implications of copyleft might not be important to you or me or the dog next door, but they're very important for the OpenBSD folks.
Re: ISO file signatures: the actual "blessed method" involving getting install media is actually to order a CD-ROM set. IIRC, the ISOs don't actually include the SHA256.sig file necessary to verify the installation tarballs; this is only present on the official CD-ROMs.
Re: package signing: yes, this was a strange oversight, and I'm glad they sign their packages now.
> Then there is limited choice of packages
It's not that limited, at least on i386 and AMD64 (other platforms are a bit more limited). Are there particular packages that are missing that you'd prefer to be available?
> and I don't trust randomers maintaining them.
So compile them yourself, with or without ports. OpenBSD ships with GCC, binutils, etc. Besides, I'm pretty sure this is the same situation as with Gentoo, Arch, etc. (and know for a fact that it's the same situation as Slackware's SlackBuilds.org).
> In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them
I run multiple OpenBSD servers. I can personally attest that the effort required to maintain them is minimal.
The only situation where OpenBSD maintenance is less than dead simple is when it comes to upgrading a machine where you don't have console access (such as a server in a remote datacenter), since now you have to do the installer's job yourself. When you do have console access, however, OpenBSD's installer makes it dead-simple to upgrade. Plus, it does so safely; no more total breakages like you'd get in, say, Ubuntu.
I will say, however, that it would be very nice to be able to track the stable branch without having to pretty much build OpenBSD from source. I think there are some folks that maintain stable-following ISOs, but this is really something that could and should be supported as a first-party feature.
> but it isn't prepackaged solution like Ubuntu is.
I'm pretty sure Ubuntu uses AppArmor - not grsecurity - so I'm not really sure how that's relevant in this particular discussion. Unless, of course, you happen to install grsecurity on Ubuntu, at which point I highly doubt OpenBSD not being an Ubuntu-like "prepackaged solution" is really as much of a problem as you make it out to be :)
Regardless, OpenBSD has as of late been progressing toward such a prepackaged solution. Boot the CD-ROM, mash the Enter key a few times (interrupted by entering some usernames and passwords), and you have a complete server operating system ready-to-go; a webserver or mailserver or fileserver or DNS server or timeserver or what have you is just an edit of /etc/rc.conf.local away. Maybe not a prepackaged desktop solution, there are plenty of other operating systems for that.
With that said, I'm not sure if the OpenBSD folks want to be comparable to Ubuntu. Canonical's demonstrated a willingness to compromise security and privacy for the sake of convenience (see: shopping lens), that's (hopefully) not something de Raadt and friends would want to emulate.
> companies like Verisign aren't likely to burn their CA business for anyone
Not voluntarily. You're inherently trusting some random company to be up to snuff on their security.
Re: package signing: yes, this was a strange oversight, and I'm glad they sign their packages now.
> Then there is limited choice of packages
It's not that limited, at least on i386 and AMD64 (other platforms are a bit more limited). Are there particular packages that are missing that you'd prefer to be available?
> and I don't trust randomers maintaining them.
So compile them yourself, with or without ports. OpenBSD ships with GCC, binutils, etc. Besides, I'm pretty sure this is the same situation as with Gentoo, Arch, etc. (and know for a fact that it's the same situation as Slackware's SlackBuilds.org).
> In practice OpenBSD is good only for servers where you are willing to put some effort in maintaining them
I run multiple OpenBSD servers. I can personally attest that the effort required to maintain them is minimal.
The only situation where OpenBSD maintenance is less than dead simple is when it comes to upgrading a machine where you don't have console access (such as a server in a remote datacenter), since now you have to do the installer's job yourself. When you do have console access, however, OpenBSD's installer makes it dead-simple to upgrade. Plus, it does so safely; no more total breakages like you'd get in, say, Ubuntu.
I will say, however, that it would be very nice to be able to track the stable branch without having to pretty much build OpenBSD from source. I think there are some folks that maintain stable-following ISOs, but this is really something that could and should be supported as a first-party feature.
> but it isn't prepackaged solution like Ubuntu is.
I'm pretty sure Ubuntu uses AppArmor - not grsecurity - so I'm not really sure how that's relevant in this particular discussion. Unless, of course, you happen to install grsecurity on Ubuntu, at which point I highly doubt OpenBSD not being an Ubuntu-like "prepackaged solution" is really as much of a problem as you make it out to be :)
Regardless, OpenBSD has as of late been progressing toward such a prepackaged solution. Boot the CD-ROM, mash the Enter key a few times (interrupted by entering some usernames and passwords), and you have a complete server operating system ready-to-go; a webserver or mailserver or fileserver or DNS server or timeserver or what have you is just an edit of /etc/rc.conf.local away. Maybe not a prepackaged desktop solution, there are plenty of other operating systems for that.
With that said, I'm not sure if the OpenBSD folks want to be comparable to Ubuntu. Canonical's demonstrated a willingness to compromise security and privacy for the sake of convenience (see: shopping lens), that's (hopefully) not something de Raadt and friends would want to emulate.
> companies like Verisign aren't likely to burn their CA business for anyone
Not voluntarily. You're inherently trusting some random company to be up to snuff on their security.
> Are there particular packages that are missing that you'd prefer to be available?
octave, mono, etc. The whole reason openports.se exists. It's more an outcome of how small openbsd team is so it's not intrinsically their fault, but nonetheless is something that prevents wider adoption.
> So compile them yourself, with or without ports.
And track upstream for security issues and possibly apply patches to make it work on OpenBSD and whatnot which can easily turn into 30 minute dance each day just to maintain the system. It's fine on a servers where you are paid to administer it, but it's not fine on workstation dekstops.
> the actual "blessed method" involving getting install media is actually to order a CD-ROM set
What glandium said + it's rather anachronistic to expect operating systems to arrive by mail in the age of computers.
> so I'm not really sure how that's relevant in this particular discussion.
Ubuntu has its own (numerous) flaws, but it requires less work to maintain. It was more a remark that if grsecurity becomes unavailable on servers then even if you don't run it on desktop we should start thinking about moving to other platforms out of the principle that if the system can't be hardened then it shouldn't be used.
octave, mono, etc. The whole reason openports.se exists. It's more an outcome of how small openbsd team is so it's not intrinsically their fault, but nonetheless is something that prevents wider adoption.
> So compile them yourself, with or without ports.
And track upstream for security issues and possibly apply patches to make it work on OpenBSD and whatnot which can easily turn into 30 minute dance each day just to maintain the system. It's fine on a servers where you are paid to administer it, but it's not fine on workstation dekstops.
> the actual "blessed method" involving getting install media is actually to order a CD-ROM set
What glandium said + it's rather anachronistic to expect operating systems to arrive by mail in the age of computers.
> so I'm not really sure how that's relevant in this particular discussion.
Ubuntu has its own (numerous) flaws, but it requires less work to maintain. It was more a remark that if grsecurity becomes unavailable on servers then even if you don't run it on desktop we should start thinking about moving to other platforms out of the principle that if the system can't be hardened then it shouldn't be used.
> octave, mono,
Both of these are available as OpenBSD packages (as evidenced by running "pkg_info octave" or "pkg_info mono", assuming you have a $PKG_PATH set). No openports.se required! :)
Both of these are available as OpenBSD packages (as evidenced by running "pkg_info octave" or "pkg_info mono", assuming you have a $PKG_PATH set). No openports.se required! :)
Re: ISO file signatures: the actual "blessed method" involving getting install media is actually to order a CD-ROM set. IIRC, the ISOs don't actually include the SHA256.sig file necessary to verify the installation tarballs; this is only present on the official CD-ROMs.
Because the CD-ROMs can't be intercepted and replaced, right?
Because the CD-ROMs can't be intercepted and replaced, right?
I never said it was a smart philosophy :)
That said, it's arguably easier to intercept and replace a CD-ROM traveling on the Internet than to intercept and replace a CD-ROM traveling in a padded envelope between the UK and wherever you're having it shipped to (though various entities - like U.S. customs - could do so trivially, other entities would have to go through the extra trouble of bribing customs - not impossible, but it's a barrier to entry for quite a few potential attackers). Such an interception also requires good timing, lest you be sitting around somewhere for a few days waiting for the package to arrive at the particular point in the shipping route you're waiting at.
Plus, if I remember right, the physical OpenBSD media is done using a proper CD press. While plenty of people could conceivably access such a press, that's yet another step an attacker would need to take to create a convincing forgery.
Really, though, this just highlights why software distribution is such a difficult thing to pull of securely. The ideal solution would be to drive to Calgary and pay Theo de Raadt to burn you a CD-ROM, but I'm not sure how receptive he is to houseguests :)
That said, it's arguably easier to intercept and replace a CD-ROM traveling on the Internet than to intercept and replace a CD-ROM traveling in a padded envelope between the UK and wherever you're having it shipped to (though various entities - like U.S. customs - could do so trivially, other entities would have to go through the extra trouble of bribing customs - not impossible, but it's a barrier to entry for quite a few potential attackers). Such an interception also requires good timing, lest you be sitting around somewhere for a few days waiting for the package to arrive at the particular point in the shipping route you're waiting at.
Plus, if I remember right, the physical OpenBSD media is done using a proper CD press. While plenty of people could conceivably access such a press, that's yet another step an attacker would need to take to create a convincing forgery.
Really, though, this just highlights why software distribution is such a difficult thing to pull of securely. The ideal solution would be to drive to Calgary and pay Theo de Raadt to burn you a CD-ROM, but I'm not sure how receptive he is to houseguests :)
Maybe for servers. It's completely unusable due to performance problems on my i7-powered thinkpad.
Really? I run it on a PowerBook G4, and while it's sluggish, it's not entirely "unsuable". If a 10-year-old single-core machine can handle OpenBSD, I'd be amazed by even the slightest performance issue on a quad-core, hyperthreaded, modern PC. What's additionally surprising is that this is the case on a Thinkpad, of all things; IIRC, the OpenBSD devs dogfood OpenBSD pretty heavily on Thinkpads due to their FOSS-friendliness.
Does your laptop have an Nvidia GPU, by chance? In my experience, those do tend to have very bad performance on OpenBSD. Intel and AMD/ATI GPUs should work better.
Also, it's worth mentioning that OpenBSD's kernel has a whole slew of debugging and error checking features compiled in by default; compiling a custom kernel without such features can be done, but the docs don't really recommend it, since it becomes excruciatingly difficult to troubleshoot any problems with it.
Does your laptop have an Nvidia GPU, by chance? In my experience, those do tend to have very bad performance on OpenBSD. Intel and AMD/ATI GPUs should work better.
Also, it's worth mentioning that OpenBSD's kernel has a whole slew of debugging and error checking features compiled in by default; compiling a custom kernel without such features can be done, but the docs don't really recommend it, since it becomes excruciatingly difficult to troubleshoot any problems with it.
My laptop has an Intel card, and everything is nominally supported.
You are free to be surprised all you wish: I went back to linux because I was sick of dealing with the system locking up for 5-10 seconds every time I opened, closed, or switched to a new browser tab. Couple that with 1-2 fewer hours' worth of battery life and I found myself very quickly asking what the point of "code correctness" was if the system just doesn't work.
A thoroughly frustrating experience from top to bottom.
You are free to be surprised all you wish: I went back to linux because I was sick of dealing with the system locking up for 5-10 seconds every time I opened, closed, or switched to a new browser tab. Couple that with 1-2 fewer hours' worth of battery life and I found myself very quickly asking what the point of "code correctness" was if the system just doesn't work.
A thoroughly frustrating experience from top to bottom.
Just saying. If you haven't already, I'd definitely send them a bug report and dmesg; that all seems very abnormal.
One risk of using OpenBSD is a lot, but not quite enough, people use it on enough on random hardware and give actionable feedback to make it battle-tested, "Just Work" (TM).
OK, figure out who the involved is. It shouldn't be too hard if you're active in that area.
See this product overview from Wind River, which mentions "grsecurity".[1] (Backup copy: [2]).
[1] http://www.windriver.com/products/product-overviews/PO_LINUX... [2] https://web.archive.org/web/20150403191546/http://www.windri...
[1] http://www.windriver.com/products/product-overviews/PO_LINUX... [2] https://web.archive.org/web/20150403191546/http://www.windri...
I'm going to guess it's the top result from the Google search of the forums for EFI and grsecurity? That or the wind is blowing me the wrong way down the river.
This would be really surprising and disappointing. Wind River used to be a/the major FreeBSD sponsor and is now owned by Intel. Intel of course is heavily invested in the Linux and FOSS community.
Intel's commitment is to specific products and technologies that it has determined are either in great market demand or are checkbox items in support of its other products. The company has no affinity whatsoever to Free Software or Open Source ideals, and most of its products are closed-source and protected with extremely restrictive licenses. This is especially true in the space at issue here; Intel does not make its firmware available under anything resembling Open Source terms. The same applies to its CPU microcode, most of its specifications, and the large body of tooling used by OEMs and embedded developers (much of which is not only closed but Windows-only). Intel is committed to supporting GNU/Linux distributions offered by its partners or as demanded by the market at large, but in general it remains an extremely closed, secretive vendor.
They run the open source technology center (http://01.org). Even if their actual goal is exploitation, why would they even blink at 5 figures a year to sponsor this group vs. giving their lawyers something to do and risking exposure like this?
This is probably the forum post they are talking about:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3713&p=134...
https://forums.grsecurity.net/viewtopic.php?f=3&t=3713&p=134...
What's the indication that the forum user in question there is a Verifone employee? That doesn't seem to be obvious in the forum post.
[deleted]
It's not clear to me that he has any case at all with the trademark. You don't get to dictate how everyone uses your trademark. Some uses are acceptable without permission:
"Usually it is permissible to use another person’s or company’s trademark or service mark when referring to a product or service of that person or company, provided it is clear that the mark is being used truthfully to refer to that specific product or service. It may not be used in a way that might mislead others as to that person’s or company’s affiliation with, sponsorship of or endorsement of your company or its products or services—for example, using a logo instead of simply the word form of the mark, or using the mark more prominently or frequently than necessary." [1]
This appears to be how Wind River is using it.
[1] http://www.inta.org/TrademarkBasics/FactSheets/Pages/Tradema...
"Usually it is permissible to use another person’s or company’s trademark or service mark when referring to a product or service of that person or company, provided it is clear that the mark is being used truthfully to refer to that specific product or service. It may not be used in a way that might mislead others as to that person’s or company’s affiliation with, sponsorship of or endorsement of your company or its products or services—for example, using a logo instead of simply the word form of the mark, or using the mark more prominently or frequently than necessary." [1]
This appears to be how Wind River is using it.
[1] http://www.inta.org/TrademarkBasics/FactSheets/Pages/Tradema...
Wind River isn't using grsecurity. They're using their own variant / port of it and advertising it as grsecurity.
spender just wants them to say they have an "unofficial port of grsecurity" if they're unwilling to pay for it to be done properly (i.e. a well-done port, auditing of code specific to that kernel, backporting of all relevant fixes, etc.).
spender just wants them to say they have an "unofficial port of grsecurity" if they're unwilling to pay for it to be done properly (i.e. a well-done port, auditing of code specific to that kernel, backporting of all relevant fixes, etc.).
I believe the point is that by modifying their code and making use of unsupported versions that they are no longer using the product and therefore lose their right to use the trademark under those rules?
Agreed. I could see this being possible with a pre-existing trademark policy, and an explicitly different trademark for "test quality" code, and being very careful about it all, but otherwise I just don't see it. Trademark is to correctly identify the source of a good, and the source here is identified correctly. If it was creative commons licensed, they would be required to do what they have done.
Not only all that, it seems like this is a bit strange that their complaint is that they called it grsecurity without using a blessed version, so their response is to stop giving out blessed versions publicly. Won't that just encourage more companies to do exactly what they are complaining about?
Not only all that, it seems like this is a bit strange that their complaint is that they called it grsecurity without using a blessed version, so their response is to stop giving out blessed versions publicly. Won't that just encourage more companies to do exactly what they are complaining about?
> Won't that just encourage more companies to do exactly what they are complaining about?
It will become much harder for any company to argue the they are using grsecurity if they are not a sponsor since it is not public disseminated any more.
This should give their lawyers considerable more leverage and the offending company's lawyers are more likely to warn discourage stone walling the grsecurity team since the company will be in a weaker position.
It will become much harder for any company to argue the they are using grsecurity if they are not a sponsor since it is not public disseminated any more.
This should give their lawyers considerable more leverage and the offending company's lawyers are more likely to warn discourage stone walling the grsecurity team since the company will be in a weaker position.
I see. This plus an official trademark policy might help.
That's a shame. :(
Also a shame that it's probably going to be way too expensive to lawyer up something like the Firefox an RedHat style of trademark protection (where forks (or even re-compiles) must use off-label branding). :(
Also a shame that the companies in question can't even be named (and shamed)...
Also a shame that it's probably going to be way too expensive to lawyer up something like the Firefox an RedHat style of trademark protection (where forks (or even re-compiles) must use off-label branding). :(
Also a shame that the companies in question can't even be named (and shamed)...
Veriphone
https://forums.grsecurity.net/viewtopic.php?f=3&t=3938&p=139...
There, shamed. Easy.
There, shamed. Easy.
There are a lot of people complaining about a future w/o grsecurity and I share your feelings. However I was surprised to see that nobody has mentioned that you and I can also donate to the project.
Yes, it sucks that MegaCorp and InnoTrode are not compensating Grsecurity for the work. Its probably just as shitty that I have used grsecurity for as long as I have and just got around to donating to the project. If you use grsecurity and don't want to see it disappear go donate. Grsecurity accepts paypal/bitcoin/dwolla:
https://grsecurity.net/contribute.php
Yes, it sucks that MegaCorp and InnoTrode are not compensating Grsecurity for the work. Its probably just as shitty that I have used grsecurity for as long as I have and just got around to donating to the project. If you use grsecurity and don't want to see it disappear go donate. Grsecurity accepts paypal/bitcoin/dwolla:
https://grsecurity.net/contribute.php
Naive question: can't EFF help?
Linus should've helped. But they don't want to merge patches to the kernel. Use OpenBSD.
> But they don't want to merge patches to the kernel.
To be clear, the 'they' in that sentence are the authors of GRSecurity, not the kernel developers.
To be clear, the 'they' in that sentence are the authors of GRSecurity, not the kernel developers.
Are you sure about that?
From what I heard Torvalds refuses to merge patches from folks who won't identify themselves[0], and the PaX Team refuses to reveal the membership of the team.
[0] This is a perfectly reasonable policy.
From what I heard Torvalds refuses to merge patches from folks who won't identify themselves[0], and the PaX Team refuses to reveal the membership of the team.
[0] This is a perfectly reasonable policy.
The problem is they're both right.
Pardon me, I'm confused. Who is "they" in your statement? Is it the mass "you"? Is it referring to my statement and mburns's statement? If it is, then can you provide a first-hand citation that supports mburns's statement?
AIUI, the GRSec folks don't gain anything by keeping their patches out of tree. If they could merge them in, they should.
AIUI, the GRSec folks don't gain anything by keeping their patches out of tree. If they could merge them in, they should.
GRSecurity devs have actively avoided submitting the patches into mainline. http://unix.stackexchange.com/questions/59020/why-are-the-gr...
Someone should really break up the patchset and submit it upstream as discrete features.
Someone should really break up the patchset and submit it upstream as discrete features.
[deleted]
If you can't get the PaX Team to attribute their code to a meatsack, (or -I guess- get someone to vouch for it), then this will be a non-starter. Grsec is pretty much useless without PaX.
To be frank, the grsecurity folks and Brad in particular aren't exactly nice to others or trying the get stuff merged in the right way, so they don't get a lot of support from the kernel folks.
Most of the time Brad is shaming kernel devs and saying they're all idiots.
Most of the time Brad is shaming kernel devs and saying they're all idiots.
<devil's advocate> The existence of his project/business and specifically the fact that other eople not only use but rip off his wrok - seem to strongly provide evidence that supports his "they're all idiots" theory...
(To be fair, "all" is clearly an exaggeration, but enough kernel devs are clearly writing security bugs into the kernel source tree to require an external "adult supervision" project to improve the security focus...)
(To be fair, "all" is clearly an exaggeration, but enough kernel devs are clearly writing security bugs into the kernel source tree to require an external "adult supervision" project to improve the security focus...)
The impasse seems to be that the kernel isn't going to roll over on all their other kernel development concerns when someone waves the "security" trump card. As much as I'm into making sure people understand the importance of security and often am the guy fighting for better security in my professional capacity, I can't fault the kernel. That kind of arrogance not only doesn't work, but makes my job harder when I encounter IT and developers that have been bitten by terrible interactions with "the security community" in the past.
> To be frank, the grsecurity folks and Brad in particular aren't exactly nice to others or trying the get stuff merged in the right way, so they don't get a lot of support from the kernel folks.
Linus "I am not a nice person, deal with it" Torvalds is upset because someone else is a ranty meany about him? Heaven forbid!
Linus "I am not a nice person, deal with it" Torvalds is upset because someone else is a ranty meany about him? Heaven forbid!
Brad doesn't throw personal attacks and insults around like Linus anyway. Plain spoken criticism of actions and ideas is not a personal attack. He tends to strongly disagree with the upstream kernel developers on issues related to security and what pisses them off is that his criticism is fair and accurate. They should be embarrassed about the state of security (and stability...) in vanilla, and they get offended when it's pointed out.
Brad doesn't throw personal attacks and insults around like Linus anyway. Plain spoken criticism of actions and ideas is not a personal attack.
Quoted below: Plainly spoken criticism of action and ideas
Quoted below: Plainly spoken criticism of action and ideas
The real question the news articles should be asking is why the embedded
industry as a whole is scum and why everyone has problems w/ them
Do you have any examples? I'd be curious to read the discussions - in particular, legitimate criticism that was ignored.
[deleted]
I want to add something. I am sure that it will get obliterated by other people. I am not with anyone that uses grsecurity.
On the one hand I can imagine nothing more bitter than other people making money on your hard work.
However, isnt this how the whole thing goes? I mean there wouldn't be a linux kernel without the work of a whole bunch of companies. Did they get sponsorship money from you? grsecurity wouldn't exist without the work of a bunch of other people. Did grsecurity pass on money to other vendors that they rely on? What about people that wrote the drivers that grsecurity use when they did development.
Open source only works because people contribute to a shared base. In return for their contributions they get to use what others already contributed.
On the one hand I can imagine nothing more bitter than other people making money on your hard work.
However, isnt this how the whole thing goes? I mean there wouldn't be a linux kernel without the work of a whole bunch of companies. Did they get sponsorship money from you? grsecurity wouldn't exist without the work of a bunch of other people. Did grsecurity pass on money to other vendors that they rely on? What about people that wrote the drivers that grsecurity use when they did development.
Open source only works because people contribute to a shared base. In return for their contributions they get to use what others already contributed.
It seems like you've missed the point. The problem isn't that companies are using the work without paying. The problem is that the unnamed companies are essentially lying in their marketing and violating the grsec trademark in the process.
This is not how FLOSS is supposed to go.
This is not how FLOSS is supposed to go.
Why do you think they are lying? Did the companies use not apply the grsecurity patches but claim they did?
If they did apply the patches AND used the grsecurity trademark in their brochures what is the problem? They arent misrepresenting grsecurity. They arent being derogatory in any way. Why can't you say that you have the kernel and you applied grsecurity patches?
It seems so funny when people are all about GPL code and "freedom" and yet act so precious about a "trademark" just like proprietary enterprises.
If they did apply the patches AND used the grsecurity trademark in their brochures what is the problem? They arent misrepresenting grsecurity. They arent being derogatory in any way. Why can't you say that you have the kernel and you applied grsecurity patches?
It seems so funny when people are all about GPL code and "freedom" and yet act so precious about a "trademark" just like proprietary enterprises.
The whole point of trademark law is that the owner of the trademark gets to control how it's used in commerce. If the mark is being used to advertise a company's product, grsecurity has the right to prohibit it; the company doesn't get to make the call.
This isn't a free-speech issue -- it's just a simple acknowledgement of the fact that consumers treat names, logos, branding etc. as indicators of a product's origin, and that there's a public interest in making those indicators accurate. You can refer to the trademark as long as you don't do so in a way that misrepresents your product. In this case, unless there are specific disclaimers to the contrary, a reasonable person would think "grsecurity" means "code released and approved by the grsecurity team", instead of a version that a third party has modified.
This isn't a free-speech issue -- it's just a simple acknowledgement of the fact that consumers treat names, logos, branding etc. as indicators of a product's origin, and that there's a public interest in making those indicators accurate. You can refer to the trademark as long as you don't do so in a way that misrepresents your product. In this case, unless there are specific disclaimers to the contrary, a reasonable person would think "grsecurity" means "code released and approved by the grsecurity team", instead of a version that a third party has modified.
From the post: "The aforementioned company has been using the grsecurity name all over its marketing material and blog posts to describe their backported, unsupported, unmaintained version in a version of Linux with other code modifications that haven't been evaluated by us for security impact. Simply put, it is NOT grsecurity"
There _are_ no "grsecurity patches" to apply for the system they're using the grsecurity trademark on.
Seems pretty clear cut from here.
There _are_ no "grsecurity patches" to apply for the system they're using the grsecurity trademark on.
Seems pretty clear cut from here.
Can we as a society stop ripping off open source developers?
Companies that do are essentially stealing from artisans to build infrastructure to defraud the poor so they can horde wealth.
Companies that do are essentially stealing from artisans to build infrastructure to defraud the poor so they can horde wealth.
Actual GPL violations are bad. If actual trademark infringement happened (the blog post presents the company's counterarguement as to whether or not that happened, and I neither know enough about the law to assess the competing claims or know enough about the situation to know whether or not the blogpost fairly represented the counterarguement), that's bad.
But "[not] bother[ing] to hire us to perform the port properly for them or to actively maintain the security of the kernel they're providing to their paid customers" isn't ripping off the developers or stealing from artisans. Nor is "not contribut[ing] a single dime toward our continued development and maintenance." None of those things are required by the GPL. If you want to sell software, and if you want to get pissed when people use your software without paying you for it, choose a license that requires people to pay you for your software.
(And exactly how much money has GRsecurity paid to the developers of the kernel they're patching? The unmitigated gall factor here is stronger than most of these kinds of rants that I've seen, because they're not even the upstream.)
But "[not] bother[ing] to hire us to perform the port properly for them or to actively maintain the security of the kernel they're providing to their paid customers" isn't ripping off the developers or stealing from artisans. Nor is "not contribut[ing] a single dime toward our continued development and maintenance." None of those things are required by the GPL. If you want to sell software, and if you want to get pissed when people use your software without paying you for it, choose a license that requires people to pay you for your software.
(And exactly how much money has GRsecurity paid to the developers of the kernel they're patching? The unmitigated gall factor here is stronger than most of these kinds of rants that I've seen, because they're not even the upstream.)
The grsecurity brand is a registered trademark and spender has the right to control how it's used. If you ship a product with the official grsecurity patch applied, you get to say it uses a grsecurity kernel in your marketing. If you want to use anything but the latest official/test kernels, then you need to make it clear that it's not grsecurity (but rather your port) or pay official support with all of the backporting, auditing and testing that entails.
I'm working on an open-source product using my own port of PaX/grsecurity (as it needs to target an unsupported kernel) and I had no problem understanding and complying with spender's wishes about this.
These companies have to respect the GPL license, so they need to provide the users with the source code for their kernels.
> And exactly how much money has GRsecurity paid to the developers of the kernel they're patching? The unmitigated gall factor here is stronger than most of these kinds of rants that I've seen, because they're not even the upstream.
The grsecurity project respects the upstream trademark and licensing. In this case, they are one of the upstreams... they're not complaining about kernels not using their substantial amount of code.
I'm working on an open-source product using my own port of PaX/grsecurity (as it needs to target an unsupported kernel) and I had no problem understanding and complying with spender's wishes about this.
These companies have to respect the GPL license, so they need to provide the users with the source code for their kernels.
> And exactly how much money has GRsecurity paid to the developers of the kernel they're patching? The unmitigated gall factor here is stronger than most of these kinds of rants that I've seen, because they're not even the upstream.
The grsecurity project respects the upstream trademark and licensing. In this case, they are one of the upstreams... they're not complaining about kernels not using their substantial amount of code.
> And exactly how much money has GRsecurity paid to the developers of the kernel they're patching?
They've donated a lot more mockery than money, I would think.
It's a good point.
They've donated a lot more mockery than money, I would think.
It's a good point.
The Linux kernel wouldn't have features like ASLR, protected_{hardlinks,symlinks}, dmesg_restrict, kptr_restrict, ptrace_scope and lots more if not for PaX/grsecurity.
The fact that pipacs and spender no longer spend their time pushing stuff upstream doesn't mean that upstream doesn't benefit in a huge way from grsecurity via others like Kees Cook who are willing to deal with the politics.
grsecurity doesn't violate the Linux trademark or licensing. It's not a good point at all. You wonder why they don't contribute upstream directly? It has a lot to do with this entitled attitude.
The fact that pipacs and spender no longer spend their time pushing stuff upstream doesn't mean that upstream doesn't benefit in a huge way from grsecurity via others like Kees Cook who are willing to deal with the politics.
grsecurity doesn't violate the Linux trademark or licensing. It's not a good point at all. You wonder why they don't contribute upstream directly? It has a lot to do with this entitled attitude.
Yeah, we just have to find their project page, hope they have a PayPal or Stripe or other donation link (that accepts a currency we already have, sorry I own no Bitcoin)...
And then donate.
For every developer or project. I don't know about most of the engineers whose work powers my internet use. How do I donate to people I don't know about?
And then donate.
For every developer or project. I don't know about most of the engineers whose work powers my internet use. How do I donate to people I don't know about?
The grsecurity brand is a registered trademark and spender has the right to control how it's used. If you ship a product with the official grsecurity patch applied, you get to say it uses a grsecurity kernel in your marketing. If you want to use anything but the latest official/test kernels, then you need to make it clear that it's not grsecurity (but rather your port) or pay official support with all of the backporting, auditing and testing that entails.
I'm working on a product using my own port of PaX/grsecurity and I had no problem understanding and complying with spender's wishes about this.
I'm working on a product using my own port of PaX/grsecurity and I had no problem understanding and complying with spender's wishes about this.
I think this was a dupe.
Here's the forum post on backporting an EFI fix:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3713
And products with Wind River Linux prominently mentions GRSecurity advertisements:
https://www.google.com/search?q=wind+river+linux+grsecurity
Edit: It looks like I wasn't the only one to find this. I'll keep this post at the top for other people to reply to.