Linux Kernel Summit discussions
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Jiri Kosina <jikos@kernel.org>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@
Date: Wed, 16 Aug 2023 16:55:39 +0200	[thread overview]
Message-ID: <2023081641-unstitch-kangaroo-a2c1@gregkh> (raw)
In-Reply-To: <20230815183120.0c92a759@gandalf.local.home>

On Tue, Aug 15, 2023 at 06:31:20PM -0400, Steven Rostedt wrote:
> On Wed, 16 Aug 2023 00:13:56 +0200 (CEST)
> Jiri Kosina <jikos@kernel.org> wrote:
> 
> > > The huge majority of Linux use in the world is Android, everything else
> > > is a rounding error.   
> > 
> > Sorry, but in my view this is a slight oversimplification.
> 
> I agree. And that's just taking in "numbers". What about impact. If there's
> a security flaw in an android phone, it opens up each individual for an
> attack, but it usually requires an attacker to hit them individually.
> 
> But if an enterprise is hit. All it takes is to go after one server, and
> you have access to thousands of users and their private data.
> 
> It's not just the number of installations that count.

Very true, but as an individual, we regard the private data in our
phones usually more important than the data stored in corporate systems :)

Anyway, my whole point here is that there are huge swaths of users of
Linux, the majority in quantity (not judging quality), that are now
doing the right thing here by taking all known fixes into their kernel
trees.  It's only a small (in absolute numbers, not importance, I'm not
judging importance as everyone is more important than everyone else,
like always), number that are not doing this and asking for us to give
them access to a tiny feed of fixes instead so that they can have a
false sense of security.

Please, let's work on fixing that false sense of security.  It's wrong,
and our users deserve better as we (the community) ARE doing all of the
fixing the best we can, but not all of our users seem to be able to take
advantage of this due to the "policy decisions" of others outside of our
community.

And note, those "policy decisions of companies" are now known by
governments to be incorrect, and soon will be made illegal in many
countries, so we are on the right side here.

Together we were able to solve the "impossible" problem of Android
kernel security.  Now that that windmill is semi-successfully conquered
despite many who thought it never could be, why can't we help other
users of our product to do the same?  If not, we run the risk of having
Linux be blamed for bad security, when in reality, it's the policy of
companies not taking advantage of what we are providing them, a nuance
that Linux users will never really understand, nor should they have to.

Let's fix this properly please, access to the security@k.o reports will
do nothing to solve the root issue, and only paper it over for a few
more years.

thanks,

greg k-h

  reply	other threads:[~2023-08-16 14:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15  9:28 [MAINTAINERS SUMMIT] Handling of embargoed security issues -- security@korg vs. linux-distros@ Jiri Kosina
2023-08-15 10:17 ` Vegard Nossum
2023-08-15 10:34   ` Jiri Kosina
2023-08-15 11:23   ` Greg KH
2023-08-15 12:42     ` Steven Rostedt
2023-08-15 13:17       ` Daniel Borkmann
2023-08-15 14:19         ` Laurent Pinchart
2023-08-15 22:04         ` Jiri Kosina
2023-08-15 14:20       ` Catalin Marinas
2023-08-15 14:41         ` Greg KH
2023-08-15 15:04           ` Steven Rostedt
2023-08-15 15:51             ` Greg KH
2023-08-15 15:08       ` Greg KH
2023-08-15 18:46         ` Konrad Rzeszutek Wilk
2023-08-15 19:41           ` Greg KH
2023-08-15 22:13         ` Jiri Kosina
2023-08-15 22:31           ` Steven Rostedt
2023-08-16 14:55             ` Greg KH [this message]
2024-02-16 17:14               ` Michal Suchánek
2024-02-16 17:34                 ` Greg KH
2024-02-16 18:13                   ` Michal Suchánek
2024-02-16 18:16                     ` Jiri Kosina
2023-08-15 22:17         ` Jiri Kosina
2023-08-16 14:57           ` Greg KH
2023-08-16 17:22             ` Jiri Kosina
2023-08-16 18:38           ` Vegard Nossum
2023-08-16 15:26   ` Solar Designer
2023-08-25 11:17     ` Donald Buczek
2023-08-29  8:46       ` Miroslav Benes

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=2023081641-unstitch-kangaroo-a2c1@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=jikos@kernel.org \
    --cc=ksummit@lists.linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=vegard.nossum@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).