ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues
Date: Mon, 10 Sep 2018 16:26:53 -0700	[thread overview]
Message-ID: <20180910232652.GC1764@localhost.localdomain> (raw)
In-Reply-To: <CAMuHMdVqhOq11fxOf7RUXEq+oT5A2gGKSVx=FadtiVz23AywHA@mail.gmail.com>

Hello Geert,

On Fri, Sep 07, 2018 at 10:21:15AM +0200, Geert Uytterhoeven wrote:
> Hi Eduardo,
> 
> On Fri, Sep 7, 2018 at 12:55 AM Eduardo Valentin <edubezval@gmail.com> wrote:
> > On Thu, Sep 06, 2018 at 09:18:07PM +0200, Jiri Kosina wrote:
> > Honestly, the fact that somehow the community managed to make this to
> > stable (and eventually to distros) is really good. Imagine for a second
> > a world in which these made only mainline and no stable branch..
> 
> It could have been the disaster needed to trigger a paradigm shift in the
> software industry?

Well yeah. Just to clarify, what I meant is that the community did a
really great job handling the event, despite the fact that we could have
dont better. But I still think pushing everyone to make sure they can
move to newer kernels is best thing to do. How achieve it is that is a
different discussion.

> 
> For a fully isolated/controlled system old stable may make sense, but in
> the post-Internet connected world, where the whole world population can
> peek at your front door, you'd better be prepared to upgrade any time.

Well yeah, I would do the same. But then there is thing called vendor
trees. That makes developers life even more horrible. As you hear in
this thread, even top noch developer would avoid backporting stuff to
too old kernels, and latest LTS is probably the oldest one can trust.
But vendor trees, which is the stuff that really ends up running on
those cameras running Linux at your front door, are usually old and
have bunch of code that community is not aware (and really should not be). 
And backporting stuff to those kernels is even a worse nighmare than
backporting to older stables.

> Despite backporting, you'll always be vulnerable to some security issues
> that were fixed in mainline.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

  reply	other threads:[~2018-09-10 23:26 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 19:18 Jiri Kosina
2018-09-06 20:56 ` Linus Torvalds
2018-09-06 21:14   ` Jiri Kosina
2018-09-06 22:51     ` Eduardo Valentin
2018-09-07  9:17   ` Jani Nikula
2018-09-07 14:43   ` David Woodhouse
2018-09-06 22:55 ` Eduardo Valentin
2018-09-07  8:21   ` Geert Uytterhoeven
2018-09-10 23:26     ` Eduardo Valentin [this message]
2018-09-11  8:45       ` Greg KH
2018-09-11 17:10         ` Dave Hansen
2018-09-11 18:28           ` Greg KH
2018-09-11 18:44           ` Thomas Gleixner
2018-09-07 13:30   ` Jiri Kosina
2018-09-09 12:55     ` Greg KH
2018-09-09 19:48       ` Jiri Kosina
2018-09-10  4:04         ` Eduardo Valentin
2018-09-12  7:03           ` Greg KH
2018-09-10  4:12       ` Eduardo Valentin
2018-09-10 11:10       ` Mark Brown
2018-09-12  4:22   ` Balbir Singh
2018-09-08  4:21 ` Andy Lutomirski
2018-09-08  8:56   ` Thomas Gleixner
2018-09-08 11:21     ` Mauro Carvalho Chehab
2018-09-08 11:34       ` Greg KH
2018-09-08 14:20         ` Andy Lutomirski
2018-09-08 15:29           ` Greg KH
2018-09-08 15:00         ` James Bottomley
2018-09-08 15:32           ` Greg KH
2018-09-08 15:54             ` James Bottomley
2018-09-08 19:49               ` Linus Torvalds
2018-09-08 21:24                 ` James Bottomley
2018-09-08 22:33                   ` Andy Lutomirski
2018-09-09 12:18                     ` Mauro Carvalho Chehab
2018-09-10 22:59                 ` Dave Hansen
2018-09-11  8:48                   ` Greg KH
2018-09-09 12:51               ` Greg KH
2018-09-09 14:20                 ` Linus Torvalds
2018-09-09 14:38                   ` James Bottomley
2018-09-09 14:51                     ` Andy Lutomirski
2018-09-09 17:20                       ` Theodore Y. Ts'o
2018-09-09 17:48                         ` David Woodhouse
2018-09-09 18:17                         ` Andy Lutomirski
2018-09-09 18:56                           ` Theodore Y. Ts'o
2018-09-09 19:19                             ` Andy Lutomirski
2018-09-09 20:20                             ` Jiri Kosina
2018-09-09 21:36                               ` James Bottomley
2018-09-10  9:25                             ` Thomas Gleixner
2018-09-10 14:40                               ` James Bottomley
2018-09-11  8:20                               ` Jiri Kosina
2018-09-11  9:03                                 ` Thomas Gleixner
2018-09-09 19:41                   ` Jiri Kosina
2018-09-08 19:26           ` Jiri Kosina
2018-09-08 19:47             ` James Bottomley

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=20180910232652.GC1764@localhost.localdomain \
    --to=edubezval@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=ksummit-discuss@lists.linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox