All of lore.kernel.org
 help / color / mirror / Atom feed
From: linuxgpletc@redchan.it
To: Ivan Ivanov <qmastery16@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	freebsd-chat@freebsd.org, misc@openbsd.org,
	gentoo-user@lists.gentoo.org, rms@gnu.org, esr@thyrsus.com
Subject: Re: GRSec is vital to Linux security
Date: Wed, 23 Jan 2019 22:28:45 +0000	[thread overview]
Message-ID: <28315c204184b212a3a60cdd393c3fd3@redchan.it> (raw)
In-Reply-To: <CAAaskFDMjUzonLeHPmiy_VcB=jvQfF9giEaWcmNLKHDTqQt4BA@mail.gmail.com>

On 2019-01-23 20:46, Ivan Ivanov wrote:
> Interesting point of view. Well, to be honest it seems to me that
> Linux kernel sacrifices the security for the sake of progress, so it
> is quite bloated at the moment and I am not sure that even GRSecurity
> could fix it. Linux really needs to stop adding new features and
> refactor itself to a smaller and more secure codebase before going
> forward. Maybe 1 year break would be nice.

This man speaks the truth. The constant flux reintroduces long-fixed 
bugs, like a constant inflowing tide. The code can never be stabilized 
due to the endless needless work of the worker-bee wage-slaves. Thus the 
code always has new hidden security errors.

GRSecurity can barely keep up.

A "feature" of the wage-slave era of Linux, that we did not have in the 
Hacker era of Linux (the people targeted by the CoC, who actually 
created the land where the wage-slave code churners now graze)

"Free" workers from for-profit and government connected enterprises do 
not come with no-strings-attached, and the enterprises are not stupid: 
they refactor to get their way if an initial strategy isn't working.

The only real flux of any significant magnitude that should occur is 
with the addition of new drivers. Instead code is ripped out and 
replaced everywhere for little to no real gain.

That being said... GRSecurity's GPL violation is the most blatant 
upfront violation of the GPL I've ever seen (they put it in writing and 
don't try to hide it (you redistribute, we punish you)).

They also do not deal with small businesses or people who would like to 
purchase a "license" from them. Only large businesses and government 
contracts.

They're afraid that a small company would pay for 1 server "license" and 
then release the code, I think.

Some people wonder why hasn't anyone penetrated their Download server 
and stolen the code back and released it?

Maybe because GRSecurity knows what they're doing. If it were hosted on 
a vanilla linux server, it would be out by now.

Remember: it's been well over a year. Not one leak of the code, not one 
penetration, nothing. They know how to secure a linux machine. Linus 
does not. He just allows endless useless flux, barely manages the 
project, places it all in the hands of the wage-slaves (who simply do 
their job for their company, not for the betterment of the thing (no 
passion)) and ousts the old Hackers who built the thing with Linus from 
the ground up originally.

Legal action could be taken to stop GrSecurity's blatant violation; one 
could atleast sue for the profits. It is a non-seperable work, they are 
violating the "no additional restrictions" rule, in writing. They 
violated the copyright - it's as simple as that in the end.

No one does a thing. Ofcourse the wage-slaves do not: they don't own 
their own code and don't have agency even over their own lives anyway. 
Their bosses could do something though, the companies that own the 
wage-slave's code. The Hackers, who's code still resides in the linux 
kernel AND/OR who's code was a predecessor of current code (even if it 
is not the same as their original code) also have standing.

Nothing is done. It's as if the GPL is just worthless trash. It has not 
stopped GRSecurity from closing their derivative work of the kernel and 
threatening anyone who would redistribute the non-separable derivative 
work. They just laugh at Linus, the Hackers, and especially the 
wage-slaves.

Didn't someone once say "Linux will be free forever" (hint: Lawrence 
Rosen). A piece of Linux isn't now... It hasn't panned out in reality.



  reply	other threads:[~2019-01-23 22:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 18:19 GRSec is vital to Linux security linuxgpletc
2019-01-23 20:46 ` Ivan Ivanov
2019-01-23 22:28   ` linuxgpletc [this message]
2019-01-24 15:31   ` Enrico Weigelt, metux IT consult
2019-01-24 16:03     ` Adam Borowski
2019-01-24 16:22     ` linuxgpletc
2019-01-24 16:31     ` GRSec is vital to Linux security -- SFConservancy = legal malpractice. Use own lawyer linuxgpletc
2019-01-24 16:40     ` Fwd: Re: GRSec is vital to Linux security linuxgpletc
2019-01-28 20:20   ` Author of GPC-Slots2 promises to sue "John Doe" who violated GPL recission linuxgpletc
2019-01-29  8:51   ` linuxgpletc
2019-01-29  9:10   ` Author of GPC-Slots2 promises to sue "John Doe" who violated GPL recission. (update) linuxgpletc
2019-01-29  9:38   ` Author of GPC-Slots2 promises to sue "John Doe" who violated GPL recission. (update 3) linuxgpletc
2019-01-24 16:53 GRSec is vital to Linux security linuxgpletc
2019-01-24 20:18 ` Boris Lukashev
2019-01-25 16:34   ` linuxgpletc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=28315c204184b212a3a60cdd393c3fd3@redchan.it \
    --to=linuxgpletc@redchan.it \
    --cc=esr@thyrsus.com \
    --cc=freebsd-chat@freebsd.org \
    --cc=gentoo-user@lists.gentoo.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=misc@openbsd.org \
    --cc=qmastery16@gmail.com \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.