Live data from Hacker News

Grsecurity: Potential contributory infringement and breach of contract risk

perens.com

121–128 of 128 posts

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#121
I think it is unfair to attack the grsecurity guys like this. They've been providing their patches free of charge for years only to have their work abused.

I mean, this whole situation seems a lot like the one described in the following articles, and afaik RedHat is still not facing any lawsuits: https://lwn.net/Articles/432012/ http://www.theregister.co.uk/2011/03/04/red_hat_twarts_oracl...

Now RedHat has the benefit that they claim they're "upstream first", but afaik ASLR originated with the grsecurity guys, so there is grsecurity stuff in the vanilla kernel. Is ASLR snake oil?

I don't see how the situation is different between how grsecurity did things and RedHat. Between going out of business and working on the boundary of the GPL, they chose to stay in business.

More importantly, how would you deal with publishing under the GPL and making money off of it? This whole discussion reminds me of this article: http://widgetsandshit.com/teddziuba/2010/01/i-love-the-gpl-e...

The way things are going, the best direction to take if you want to produce GPL code is to have another job unrelated to programming to earn enough to code in your free time. It's really sad if you think of the megacorps that are making billions off of FOSS.

I'll end up with a quote by Steve Jobs: By the way, what have you done that’s so great? Do you create anything, or just criticize others work and belittle their motivations? http://widgetsandshit.com/teddziuba/2010/05/the-future-of-ap...

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#122
post #107

Earlier quoted context omitted.

Care to refute? We've got quotes from Linus himself in this thread that show a belief that their products do not provide value. I'd say that while Linus is generally inflammatory, he's also generally correct. I don't know that what SwellJoe has said is any worse. Do you believe Linus should retract and apologize as well? This request is genuine - you're a well respected voice in the security world, and I'd be curious…

I think you're missing the point here. It's not helped by the way Linus has expressed himself here. The truth is that there's a fundamental philosophical disagreement here: Linus prioritises not breaking userland, GR security doesn't. Their patches are "crap" because they're large and not in the correct style, not because they don't achieve what they set out to do. Sometimes people take subsets of those patches, clea…

I think if we get into the technical side, there's a lot of question too.

It doesn't seem like they are very good at code review or testing, for example:

https://twitter.com/marcan42/status/724745886794833920?lang=...

And when called out on this, they simply block the people saying it.

I'd personally be very skeptical of any security company that values their own tolerance for dealing with people telling them their code sucks over finding out that their code sucks and fixing it. And a lack of good code review and testing is of huge import when it comes to security, at least in my opinion.

Then there's also their weird crusade against (e)BPF without any supporting evidence beyond "It adds more features so that's more attack surface and thus shouldn't ever be added or attempted and we don't believe anyone involved could ever make it secure so there."

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#123

Earlier quoted context omitted.

Sorry, I am still not sure what you mean. Could you point me at an example of 'patch metadata'? Thanks!

Here is an example of patch metadata, in this case for Debian: https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian... "Without patch metadata" would be a single file patch.

Thanks!

A CentOS 6 kernel source rpm that I unpacked recently had multiple patch files in it.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#124
post #106

Earlier quoted context omitted.

Care to refute? We've got quotes from Linus himself in this thread that show a belief that their products do not provide value. I'd say that while Linus is generally inflammatory, he's also generally correct. I don't know that what SwellJoe has said is any worse. Do you believe Linus should retract and apologize as well? This request is genuine - you're a well respected voice in the security world, and I'd be curious…

> We've got quotes from Linus himself in this thread that show a belief that their products do not provide value. All I see is a link to some message where Linus calls these patches pure garbage. There's very little context, and the only borderline technical issue he points out is that grsecurity breaks things. If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with…

>If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with Linus' values.

The thread is actually someone asking if it's worth taking a look at how grsecurity handles a large stack guard gap to get ideas for implementation in the kernel. Linus then responds saying to not bother with them.

It's a pretty clear condemnation of them in general, not just their shitty patch submission process.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#125

Earlier quoted context omitted.

You'd know better than I would, though I'm not inclined to apologize. I will use more mildly negative language henceforth, however. My problems with Grsecurity are, in order of importance: - This whole licensing thing. I like the GPL. I publish much of my software under the GPL. I want the GPL to be a real thing that we all respect and abide by. When someone breaks that social contract, we all lose. - The lack of eff…

I don't expect or ask you to praise it, but in software security, "snake oil" has a particular meaning that absolutely does not apply to Grsecurity. Grsecurity might not be appropriate for the kinds of systems you deploy --- or, even, in your professional judgement, for any production system! But "snake oil" refers to security products that don't do anything, and that are built in bad faith to bilk users out of their…

I should probably just refrain from participating in esoteric security topics from now on; it's above my pay grade. I'll stick to complaining about their licensing.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#126

LOL. Please, just bow out on topics related to security. You are spreading misinformation.

Personal attacks will get you banned on HN. Surely you know that? Please don't do this again.

We detached this comment from https://news.ycombinator.com/item?id=14732721 and marked it off-topic.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#128
post #83
post #76

Earlier quoted context omitted.

But that's not what they're saying. If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL. What they will do is terminate your contract and you will not receive further updates. There GPL does not mandate that you receive updates to anything. All it says is is that no restrictions can be applied on the source code that you have received.

>But that's not what they're saying. Let's back up for a moment just to make sure we're talking about the same "they." "They" being the author of this article, absolutely said almost verbatim what I claimed they said. My post: "It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code" The article: "This is tantamount to the addition of…

The word "they" in my previous post was referring to grsec.
Post reply on HN