public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Vanilla sources
Date: Sat, 4 Jan 2020 06:01:30 -0500	[thread overview]
Message-ID: <CAGfcS_=KzxrAWDasd-h4w+dXsUshtTCgNtEJsybaP1WKHz_yLA@mail.gmail.com> (raw)
In-Reply-To: <1D58FC4F-EBE7-470C-BB59-6BA54314F740@gentoo.org>

On Fri, Jan 3, 2020 at 11:28 AM Aaron Bauman <bman@gentoo.org> wrote:
> On January 3, 2020 9:55:31 AM EST, Michael Orlitzky <mjo@gentoo.org> wrote:
> >On 1/3/20 9:52 AM, Michael Orlitzky wrote:
> >>
> >> But here we are. Do we make OpenRC Linux-only and steal the fix from
> >> systemd? Or pretend to support other operating systems, but leave
> >them
> >> insecure?
> >>
> >
> >Or the gripping hand: rewrite opentmpfiles in C, so that it's only as
> >insecure as checkpath.
> >
> >Every option sucks. I was only trying to point out that vanilla-sources
> >gets no security support -- security@ has stated this, but it's on a
> >private bug, so I won't quote it -- and the risk is more than academic.
>
> This should be known. Security does not support vanilla-sources. This is one reason vanilla-sources are not stabilized.
>

Packages without security support should be masked.  Really I don't
see the point of even having this in the repo.

I run vanilla sources personally but I just get them from upstream.
Makes way more sense than worrying about whether the version in the
repo is up to date for the longterm kernel I'm following.  People
running vanilla sources are probably using out-of-tree modules (like
me) and as such are going to have particular requirements around how
they're updated.  So, Gentoo is adding fairly little value.

All they do is download sources anyway, which is trivially done from
git more efficiently (or tarballs that are probably easy to obtain
just as efficiently).  I can see more of the point in the new
distribution kernel project which will be turnkey.  I can see some of
the value in gentoo-sources (particularly as the upstream for the
distribution kernels) especially if they're tied to Gentoo-specific
bugs.  For more general bugs that apply to all distros I really don't
see the point in trying to compete with the upstream stable branches
(if they're taking forever to merge a patch, chances are there is a
reason for it, and I'm skeptical that Gentoo users are special in some
way).

Is there some reason that we should keep vanilla sources despite not
getting security handling?

-- 
Rich


  reply	other threads:[~2020-01-04 11:01 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-28  7:09 [gentoo-dev] Keywordreqs and slacking arch teams Michał Górny
2019-12-28  9:27 ` Kent Fredric
2019-12-28  9:35   ` Fabian Groffen
2019-12-28 11:05     ` Kent Fredric
2019-12-28 11:14       ` Michael 'veremitz' Everitt
2019-12-28 11:27         ` Kent Fredric
2019-12-28 11:40           ` James Le Cuirot
2019-12-28 11:44             ` Kent Fredric
2019-12-28 11:32         ` Kent Fredric
2019-12-28 11:35           ` Michael 'veremitz' Everitt
2019-12-28 11:42             ` Kent Fredric
2019-12-28 18:05               ` Alec Warner
2019-12-29  2:19                 ` Aaron Bauman
2019-12-29  5:09                   ` Kent Fredric
2019-12-30  1:45         ` A Schenck
2020-01-02 20:32       ` Rolf Eike Beer
2020-01-02 23:25         ` Mike Pagano
2020-01-02 23:35           ` Rolf Eike Beer
2020-01-03  0:19             ` Michael 'veremitz' Everitt
2020-01-03  2:40             ` Aaron Bauman
2020-01-03 10:00               ` Rolf Eike Beer
2020-01-04 11:09                 ` Rolf Eike Beer
2020-01-04 11:25                   ` Michael 'veremitz' Everitt
2020-01-04 13:35                     ` Rolf Eike Beer
2020-01-03 14:37             ` [gentoo-dev] Vanilla sources Michael Orlitzky
2020-01-03 14:40               ` Toralf Förster
2020-01-03 14:41                 ` Michael Orlitzky
2020-01-03 14:46                   ` Rich Freeman
2020-01-03 14:48                     ` Toralf Förster
2020-01-03 22:32                       ` Michael 'veremitz' Everitt
2020-01-04  7:38                       ` Hanno Böck
2020-01-04 18:39                         ` William Hubbs
2020-01-04 18:41                         ` Michał Górny
2020-01-07  8:52                           ` Hanno Böck
2020-01-03 14:52                     ` Michael Orlitzky
2020-01-03 14:55                       ` Michael Orlitzky
2020-01-03 16:28                         ` Aaron Bauman
2020-01-04 11:01                           ` Rich Freeman [this message]
2020-01-04 11:42                             ` Roy Bamford
2020-01-04 12:54                               ` Rich Freeman
2020-01-04 13:08                                 ` Roy Bamford
2020-01-04 13:43                                   ` Thomas Deutschmann
2020-01-05 10:34                                     ` Roy Bamford
2020-01-04 20:13                                 ` Christopher Head
2020-01-04 20:39                                   ` Rich Freeman
2020-01-04 13:47                             ` Thomas Deutschmann
2020-01-04 18:41                         ` William Hubbs
2020-01-04 18:42                           ` Michał Górny
2020-01-04 19:13                           ` Rolf Eike Beer
2020-01-05 16:41                             ` Michael Orlitzky

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='CAGfcS_=KzxrAWDasd-h4w+dXsUshtTCgNtEJsybaP1WKHz_yLA@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.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