Re: [gentoo-dev] Vanilla sources

2020-01-07 Thread Hanno Böck
On Sat, 04 Jan 2020 19:41:21 +0100
Michał Górny  wrote:

> On Sat, 2020-01-04 at 08:38 +0100, Hanno Böck wrote:
> > On Fri, 3 Jan 2020 15:48:54 +0100
> > Toralf Förster  wrote:
> >   
> > > #   Restrict potential illegal access via links
> > > # 
> > > fs.protected_hardlinks = 1
> > > fs.protected_symlinks = 1   
> > 
> > Given the issues with openrc:
> > Wouldn't it be a good idea to add these by default to Gentoo's
> > sysctl.conf in baselayout?  
> 
> Yes, we should.  This really sounds like some horror where developers
> are hacking things around in sources instead of communicating with
> people maintaining the component where a proper fix belongs.

I created a bug for this so we can move the discussion there:
https://bugs.gentoo.org/704914

Particularly if anyone thinks this is a bad idea or knows of a
situation where this breaks things please speak up now in the bugreport.

-- 
Hanno Böck
https://hboeck.de/


pgpu2QXCFT33y.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-05 Thread Michael Orlitzky
On 1/4/20 2:13 PM, Rolf Eike Beer wrote:
> 
> Bad idea. If you wonder why: eshowkw dev-lang/rust.
> 

Or consider that every rust package in Gentoo bundles hundreds of
libraries. We'd be fixing one security issue by introducing 10x more.

Not that rewriting it in rust would fix anything; writing it in C is
only a solution insofar as it makes the window to exploit the race
condition is as small as possible.



Re: [gentoo-dev] Vanilla sources

2020-01-05 Thread Roy Bamford
On 2020.01.04 13:43, Thomas Deutschmann wrote:
> On 2020-01-04 14:08, Roy Bamford wrote:
> > emerge -1 vanilla-sources
> > eselect kernel ...
> > genkernel all
> > ...
> 
> Please tell user to do
> 
> genkernel --kernel-config=/proc/config.gz all
> 
> by default which will give them a better experience because new kernel
> will be build based on kernel configuration from current running
> kernel.
> Without providing a kernel config, user will probably fall back to
> generic configuration which isn't intended for daily usage.
> 
> 
> -- 
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
> 
> 

Thomas,

Ten years ago the user did 
genkernel all 
and used the default .config provided with genkernel.

Today, genkernel --kernel-config=/proc/config.gz all does not improve 
that config.

genkernel --kernel-config=/proc/config.gz all 
perpetuates the existing .config which is only useful if its not an 
earlier generic configuration.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpjhN8CA5bom.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Sat, Jan 4, 2020 at 3:13 PM Christopher Head  wrote:
>
>
> Of course this would be a bad argument if V-S were lagging behind upstream 
> significantly, and it’s a much better argument for packages that come with 
> expectations of security team support than those that don’t, but it is 
> something to consider.
>

This was my main concern when it was mentioned that it wasn't
security-supported.

If it is always up-to-date that definitely helps mitigate things.
Though, there should definitely be some kind of warning on the package
that it isn't security supported.  Even if it is up to date it won't
get GLSAs and GLSA-checker won't work.  Though, that really only makes
a difference insofar as the GLSAs are also timely.

In any case, if the just-announced distribution kernel project takes
off and remains active I could easily see that becoming the most
commonly used kernel option.  I'm not knocking minimal kernels but I
suspect a LOT of users are going to be well-served by a modular kernel
that just works 99% of the time.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Christopher Head
On January 4, 2020 4:54:07 AM PST, Rich Freeman  wrote:
>
>Uh, all it does is install kernel sources.  They're useless unless you
>build a kernel using them.
>
>Apparently git and tar are too complicated for Gentoo users, but
>managing symlinks, using make, managing a bootloader, dealing with the
>kernel's configuration system, and so on are just fine?

I use gentoo-sources myself, but still, I would like to propose one reason for 
keeping vanilla-sources. For me, git/tar are not too complicated, but having 
V-S in the Gentoo tree would provide another benefit: reducing the number of 
things I have to check every weekly update cycle. Every piece of software I get 
from a source other than the Gentoo tree is another website I have to visit 
every update day to check whether there’s a newer version available. So from 
that perspective, the advantage of having packages in tree that just install 
some files is that emerge tells me when a new version is available, rather than 
me having to go every week to upstream’s website and check manually (or sign up 
for countless announcement mailing lists).

Of course this would be a bad argument if V-S were lagging behind upstream 
significantly, and it’s a much better argument for packages that come with 
expectations of security team support than those that don’t, but it is 
something to consider.

-- 
Christopher Head

signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rolf Eike Beer
Am Samstag, 4. Januar 2020, 19:41:05 CET schrieb William Hubbs:
> On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky 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.
> 
> There is a pr open for opentmpfiles for this, and we are also discussing
> writing it in rust.

Bad idea. If you wonder why: eshowkw dev-lang/rust.

Eike

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Michał Górny
On Sat, 2020-01-04 at 12:41 -0600, William Hubbs wrote:
> On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky 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.
> 
> There is a pr open for opentmpfiles for this, and we are also discussing
> writing it in rust.
> 

You could also force people to install systemd.  That would be more
merciful.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread William Hubbs
On Fri, Jan 03, 2020 at 09:55:31AM -0500, Michael Orlitzky 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.

There is a pr open for opentmpfiles for this, and we are also discussing
writing it in rust.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Michał Górny
On Sat, 2020-01-04 at 08:38 +0100, Hanno Böck wrote:
> On Fri, 3 Jan 2020 15:48:54 +0100
> Toralf Förster  wrote:
> 
> > #   Restrict potential illegal access via links
> > # 
> > fs.protected_hardlinks = 1
> > fs.protected_symlinks = 1 
> 
> Given the issues with openrc:
> Wouldn't it be a good idea to add these by default to Gentoo's
> sysctl.conf in baselayout?

Yes, we should.  This really sounds like some horror where developers
are hacking things around in sources instead of communicating with
people maintaining the component where a proper fix belongs.

> 
> As far as I understand this from the thread by now, these are set by
> default by Gentoo Sources. So we shouldn't really expect much breakage
> if we set them via sysctl.
> 
> 

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread William Hubbs
On Sat, Jan 04, 2020 at 08:38:59AM +0100, Hanno Böck wrote:
> On Fri, 3 Jan 2020 15:48:54 +0100
> Toralf Förster  wrote:
> 
> > #   Restrict potential illegal access via links
> > # 
> > fs.protected_hardlinks = 1
> > fs.protected_symlinks = 1 
> 
> Given the issues with openrc:
> Wouldn't it be a good idea to add these by default to Gentoo's
> sysctl.conf in baselayout?

If we want to do this, it is easy for me to do it in baselayout.

Thanks,

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Thomas Deutschmann
On 2020-01-04 12:01, Rich Freeman wrote:
> Packages without security support should be masked.  Really I don't
> see the point of even having this in the repo.

THIS! +infinite

And arches without security support in general can't have stable keywords.

But this is a dream. :-/


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Thomas Deutschmann
On 2020-01-04 14:08, Roy Bamford wrote:
> emerge -1 vanilla-sources
> eselect kernel ...
> genkernel all
> ...

Please tell user to do

genkernel --kernel-config=/proc/config.gz all

by default which will give them a better experience because new kernel
will be build based on kernel configuration from current running kernel.
Without providing a kernel config, user will probably fall back to
generic configuration which isn't intended for daily usage.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Roy Bamford
On 2020.01.04 12:54, Rich Freeman wrote:
> On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford 
> wrote:

[snip]
> 
> Apparently git and tar are too complicated for Gentoo users, but
> managing symlinks, using make, managing a bootloader, dealing with the
> kernel's configuration system, and so on are just fine?

emerge -1 vanilla-sources
eselect kernel ...
genkernel all
...

Yep, lots of users have trouble managing their boot loader. They come to
the forums and IRC every day not running the kernel they think they are.
That's not related to any particular kernel sources though.

[snip]

> 
> On a further aside, I just noticed how up-to-date gentoo-sources are.
> Kudos to whoever is doing that these days - for a while it was tending
> to slip a bit but it seems like we're basically current.

+1

> 
> -- 
> Rich
> 
> 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpOaAY6RX0hb.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Sat, Jan 4, 2020 at 6:42 AM Roy Bamford  wrote:
>
> On 2020.01.04 11:01, Rich Freeman wrote:
> >
> > Is there some reason that we should keep vanilla sources despite not
> > getting security handling?
> >
>
> Gentoo had this discussion before. The outcome was that
> vanilla-sources is just as Linus intended.
> If Gentoo did anything to it, it wouldn't be vanilla any longer.

Obviously.  I wasn't suggesting that we keep vanilla sources but not
make them vanilla.  That doesn't mean that they couldn't be
security-supported, or that we have to have them in the repo.

> Yes, it should be kept. We should not force users to learn
> git or tar.

Uh, all it does is install kernel sources.  They're useless unless you
build a kernel using them.

Apparently git and tar are too complicated for Gentoo users, but
managing symlinks, using make, managing a bootloader, dealing with the
kernel's configuration system, and so on are just fine?

I completely get the point of the distribution kernel project that was
just announced, as I already said.

> I agree git or a tarball of vanilla-sources is faster and more
> efficient but that's not a reason to drop it.
> By the same argument we could drop linux-firmware too.
> There are probably other packages that only install whatever
> they fetch. Could they be dropped?

So, a few issues with that argument:

1.  Those other packages are security supported.
2.  Those other packages are largely functional once installed, and to
the degree that they require configuration that is generally one-time
and after updates they remain functional.

All that said, it seems like vanilla-sources is pretty up-to-date, so
I'm not sure what we mean by it not being security supported.  I just
took that as a given.  Does that mean that we're not releasing patches
before upstream?  If so, that seems like a pretty minor issue since
upstream generally does security bumps pretty quickly.  4.4.208 isn't
in our repo but was released today - I'm not sure how quickly these
get bumped.  If our repo could be days behind that is definitely
another reason not to host this stuff, as users should be directed
upstream if our packages aren't security supported.

On a further aside, I just noticed how up-to-date gentoo-sources are.
Kudos to whoever is doing that these days - for a while it was tending
to slip a bit but it seems like we're basically current.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Roy Bamford
On 2020.01.04 11:01, Rich Freeman wrote:
>
> Is there some reason that we should keep vanilla sources despite not
> getting security handling?
> 
> -- 
> Rich
> 

Rich,

Gentoo had this discussion before. The outcome was that 
vanilla-sources is just as Linus intended.
If Gentoo did anything to it, it wouldn't be vanilla any longer.

Yes, it should be kept. We should not force users to learn
git or tar.

I agree git or a tarball of vanilla-sources is faster and more
efficient but that's not a reason to drop it.
By the same argument we could drop linux-firmware too.
There are probably other packages that only install whatever
they fetch. Could they be dropped?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpNeBPcQXuuf.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources

2020-01-04 Thread Rich Freeman
On Fri, Jan 3, 2020 at 11:28 AM Aaron Bauman  wrote:
> On January 3, 2020 9:55:31 AM EST, Michael Orlitzky  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



Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Hanno Böck
On Fri, 3 Jan 2020 15:48:54 +0100
Toralf Förster  wrote:

> #   Restrict potential illegal access via links
> # 
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1 

Given the issues with openrc:
Wouldn't it be a good idea to add these by default to Gentoo's
sysctl.conf in baselayout?

As far as I understand this from the thread by now, these are set by
default by Gentoo Sources. So we shouldn't really expect much breakage
if we set them via sysctl.


-- 
Hanno Böck
https://hboeck.de/


pgp0gbqf5JHKL.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael 'veremitz' Everitt
On 03/01/20 14:48, Toralf Förster wrote:
> On 1/3/20 3:46 PM, Rich Freeman wrote:
>> If OpenRC contains a vulnerability wouldn't it make more sense to set
>> this as part of OpenRC,
> Indeed.
>
> Furthermore there's a nifty page 
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
> which yields for me to this /etc/sysctl.d/local.conf :
>
>
> #   Restrict potential illegal access via links
> # 
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1 
>
> #
> # https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#CONFIGs
> #
>
> # Try to keep kernel address exposures out of various /proc files (kallsyms, 
> modules, etc).
> kernel.kptr_restrict = 1
>
> # Avoid kernel memory address exposures via dmesg.
> kernel.dmesg_restrict = 1
>
> # Block non-uid-0 profiling (needs distro patch, otherwise this is the same 
> as "= 2")
> kernel.perf_event_paranoid = 3
>
> # Turn off kexec, even if it's built in.
> kernel.kexec_load_disabled = 1
>
> # Avoid non-ancestor ptrace access to running processes and their credentials.
> kernel.yama.ptrace_scope = 1
>
> # Disable User Namespaces, as it opens up a large attack surface to 
> unprivileged users.
> user.max_user_namespaces = 0
>
> # Turn off unprivileged eBPF access.
> kernel.unprivileged_bpf_disabled = 1
>
> # Turn on BPF JIT hardening, if the JIT is enabled.
> net.core.bpf_jit_harden = 2
>
>
FWIW, there is a move to add further hardening options to the
Gentoo-sources kernel - bug 689154, based on the kernsec recommendations.
Further details of proposals, and inspiration, are in the bug.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Aaron Bauman



On January 3, 2020 9:55:31 AM EST, Michael Orlitzky  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. 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
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.



Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/3/20 9:46 AM, Rich Freeman wrote:
> 
> ...
> 
> In any case this seems more like an OpenRC issue than a Gentoo issue.
> 

It's a specification issue. There's no way to implement tmpfiles safely
on a POSIX system, and opentmpfiles shouldn't exist if OpenRC wants to
work on anything other than Linux.

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?



Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Toralf Förster
On 1/3/20 3:46 PM, Rich Freeman wrote:
> If OpenRC contains a vulnerability wouldn't it make more sense to set
> this as part of OpenRC,
Indeed.

Furthermore there's a nifty page 
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
which yields for me to this /etc/sysctl.d/local.conf :


#   Restrict potential illegal access via links
# 
fs.protected_hardlinks = 1
fs.protected_symlinks = 1 

#
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#CONFIGs
#

# Try to keep kernel address exposures out of various /proc files (kallsyms, 
modules, etc).
kernel.kptr_restrict = 1

# Avoid kernel memory address exposures via dmesg.
kernel.dmesg_restrict = 1

# Block non-uid-0 profiling (needs distro patch, otherwise this is the same as 
"= 2")
kernel.perf_event_paranoid = 3

# Turn off kexec, even if it's built in.
kernel.kexec_load_disabled = 1

# Avoid non-ancestor ptrace access to running processes and their credentials.
kernel.yama.ptrace_scope = 1

# Disable User Namespaces, as it opens up a large attack surface to 
unprivileged users.
user.max_user_namespaces = 0

# Turn off unprivileged eBPF access.
kernel.unprivileged_bpf_disabled = 1

# Turn on BPF JIT hardening, if the JIT is enabled.
net.core.bpf_jit_harden = 2


-- 
Toralf
PGP 23217DA7 9B888F45



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Rich Freeman
On Fri, Jan 3, 2020 at 9:41 AM Michael Orlitzky  wrote:
>
> On 1/3/20 9:40 AM, Toralf Förster wrote:
> > On 1/3/20 3:37 PM, Michael Orlitzky wrote:
> >> The gentoo-sources aren't 100% safe either, but the exploitable scenario
> >> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
> >
> > But this can be easily achieved w/o installing gentoo-sources, or?
> >
>
> Yes, if you know how to do it. And the hard part: if you know that you
> *should* do it.
>

If OpenRC contains a vulnerability wouldn't it make more sense to set
this as part of OpenRC, then to assume somebody is running a kernel
patch that does it, especially since OpenRC doesn't in any way ensure
that gentoo-sources is actually being used?

Of course, fixing the vulnerability seems like a better option.   At
least on Linux based on your one bug description it sounds like
systemd has a Linux-specific fix already.  Obviously it would be best
to secure this on all kernels but there is no reason not to at least
use that fix on Linux.  You could also try to convince the entire
world not to use tmpfiles.d but since it is only a problem if you
aren't using systemd I suspect you won't get much traction there.

In any case this seems more like an OpenRC issue than a Gentoo issue.

-- 
Rich



Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/3/20 9:40 AM, Toralf Förster wrote:
> On 1/3/20 3:37 PM, Michael Orlitzky wrote:
>> The gentoo-sources aren't 100% safe either, but the exploitable scenario
>> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
> 
> But this can be easily achieved w/o installing gentoo-sources, or?
> 

Yes, if you know how to do it. And the hard part: if you know that you
*should* do it.




Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Toralf Förster
On 1/3/20 3:37 PM, Michael Orlitzky wrote:
> The gentoo-sources aren't 100% safe either, but the exploitable scenario
> is less common thanks to fs.protected_{hardlinks,symlinks}=1.

But this can be easily achieved w/o installing gentoo-sources, or?

-- 
Toralf
PGP 23217DA7 9B888F45



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/2/20 6:35 PM, Rolf Eike Beer wrote:
> 
> I only run vanilla-sources since there are still lot of cache corruption 
> problems in hppa kernels, or whatever makes them flaky.

The vanilla-sources are unsafe to use on Gentoo. Many services have
stupid-easy root exploits, since we install tmpfiles entries by default
and OpenRC runs them insecurely:

  * https://github.com/OpenRC/opentmpfiles/issues/3
  * https://github.com/OpenRC/opentmpfiles/issues/4

I've fixed similar exploits when I've found them in /etc/init.d and
pkg_postinst[0][1], but they continue to be added to the tree. And there
is no fix for opentmpfiles.

The gentoo-sources aren't 100% safe either, but the exploitable scenario
is less common thanks to fs.protected_{hardlinks,symlinks}=1.


[0]
http://michael.orlitzky.com/articles/end_root_chowning_now_%28make_etc-init.d_great_again%29.xhtml

[1]
http://michael.orlitzky.com/articles/end_root_chowning_now_%28make_pkg_postinst_great_again%29.xhtml



Re: [gentoo-dev] vanilla-sources broken

2018-01-05 Thread Nicolas Bock

On Fri, Jan 05, 2018 at 11:47:51PM +0900, Alice Ferrazzi wrote:

On Fri, Jan 5, 2018 at 11:08 PM, Nicolas Bock  wrote:

Hi,

currently vanilla-sources are broken, but there is an upstream patch that
fixes it (appended at the end). I know that vanilla-sources are supposed to
be vanilla, but it would help if we added this patch until upstream
backports it. Any thoughts?



Thanks Alice,

I'll try my luck upstream :)

Nick


Hello Nicolas,

vanilla-sources, unfortunately, are given same as the kernel upstream,
Gentoo is not supporting or adding patches to vanilla-sources.
If you have any problem with vanilla-sources please report it to the Kernel
upstream not to Gentoo.
If you want kernel support from Gentoo kernel team, please switch to
gentoo-sources.

--
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Board Member
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A



--
Nicolas Bock 


signature.asc
Description: PGP signature


Re: [gentoo-dev] vanilla-sources broken

2018-01-05 Thread Alice Ferrazzi
On Fri, Jan 5, 2018 at 11:08 PM, Nicolas Bock  wrote:
> Hi,
>
> currently vanilla-sources are broken, but there is an upstream patch that
> fixes it (appended at the end). I know that vanilla-sources are supposed to
> be vanilla, but it would help if we added this patch until upstream
> backports it. Any thoughts?
>

Hello Nicolas,

vanilla-sources, unfortunately, are given same as the kernel upstream,
Gentoo is not supporting or adding patches to vanilla-sources.
If you have any problem with vanilla-sources please report it to the Kernel
upstream not to Gentoo.
If you want kernel support from Gentoo kernel team, please switch to
gentoo-sources.

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Board Member
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A



[gentoo-dev] vanilla-sources broken

2018-01-05 Thread Nicolas Bock

Hi,

currently vanilla-sources are broken, but there is an upstream patch that fixes 
it (appended at the end). I know that vanilla-sources are supposed to be 
vanilla, but it would help if we added this patch until upstream backports it. 
Any thoughts?

Best,

Nick



From 9d641b18db295b9ded33df0430940c7df7bb795e Mon Sep 17 00:00:00 2001
From: Andrew Morton 
Date: Fri, 15 Dec 2017 11:22:35 +1100
Subject: tools/objtool/Makefile: don't assume sync-check.sh is executable

patch(1) loses the x bit.  Kernel build breaks.

Fixes: 3bd51c5a371de ("objtool: Move kernel headers/code sync check to a 
script")
Cc: Ingo Molnar 
Cc: Josh Poimboeuf 
Signed-off-by: Andrew Morton 
Signed-off-by: Stephen Rothwell 
---
tools/objtool/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index ae0272f..e6acc28 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -46,7 +46,7 @@ $(OBJTOOL_IN): fixdep FORCE
@$(MAKE) $(build)=objtool

$(OBJTOOL): $(LIBSUBCMD) $(OBJTOOL_IN)
-   @./sync-check.sh
+   @$(CONFIG_SHELL) ./sync-check.sh
$(QUIET_LINK)$(CC) $(OBJTOOL_IN) $(LDFLAGS) -o $@


--
cgit v1.1


--
Nicolas Bock 


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Tom Wijsman
On Thu, 8 Aug 2013 15:29:06 -0700
Greg KH gre...@gentoo.org wrote:

 On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
  
   On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
I think this supports the argument that the better kernel is
always the one with the most fixes.
  
  Define better; because 3.10.0 has also been worse than the last
  3.9 release in some ways, despite it having more fixes than the
  last 3.9.
 
 How was it worse?  You don't seem to define that either :)

The point is rather whether it can be defined, therefore it is also
worse in some ways; of course without statistics you can't really
define it, but as long as there is reason to believe it people are
going to follow this train of thoughts. For example, the LTS kernels.

 Yes, there are always going to be bugs and regressions, but as long as
 we are fixing them more than we are making them, we are doing ok.

That's might be a false impression; have you took a set of commits from
back in time, analyzed what they caused and have a report available?

There's reason enough to be wary of refactoring, new features and more
to regress the first release of a new branch; and none of these are
actually fixes, they are not ok when you are looking for stability.

(Add to that that fixes can also cause bugs and regressions.)

Later releases in a branch don't contain such commits, only fixes; so,
therefore skipping the first releases of a branch is a normal thing to
do, unless there's proof or more convincing argumentation that it is a
stupid thing to do I don't see a change in this behavior any time soon.

Without statistics, neither person is wrong or right; so, both behaviors
happen and are based on thoughts, reasoning and beliefs. So, when stated
that the better kernel is always the one with the most fixes one needs
to objectively define better; otherwise that sentence is meaningless.

Without a definition and supporting evidence, that is a contradiction.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Tom Wijsman
On Fri, 9 Aug 2013 01:44:12 +0200
Peter Stuge pe...@stuge.se wrote:

   I think this supports the argument that the better kernel is
   always the one with the most fixes.
  
  That's what us kernel developers have been saying for 10+ years,
  nice to see it's finally getting some traction :)
 
 It has been obvious for me for a very long time as well, but I am
 just one person, and my idea doesn't seem to have much traction in
 Gentoo. :\

When you state a contradiction [1], there is nothing convincing about
it; the sentence as you made it there, can be interpreted in both ways.

 [1]: 20130809101023.6618a356@TOMWIJ-GENTOO
  See the previous mail I just sent out.

   Rather than separating bug fixes from security fixes maybe
   it's wiser to think about separating fixes from features -
   this may be easier, but still not neccessarily easy.
  
  For stable kernel releases, that type of thing should be quite easy
  for someone to do, if they want to do it, as the only type of
  features I take for them are new device ids.
  
  But I fail to see how marking 5 patches out of 100 as features is
  really doing to do much for anyone, do you?
 
 For stable kernel releases there would be no need.

Depends on your own needs; but, identifying security fixes so they can
be applied in a timely fashion as well as back ported and what not
would definitely help. Why should the fact be hidden or slowly deduced
that a commit is a security fix. Collaboration would really help...

 I think they should be stabilized automatically in Gentoo. It's
 simply a more accurate model of upstream.

With 30 days delay, as well as bugs that block stabilization; there is
nowhere in Gentoo an accurate model of upstream, if it were then it
would be my mere luck. I don't see why the kernel should differ...

At most, we do our best to keep up where we can; if not, there's always
keywords like ~ and  for people that want to be more bleeding edge.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Tom Wijsman
On Thu, 8 Aug 2013 15:32:45 -0700
Greg KH gre...@gentoo.org wrote:

 On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
  On Wed, 7 Aug 2013 15:44:34 -0700
  Greg KH gre...@gentoo.org wrote:
  
   I am not going to impose an additional burden on developers to get
   their patches into the stable kernel releases like this, sorry.
  
  As I said, it's not your task; so, what you impose doesn't matter.
 
 What do you mean by that?  I am the upstream stable kernel maintainer,
 as well as a subsystem maintainer.  I don't want to do the extra work
 of tagging all of my stable patches with this type of information, I
 can barely keep on top of the ones that I have to mark for stable as
 it is.

  ...

 But I will argue that you can not annotate them properly.  That is
 imposing more work on me, a subsystem maintainer, that I will not do.

Not just stable patches, but any patch; why delay till after the fact?

Tagging at the time of committing is just a few extra characters.

   Hint, the line between a bugfix and a security fix is not always
   obvious, or even known at all.
  
  The developer knows; and if not, he can probably just mark it as a
  fix.
 
 Ok, so you have just now divided everything into fix or feature.
 As the feature patches are quite obvious, everything else must be
 fix. So why tag anything, your classification is already done for
 you.

If they are obvious, what's so hard abut tagging them?

No classification is done if there is no single command to obtain them.

   And what about all of the fixes I merge in, that _are_ really
   security fixes, yet we do not want to shout it out to the world
   at the moment?
  
  For known security bugs, being aware of a fix earlier helps.
 
 I don't understand what you mean here at all.

Neither do I understand what you mean by not shouting it out; so,
unless you have argumentation to not shout it out, I'm in the belief
that the faster one is able to apply a security fix, the more secure he
is as a result. If not shouting it out makes things more secure, then
please state me how and why; because it only gives attackers more time.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Rich Freeman
On Fri, Aug 9, 2013 at 4:34 AM, Tom Wijsman tom...@gentoo.org wrote:
 On Thu, 8 Aug 2013 15:32:45 -0700
 Greg KH gre...@gentoo.org wrote:
 On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
   And what about all of the fixes I merge in, that _are_ really
   security fixes, yet we do not want to shout it out to the world
   at the moment?
 
  For known security bugs, being aware of a fix earlier helps.

 I don't understand what you mean here at all.

 Neither do I understand what you mean by not shouting it out; so,
 unless you have argumentation to not shout it out, I'm in the belief
 that the faster one is able to apply a security fix, the more secure he
 is as a result. If not shouting it out makes things more secure, then
 please state me how and why; because it only gives attackers more time.

I think that you guys are talking past each other to an extent.

My sense is that Greg is using the term security bugs to refer to
implementation errors that could be exploited to obtain unintended
access to a system.  Using this definition, any bug could be a
security bug, and figuring this out is about as easy as figuring out
whether a particular move is a good or bad one in chess.

I think Tom is using the term security bug to refer to a bug that has
a published exploit against it (ie a CVE/etc).  Using this definition
it is clear whether a particular bug is a security bug - it is either
in the database or it isn't.

I don't follow the kernel closely, but my guess is that they stay
well-ahead of CVE most of the time.  I'd certainly say that any
project should clearly document which releases incorporate fixes to
CVEs - perhaps the kernel already does this.  Since most bugs get
fixed before anybody bothers to file a CVE, I'm not sure how much that
actually matters in practice.

Frankly with the huge volume of changes and frequent releases I'm
amazed the kernel works as well as it does!  Greg gave a talk about
the rate of change and the implications for those submitting changes
recently - I'm sure it is on youtube/etc somewhere.

Rich



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Tom Wijsman
On Fri, 9 Aug 2013 06:38:56 -0400
Rich Freeman ri...@gentoo.org wrote:

 My sense is that Greg is using the term security bugs to refer to
 implementation errors that could be exploited to obtain unintended
 access to a system.  Using this definition, any bug could be a
 security bug, and figuring this out is about as easy as figuring out
 whether a particular move is a good or bad one in chess.

That's indeed not what I understood; Greg, was this your though?

 I think Tom is using the term security bug to refer to a bug that has
 a published exploit against it (ie a CVE/etc).  Using this definition
 it is clear whether a particular bug is a security bug - it is either
 in the database or it isn't.

This is indeed what I assumed Greg meant; so, thanks for clarifying.

 I don't follow the kernel closely, but my guess is that they stay
 well-ahead of CVE most of the time.  I'd certainly say that any
 project should clearly document which releases incorporate fixes to
 CVEs - perhaps the kernel already does this.

Currently I don't see this; so, my assumption was that it does not
currently happen, as far as I have seen this appears to happen on an
individual basis, but I assume not everyone does report to CVE.

Reporting to CVE is much more work than it takes to tag a commit; so,
as you can see tagging here might be a benefit to lift the work to
other people that have more time for reporting it as a CVE, etc...

 Since most bugs get fixed before anybody bothers to file a CVE, I'm
 not sure how much that actually matters in practice.

It is dangerous to assume something you fix isn't known yet. As I said
before, it buys the people that do know time; whether or not a CVE or
any other form of public or less public documentation on it exists.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Greg KH
On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote:
 On Fri, 9 Aug 2013 06:38:56 -0400
 Rich Freeman ri...@gentoo.org wrote:
 
  My sense is that Greg is using the term security bugs to refer to
  implementation errors that could be exploited to obtain unintended
  access to a system.  Using this definition, any bug could be a
  security bug, and figuring this out is about as easy as figuring out
  whether a particular move is a good or bad one in chess.
 
 That's indeed not what I understood; Greg, was this your though?

Yes, that's close to the issue.  Any bug could be classified as a
security bug if you wish to do so, so there's no need to call out some
fixes and not others, as odds are, you will miss some, and give people
the wrong impression they are safe when they are really not.

  I don't follow the kernel closely, but my guess is that they stay
  well-ahead of CVE most of the time.  I'd certainly say that any
  project should clearly document which releases incorporate fixes to
  CVEs - perhaps the kernel already does this.
 
 Currently I don't see this; so, my assumption was that it does not
 currently happen, as far as I have seen this appears to happen on an
 individual basis, but I assume not everyone does report to CVE.
 
 Reporting to CVE is much more work than it takes to tag a commit; so,
 as you can see tagging here might be a benefit to lift the work to
 other people that have more time for reporting it as a CVE, etc...

The kernel usually has things fixed it in long before a CVE is asked
for.  So there's no way to go back in time and add CVEs to commits.

thanks,

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Greg KH
On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote:
 On Thu, 8 Aug 2013 15:32:45 -0700
 Greg KH gre...@gentoo.org wrote:
 
  On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
   On Wed, 7 Aug 2013 15:44:34 -0700
   Greg KH gre...@gentoo.org wrote:
   
I am not going to impose an additional burden on developers to get
their patches into the stable kernel releases like this, sorry.
   
   As I said, it's not your task; so, what you impose doesn't matter.
  
  What do you mean by that?  I am the upstream stable kernel maintainer,
  as well as a subsystem maintainer.  I don't want to do the extra work
  of tagging all of my stable patches with this type of information, I
  can barely keep on top of the ones that I have to mark for stable as
  it is.
 
   ...
 
  But I will argue that you can not annotate them properly.  That is
  imposing more work on me, a subsystem maintainer, that I will not do.
 
 Not just stable patches, but any patch; why delay till after the fact?
 
 Tagging at the time of committing is just a few extra characters.

And don't people do that already with their changelog comments in the
kernel?

No, not in any offical format, but that's been rejected numerous
times.  Just read the commits to find out what is resolved, if anything
is known at that point in time, if you are curious.


Hint, the line between a bugfix and a security fix is not always
obvious, or even known at all.
   
   The developer knows; and if not, he can probably just mark it as a
   fix.
  
  Ok, so you have just now divided everything into fix or feature.
  As the feature patches are quite obvious, everything else must be
  fix. So why tag anything, your classification is already done for
  you.
 
 If they are obvious, what's so hard abut tagging them?

Because it's extra work that is pointless.  You do realize just how many
patches go into the kernel every day, right?  Doing anything to a patch
will slow things down, and given the huge number of the, odds are a
percentage will be wrong anyway.

 No classification is done if there is no single command to obtain them.

I don't understand what you mean by this.

And what about all of the fixes I merge in, that _are_ really
security fixes, yet we do not want to shout it out to the world
at the moment?
   
   For known security bugs, being aware of a fix earlier helps.
  
  I don't understand what you mean here at all.
 
 Neither do I understand what you mean by not shouting it out; so,
 unless you have argumentation to not shout it out, I'm in the belief
 that the faster one is able to apply a security fix, the more secure he
 is as a result. If not shouting it out makes things more secure, then
 please state me how and why; because it only gives attackers more time.

The kernel team does not explicitly call out security fixes when they go
into the kernel for a variety of good reasons, all of which have been
argued and debated numerous times for many years.  See the linux-kernel
mailing list archives if you are curious, I'm not going to get into that
argument here, except to point out that the current behavior is probably
not going to change.

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Tom Wijsman
On Fri, 9 Aug 2013 12:30:42 -0700
Greg KH gre...@gentoo.org wrote:

 ...  Just read the commits to find out what is resolved, ...

 ... Because it's extra work that is pointless.  ...
 
  No classification is done if there is no single command to obtain
  them.
 
 I don't understand what you mean by this.

What I'm suggesting is based on the need for a digest; we both know,
that a lot of people are not going to read every single commit to
classify them, if everyone has to do that that causes a lot of double
work which could be easily spared out at the source. Alternatively,
we are in need of a separate resource outside of the kernel infra that
is interested in classifying commits this way, I'm not sure whether
there is anybody doing such thing.

Well, the CVE's are one such resource; but as you have stated in the
other mail they run behind on this, I think that other resources might
also be destined to run behind. Therefore I only see doing this at the
source to be a more solid approach that doesn't give attackers the
extra time while things stay unpatched; so, this a legitimate concern
for kernel mantainers in Gentoo as well as server admins in general.

Of course our discussion won't make this happen, because you oppose;
but I'll try to hear later with the kernel ML what their thoughts are.

 The kernel team does not explicitly call out security fixes when they
 go into the kernel for a variety of good reasons, all of which have
 been argued and debated numerous times for many years.  See the
 linux-kernel mailing list archives if you are curious, I'm not going
 to get into that argument here, except to point out that the current
 behavior is probably not going to change.

Okay, thanks for the clarifications; I'll try to look for them, failing
that I suspect people will refer me to them when I post the proposal.

Undoubtedly you heard thoughts similar to the above many times before;
but I'm new to this train of thoughts, so I'm unaware of those debates.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-09 Thread Greg KH
On Fri, Aug 09, 2013 at 09:46:43PM +0200, Tom Wijsman wrote:
 On Fri, 9 Aug 2013 12:30:42 -0700
 Greg KH gre...@gentoo.org wrote:
 
  ...  Just read the commits to find out what is resolved, ...
 
  ... Because it's extra work that is pointless.  ...
  
   No classification is done if there is no single command to obtain
   them.
  
  I don't understand what you mean by this.
 
 What I'm suggesting is based on the need for a digest; we both know,
 that a lot of people are not going to read every single commit to
 classify them, if everyone has to do that that causes a lot of double
 work which could be easily spared out at the source. Alternatively,
 we are in need of a separate resource outside of the kernel infra that
 is interested in classifying commits this way, I'm not sure whether
 there is anybody doing such thing.

There is not, and anyone who has tried to do such a thing quickly gave
up as it was a very difficult task.  But please, if you feel like you
can succeed where others have failed, please do so, I know a lot of
people would like someone to do this type of work for them.

 Undoubtedly you heard thoughts similar to the above many times before;
 but I'm new to this train of thoughts, so I'm unaware of those debates.

Yes, it comes up every few months by people who are just suddenly
thinking of it.  Please give us some kind of credit, we have been
dealing with this issue for well over a decade, and have come to the
existing state based on our experience and knowledge of what works best
for us, and hopefully, the rest of the community.

thanks,

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-08 Thread Greg KH
On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
 On Wed, 7 Aug 2013 16:19:43 -0700
 Greg KH gre...@gentoo.org wrote:
 
  On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
   Greg KH wrote:
See above for why it is not easy at all, and, why even if we do
know some fixes are security ones, we would not tag them as such
anyway.
   
   I think this supports the argument that the better kernel is always
   the one with the most fixes.
 
 Define better; because 3.10.0 has also been worse than the last 3.9
 release in some ways, despite it having more fixes than the last 3.9.

How was it worse?  You don't seem to define that either :)

Yes, there are always going to be bugs and regressions, but as long as
we are fixing them more than we are making them, we are doing ok.

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-08 Thread Greg KH
On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
 On Wed, 7 Aug 2013 15:44:34 -0700
 Greg KH gre...@gentoo.org wrote:
 
  On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
 
   Some kind of annotation with tags would make this kind of thing
   easy; I'm not saying it is your task to apply such annotations to
   commits, but it would rather be the task of the person who makes an
   individual patch.
  
  I am not going to impose an additional burden on developers to get
  their patches into the stable kernel releases like this, sorry.
 
 As I said, it's not your task; so, what you impose doesn't matter.

What do you mean by that?  I am the upstream stable kernel maintainer,
as well as a subsystem maintainer.  I don't want to do the extra work of
tagging all of my stable patches with this type of information, I can
barely keep on top of the ones that I have to mark for stable as it is.

As the stable kernel maintainer, all I ask for is that subsystem
maintainers tag their patches for the stable tree.  If I have questions
about them, I ask, otherwise I accept them.

  Can you judge which bug fixes are security ones, and which are not?
  And do so for 100+ patches a week?  52 weeks a year?  Great, please
  do so, as no one has ever been able to do this (others have tried.)
 
 Yes, that is easy on the premise that they are annotated.

But I will argue that you can not annotate them properly.  That is
imposing more work on me, a subsystem maintainer, that I will not do.

  Hint, the line between a bugfix and a security fix is not always
  obvious, or even known at all.
 
 The developer knows; and if not, he can probably just mark it as a fix.

Ok, so you have just now divided everything into fix or feature.  As
the feature patches are quite obvious, everything else must be fix.
So why tag anything, your classification is already done for you.

  And what about all of the fixes I merge in, that _are_ really security
  fixes, yet we do not want to shout it out to the world at the moment?
 
 For known security bugs, being aware of a fix earlier helps.

I don't understand what you mean here at all.

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-08 Thread Peter Stuge
Greg KH wrote:
   See above for why it is not easy at all, and, why even if we do know
   some fixes are security ones, we would not tag them as such anyway.
  
  I think this supports the argument that the better kernel is always
  the one with the most fixes.
 
 That's what us kernel developers have been saying for 10+ years, nice to
 see it's finally getting some traction :)

It has been obvious for me for a very long time as well, but I am
just one person, and my idea doesn't seem to have much traction in
Gentoo. :\


  Rather than separating bug fixes from security fixes maybe it's
  wiser to think about separating fixes from features - this may
  be easier, but still not neccessarily easy.
 
 For stable kernel releases, that type of thing should be quite easy for
 someone to do, if they want to do it, as the only type of features I
 take for them are new device ids.
 
 But I fail to see how marking 5 patches out of 100 as features is
 really doing to do much for anyone, do you?

For stable kernel releases there would be no need. I think they
should be stabilized automatically in Gentoo. It's simply a more
accurate model of upstream.


//Peter



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Tom Wijsman
On Wed, 24 Jul 2013 16:09:11 -0700
Greg KH gre...@gentoo.org wrote:

 Please
 tell me exactly how you are going to evaluate which fixes I make are
 security fixes, and you know which to pick and choose from.

Some kind of annotation with tags would make this kind of thing easy;
I'm not saying it is your task to apply such annotations to commits, but
it would rather be the task of the person who makes an individual patch.

This would benefit multiple people; it would benefit users to know the
amount of patches that are security and code fixes, new features and
see them separately. It would also benefit distributions and system
admins to filter them out, they could for instance drop new feature
patches so they just get the fixes they need.

It puts the power in the user's hands; allowing them to evaluate, pick
and choose according to their own demands and needs.

Implementation wise, I don't think this is any harder than the already
existing annotations; work wise, adding a tag is easy to do.

Maybe I should write up something more technical and throw it at the
upstream kernel ML for people to consider. Is there someone whom I need
to CC in specific if I do that?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Tom Wijsman
On Wed, 24 Jul 2013 23:17:36 +0100
Markos Chandras hwoar...@gentoo.org wrote:

 This thread derailed as usual. The kernel team made a decision.

Perhaps it did, perhaps it didn't; I do not intend to discuss this but
to rather clarify the decision that was made, as a matter of support.
The reason the reply was on the ML is so it benefits more people.

Granted, the ML isn't the right place for support though; if anyone
has further doubts we invite them to mail the kernel herd about it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Tom Wijsman
On Sat, 27 Jul 2013 15:32:39 +0200
Manuel Rüger mr...@gentoo.org wrote:

 On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
  On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
  How about dropping vanilla-sources and adding a vanilla USE flag 
  to gentoo-sources?
  Then we might as well just have a Linux package with a bunch of USE
  flags -- gentoo, hardened, libre, tuxonice, ck, etc.
  
 
 This is not a good idea, I'd like to have different kernel flavours of
 the same version installed in parallel.

If people think both ideas are good, consider having both?

Adding USE flags without dropping the packages is also an option; the
mere reason we will be bringing the experimental patches [1] soon is to
spare out on some of the duplicate work that is being done, if people
want to continue to maintain a separate package then nothing prohibits
them from doing so. Not the experimental patches [1] idea, and not the
addition of USE flags.

That being said, I expressed earlier that USE flags feel like a bad
idea though; I want you to keep in mind that, if you add USE flags, you
effectively have a double opt-in since you need to enable the USE flag
and then after that toggle the options in the menuconfig as well.

Is the gain of adding USE flags really worth the burden it causes?

 [1]: http://article.gmane.org/gmane.linux.gentoo.kernel/740

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Greg KH
On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
 On Wed, 24 Jul 2013 16:09:11 -0700
 Greg KH gre...@gentoo.org wrote:
 
  Please
  tell me exactly how you are going to evaluate which fixes I make are
  security fixes, and you know which to pick and choose from.
 
 Some kind of annotation with tags would make this kind of thing easy;
 I'm not saying it is your task to apply such annotations to commits, but
 it would rather be the task of the person who makes an individual patch.

I am not going to impose an additional burden on developers to get their
patches into the stable kernel releases like this, sorry.

Can you judge which bug fixes are security ones, and which are not?  And
do so for 100+ patches a week?  52 weeks a year?  Great, please do so,
as no one has ever been able to do this (others have tried.)

Hint, the line between a bugfix and a security fix is not always
obvious, or even known at all.

And what about all of the fixes I merge in, that _are_ really security
fixes, yet we do not want to shout it out to the world at the moment?
How would one properly tag that?

 This would benefit multiple people; it would benefit users to know the
 amount of patches that are security and code fixes, new features and
 see them separately. It would also benefit distributions and system
 admins to filter them out, they could for instance drop new feature
 patches so they just get the fixes they need.
 
 It puts the power in the user's hands; allowing them to evaluate, pick
 and choose according to their own demands and needs.
 
 Implementation wise, I don't think this is any harder than the already
 existing annotations; work wise, adding a tag is easy to do.

See above for why it is not easy at all, and, why even if we do know
some fixes are security ones, we would not tag them as such anyway.

So that kind of makes that whole idea fall apart, right?  :)

sorry,

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Peter Stuge
Greg KH wrote:
 See above for why it is not easy at all, and, why even if we do know
 some fixes are security ones, we would not tag them as such anyway.

I think this supports the argument that the better kernel is always
the one with the most fixes.

Rather than separating bug fixes from security fixes maybe it's
wiser to think about separating fixes from features - this may
be easier, but still not neccessarily easy.


//Peter



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Greg KH
On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
 Greg KH wrote:
  See above for why it is not easy at all, and, why even if we do know
  some fixes are security ones, we would not tag them as such anyway.
 
 I think this supports the argument that the better kernel is always
 the one with the most fixes.

That's what us kernel developers have been saying for 10+ years, nice to
see it's finally getting some traction :)

 Rather than separating bug fixes from security fixes maybe it's
 wiser to think about separating fixes from features - this may
 be easier, but still not neccessarily easy.

For stable kernel releases, that type of thing should be quite easy for
someone to do, if they want to do it, as the only type of features I
take for them are new device ids.

But I fail to see how marking 5 patches out of 100 as features is
really doing to do much for anyone, do you?

thanks,

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-08-07 Thread Tom Wijsman
On Wed, 7 Aug 2013 16:19:43 -0700
Greg KH gre...@gentoo.org wrote:

 On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
  Greg KH wrote:
   See above for why it is not easy at all, and, why even if we do
   know some fixes are security ones, we would not tag them as such
   anyway.
  
  I think this supports the argument that the better kernel is always
  the one with the most fixes.

Define better; because 3.10.0 has also been worse than the last 3.9
release in some ways, despite it having more fixes than the last 3.9.

  Rather than separating bug fixes from security fixes maybe it's
  wiser to think about separating fixes from features - this may
  be easier, but still not neccessarily easy.
 
 For stable kernel releases, that type of thing should be quite easy
 for someone to do, if they want to do it, as the only type of
 features I take for them are new device ids.

 But I fail to see how marking 5 patches out of 100 as features is
 really doing to do much for anyone, do you?

Preferably this would be done for any release, a release like 3.10.0
doesn't have to be an exception; it does contain a lot more features.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-29 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/07/13 15:32, Manuel Rüger wrote:
 On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
 Then we might as well just have a Linux package with a bunch of 
 USE flags -- gentoo, hardened, libre, tuxonice, ck, etc.
 This is not a good idea, I'd like to have different kernel
 flavours of the same version installed in parallel.

On 27/07/13 20:20, Chí-Thanh Christopher Nguyễn wrote:
 I don't think this can be made work, the other kernel packages' 
 releases may not happen simultaneously with kernel releases. Or
 they may even skip certain releases.

Sorry, the point I was trying to make was basically that I think that
using a vanilla USE flag is a bad idea.

- -- 
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlH24nsACgkQRtClrXBQc7UfUAEAr465o/VCLPTvYLMEQ4aZMO9S
8b6HyeAqYp1HRVgg5usBAK4n4j2hgw/6JzFFfEJyOZWIvWC4tEQyffj8p62BP35/
=64DS
-END PGP SIGNATURE-



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Sergey Popov
24.07.2013 22:16, Peter Stuge пишет:
 It seems that for this package Gentoo QA can not realistically add
 any value to this package, hence my suggestion not to pretend that
 they can, and just remove the distinction between ~arch and arch for
 v-s, and make the latest version available to users by default.

As were said before, blindly stabling vanilla-sources when
gentoo-sources is stabilized is not an option.

Remove the distinction between ~arch and arch for any package is not
apropriate, as stable keywords were made for a reason, period...

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Chí-Thanh Christopher Nguyễn
Mike Pagano schrieb:
 Team members working alongside upstream (and downstream) developer Greg k-h 
 have decided to no longer request stabilization of the vanilla sources 
 kernel.  

How about dropping vanilla-sources and adding a vanilla USE flag to
gentoo-sources?


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
 How about dropping vanilla-sources and adding a vanilla USE flag 
 to gentoo-sources?
Then we might as well just have a Linux package with a bunch of USE
flags -- gentoo, hardened, libre, tuxonice, ck, etc.
- -- 
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHzyugACgkQRtClrXBQc7VyjwD/WXn+JxvCukvY1xkpQzYnwm9N
frXlmNbvh8ic0K5dxw4A+gMoly44UzLBNoMlFdp4dGqVjCHv6sMnw7p0zcDc0cO1
=qgEa
-END PGP SIGNATURE-



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Manuel Rüger
On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
 On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
 How about dropping vanilla-sources and adding a vanilla USE flag 
 to gentoo-sources?
 Then we might as well just have a Linux package with a bunch of USE
 flags -- gentoo, hardened, libre, tuxonice, ck, etc.
 

This is not a good idea, I'd like to have different kernel flavours of
the same version installed in parallel.

Kind regards,

Manuel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Rich Freeman
On Sat, Jul 27, 2013 at 4:56 AM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Mike Pagano schrieb:
 Team members working alongside upstream (and downstream) developer Greg k-h
 have decided to no longer request stabilization of the vanilla sources 
 kernel.

 How about dropping vanilla-sources and adding a vanilla USE flag to
 gentoo-sources?

Unless it were stable-masked it would create the exact same problem.

There was another suggestion to try to manage the patch sets via the
kernel config system, but that isn't without its own challenges.

Rich



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexander Berntsen schrieb:
 On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
 How about dropping vanilla-sources and adding a vanilla USE flag to
 gentoo-sources?
 Then we might as well just have a Linux package with a bunch of USE 
 flags -- gentoo, hardened, libre, tuxonice, ck, etc.

I don't think this can be made work, the other kernel packages' releases
may not happen simultaneously with kernel releases. Or they may even skip
certain releases.

Rich Freeman schrieb:
 Unless it were stable-masked it would create the exact same problem.

vanilla flags are not package.use.stable.mask'ed for toolchain packages
either, yet they go stable with them. And there, USE=vanilla might cause
serious breakage even.

 There was another suggestion to try to manage the patch sets via the 
 kernel config system, but that isn't without its own challenges.

vanilla = don't apply any patches, I don't think that could be improved by
any modification to the kernel config system.


Best regards,
Chí-Thanh Christopher Nguyễn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlH0D3MACgkQ+gvH2voEPRBmFACbBixGjRbW0z4yOhMvLRXaHx1z
PjAAnin5cF6lD7X8n0KGpBbyMFT3kAAz
=kPOS
-END PGP SIGNATURE-



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-27 Thread Mike Pagano
On Saturday, July 27, 2013 09:58:08 AM Rich Freeman wrote:

 
 Unless it were stable-masked it would create the exact same problem.
 


^^ This

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



[gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Mike Pagano

tl;dr

Summary

Team members working alongside upstream (and downstream) developer Greg k-h 
have decided to no longer request stabilization of the vanilla sources kernel.  
Team members and arch teams (understandably) are unable to keep up with the 
1-2 weekly kernel releases, and therefore will now direct users to always run 
the latest vanilla sources, or to run gentoo-sources for a fully Gentoo 
supported kernel. We will continue to do our best effort to request and get 
stabililzed g-s versions.


Details

Some facts:

1. Upstream release rate is now a much higher 1-2 kernels a week.
2. Very frequently, these releases contain security fixes.
3. This rate of release puts arch teams in a difficult position, since
it is unsustainable to try to keep up to date with stabilization
4. By continuing the policy of providing a stable vanilla kernel version, 
Gentoo is giving a false sense of security to its users, since by the time the 
kernel does get stabilized, a newer version with more security fixes is almost 
always already released

Eventually, we will be updating our project pages to reflect these changes. As 
always with me, constructive dialog concerning this policy is welcome.

Original thread of discussion:
http://thread.gmane.org/gmane.linux.gentoo.kernel/697

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Alex Xu
On 24/07/13 01:37 PM, Peter Stuge wrote:
 Mike Pagano wrote:
 Team members working alongside upstream (and downstream) developer Greg k-h 
 have decided to no longer request stabilization of the vanilla sources 
 kernel.  
 Team members and arch teams (understandably) are unable to keep up with the 
 1-2 weekly kernel releases, and therefore will now direct users to always 
 run 
 the latest vanilla sources
 
 Maybe it would make sense to automatically stabilize every v-s kernel
 right away?
 
 
 //Peter
 

As has been stated, this implies that Gentoo QA has tested the packages
and found them to be reasonably safe for use.

Although stable kernels *have* been tested by many people before use,
Gentoo QA has *not* (officially) tested them, at least not on every
architecture.

On a technical level, it's not that hard to put
sys-kernel/vanilla-sources in your package.accept_keywords.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Rich Freeman
On Wed, Jul 24, 2013 at 1:43 PM, Alex Xu alex_y...@yahoo.ca wrote:
 As has been stated, this implies that Gentoo QA has tested the packages
 and found them to be reasonably safe for use.

++

Stable should mean something, and those who understand the tradeoffs
can accept unstable packages where needed (far more easily than on
most other distros I might add).

If gentoo-sources is where our stable efforts will be, then the
keywords should reflect this.  We're not getting rid of
vanilla-sources.

Rich



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Peter Stuge
Mike Pagano wrote:
 Team members working alongside upstream (and downstream) developer Greg k-h 
 have decided to no longer request stabilization of the vanilla sources 
 kernel.  
 Team members and arch teams (understandably) are unable to keep up with the 
 1-2 weekly kernel releases, and therefore will now direct users to always run 
 the latest vanilla sources

Maybe it would make sense to automatically stabilize every v-s kernel
right away?


//Peter



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Peter Stuge
Alex Xu wrote:
  Maybe it would make sense to automatically stabilize every v-s kernel
  right away?
 
 As has been stated, this implies that Gentoo QA has tested the packages
 and found them to be reasonably safe for use.
..
 Although stable kernels *have* been tested by many people before use,
 Gentoo QA has *not* (officially) tested them, at least not on every
 architecture.

I don't think that matters.


 On a technical level, it's not that hard to put
 sys-kernel/vanilla-sources in your package.accept_keywords.

But why should Gentoo users have to do that in order to use v-s?

If it is intentional to push g-s onto users then it makes good sense -
but if I were the sys-kernel team I wouldn't bother with g-s at all
and just make v-s as easily available to users as possible..


//Peter


pgpdBl65QVL_k.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Peter Stuge
Rich Freeman wrote:
  As has been stated, this implies that Gentoo QA has tested the packages
  and found them to be reasonably safe for use.
 
 ++

While good in theory, it seems that newer v-s are actually more
reasonably safe than any g-s.


 Stable should mean something

For users, stable means older in practice. Always did, always will.


 If gentoo-sources is where our stable efforts will be, then the
 keywords should reflect this.  We're not getting rid of
 vanilla-sources.

Ideally distribution efforts to stabilize packages should go
upstream instead of staying within the distribution.

Sadly not all upstreams are competent enough to handle that. :\


//Peter



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Alex Xu
On 24/07/13 01:49 PM, Peter Stuge wrote:
 Alex Xu wrote:
 Maybe it would make sense to automatically stabilize every v-s kernel
 right away?

 As has been stated, this implies that Gentoo QA has tested the packages
 and found them to be reasonably safe for use.
 ..
 Although stable kernels *have* been tested by many people before use,
 Gentoo QA has *not* (officially) tested them, at least not on every
 architecture.
 
 I don't think that matters.

If you don't care too much for Gentoo QA, then you are free to run
global ~arch on your system. It works reasonably well (no sarcasm), and
almost always, someone has tested most packages on most architectures.
At least it's been tested by the programmer and maintainer. But that's
how KEYWORDS have always been used in Gentoo, as far as I know.

 On a technical level, it's not that hard to put
 sys-kernel/vanilla-sources in your package.accept_keywords.
 
 But why should Gentoo users have to do that in order to use v-s?

So they acknowledge that vanilla-sources has not been officially tested
by Gentoo QA. You are free to do the simple procedure once and trust the
kernel community to have done adequate testing.

 If it is intentional to push g-s onto users then it makes good sense -
 but if I were the sys-kernel team I wouldn't bother with g-s at all
 and just make v-s as easily available to users as possible..

I can't comment on that.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Peter Stuge
Alex Xu wrote:
  Maybe it would make sense to automatically stabilize every v-s kernel
  right away?
 
  As has been stated, this implies that Gentoo QA has tested the packages
  and found them to be reasonably safe for use.
  ..
  Although stable kernels *have* been tested by many people before use,
  Gentoo QA has *not* (officially) tested them, at least not on every
  architecture.
  
  I don't think that matters.
 
 If you don't care too much for Gentoo QA

The point is that when arch teams find that they can not keep up with
the pace of upstream and choose never to attempt stabilize v-s then
clearly Gentoo QA will also not be able to keep up with that pace and
thus Gentoo QA becomes irrelevant for the particular package.

There will never be Gentoo QA on v-s.

The original post also mentioned that generally v-s has more fixes
than anything coming from stabilization efforts.

It seems that for this package Gentoo QA can not realistically add
any value to this package, hence my suggestion not to pretend that
they can, and just remove the distinction between ~arch and arch for
v-s, and make the latest version available to users by default.


  On a technical level, it's not that hard to put
  sys-kernel/vanilla-sources in your package.accept_keywords.
  
  But why should Gentoo users have to do that in order to use v-s?
 
 So they acknowledge that vanilla-sources has not been officially tested
 by Gentoo QA.

Since v-s is a special case that Gentoo QA is known not to handle,
this overhead seems completely unneccessary to me. And the usability
is of course poor.


  If it is intentional to push g-s onto users then it makes good sense
..
 I can't comment on that.

I guess this is really the pivotal point. If Gentoo prefers to push
g-s rather than v-s then adding overhead for v-s kernels is fine. I'd
prefer Gentoo to push v-s instead.


//Peter


pgprinbDx2lyW.pgp
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Rich Freeman
On Wed, Jul 24, 2013 at 1:54 PM, Peter Stuge pe...@stuge.se wrote:
 Rich Freeman wrote:

 Stable should mean something

 For users, stable means older in practice. Always did, always will.

If you don't like stable, then don't run stable.  Don't change the
meaning of stable, however, for those who find it useful.

I've never had a problem with Gentoo stable.  If it doesn't work, it
should be dropped entirely on the arches that don't keep up (even if
that means all of them).  Defining stable to mean no testing at all
except by the maintainer just makes the keyword meaningless - ~arch
packages are supposed to be tested by the maintainer already.

The main distinction between stable and testing is fewer updates.  I'm
sure the average person who runs mythtv with versions synced across 3
systems doesn't need every monthly patch set I push out, but once in a
while I'll stabilize a keeper, and if somebody wants a particular
feature sooner they can do the extra work.  If a security update comes
out the stable users still get them.

If gentoo-sources isn't complying with our GLSA standards I think that
is worth bringing attention (and help) to, but I've yet to hear that
mentioned.

Rich



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Peter Stuge
Rich Freeman wrote:
  Stable should mean something
 
  For users, stable means older in practice. Always did, always will.
 
 Don't change the meaning of stable, however, for those who find it useful.

This is a good point, but the original post suggested to me that
actually every new release of v-s is preferable over every older
one and perhaps even over g-s because there are more fixes.


 Defining stable to mean no testing at all except by the maintainer
 just makes the keyword meaningless

I do think it's meaningless, though in a different way than you mean.

But back on track:

1. stable in Gentoo means Gentoo QA-approved and it is the default
2. v-s will never be stable
3. g-s will always be behind v-s, the latter having more fixes

It just seems to me that stable isn't a good default for the kernel
because of 2 and 3, and as a result users end up having fewer fixes,
since g-s is older.


 The main distinction between stable and testing is fewer updates.

If QA had infinite resources I suppose that wouldn't be the case.
I think it's important to stick to the actual definition of stable
meaning QA-approved.


 If gentoo-sources isn't complying with our GLSA standards I think
 that is worth bringing attention (and help) to, but I've yet to
 hear that mentioned.

Is that somehow implied by the original post, which states that g-s
can be expected to always lack the newest fixes in v-s?

I realize that this isn't such a simple matter, but I think it's
worth consideration.


To be clear: I am not suggesting to change the meaning of stable,
I am suggesting that the latest available upstream kernel should
perhaps be the default for Gentoo users. How to make that happen
is less important, the idea to automatically mark v-s stable is
only that, an idea. :)


//Peter



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Ben Kohler
On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge pe...@stuge.se wrote:


 To be clear: I am not suggesting to change the meaning of stable,
 I am suggesting that the latest available upstream kernel should
 perhaps be the default for Gentoo users. How to make that happen
 is less important, the idea to automatically mark v-s stable is
 only that, an idea. :)


 //Peter

 You seem to be ignoring the regressions that often come with new kernel
releases, the very common breakage caused in stable genkernel all, and
other various complications.  Unleashing brand new kernel.org sources on
stable users as soon as they are released seems crazy to me.  These
releases surely bring more than just the newest fixes.

Going straight to stable is (in my eyes) so far from being a viable option,
that always unstable, allow unstable if you're ok with the risk/benefit
tradeoff seems like the best bet, to me.

-Ben


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Peter Stuge
Ben Kohler wrote:
  I am suggesting that the latest available upstream kernel should
  perhaps be the default for Gentoo users.
 
 You seem to be ignoring the regressions that often come with new kernel
 releases, the very common breakage caused in stable genkernel all, and
 other various complications.  Unleashing brand new kernel.org sources on
 stable users as soon as they are released seems crazy to me.

I don't know, I think it makes a lot of sense..

Users who upgrade their kernels (don't upgrade if you don't want to)
would be able to participate upstream with reports and confirmations.


 These releases surely bring more than just the newest fixes.

It varies but sure, I think users should inform themselves about the
new version (of any package!) before they actually upgrade it.


//Peter



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Tom Wijsman
On Wed, 24 Jul 2013 19:54:10 +0200
Peter Stuge pe...@stuge.se wrote:

 Rich Freeman wrote:
   As has been stated, this implies that Gentoo QA has tested the
   packages and found them to be reasonably safe for use.
  
  ++
 
 While good in theory, it seems that newer v-s are actually more
 reasonably safe than any g-s.

Depends; a version like 3.10.0 could introduce 0-days that might not get
fixed till 3.10.6, whereas a version like 3.9.11 received many fixes
and doesn't have these 0-days yet. Reasonably safe is subjective.

But that's just safe as in security, there's also safe as in
stable; versions like 3.10.0 - 3.10.2 come with a lot of rewrites, new
features and what not, a collection of stuff that was just written and
just passed the release candidate and stable queue. 3.10.0 breaks stuff.

Fixes for the introduced bugs will take a few more releases; that
3.10.3 that comes up? A whopping 100+ patches. Compare that to a version
like 3.9.11 that has not seen anything new and received lots of fixes.

This is why, for gentoo-sources, we pick kernels near the end of a
branch; they can be seen as more secure and stable than the latest
upstream stable kernel, especially since we backport important security
fixes. Like for instance has been seen with 3.7 and similar.

Now, you might wonder, why not stabilize 3.10.6 instead of waiting for
something like 3.10.12 that could be EOL? Well, while that is certainly
something we would like to do, and I have tried in the past; it didn't
work out because the stabilization teams are a bit undermanned to keep
up with stabilizing kernels this frequently. Don't forget there is
hardened-sources, you can see that they also have one kernel per
branch; their last stable kernel, awfully sits at 3.9.5. So...

Arch teams need more resources; as in man power and machine power.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Tom Wijsman
On Wed, 24 Jul 2013 21:01:30 +0200
Peter Stuge pe...@stuge.se wrote:

 I am suggesting that the latest available upstream kernel should
 perhaps be the default for Gentoo users.

See my previous e-mail; if you're willing to go through with this
suggestion, then please back that up with sufficient reasoning. That
is, state what is bad with gentoo-sources and state the advantages that
would come with vanilla-sources; but don't forget to document the
disadvantages as well, since there is no magic silver bullet here.

Would you upgrade more than hundreds to thousands of servers to 3.10.0?

Take a look at the whole picture; for example, Nouveau worked great in
late 3.6 and regressed over a lot of people in early 3.7, so they had
to wait for fixes to land in late 3.7 again. Another example? Here:

https://bugs.gentoo.org/show_bug.cgi?id=468078#c0

And there thousands of bugs to find on all the bug trackers out there
that share this kind of nature; so, this is why you can't simple mark
what upstream deems stable, but rather what our QA process deems stable.

Changing that QA process doesn't happen from one day onto the other; it
has to be carefully thought out, documented, planned and announced.

If not, it could affect Gentoo's image.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Rich Freeman
On Wed, Jul 24, 2013 at 3:15 PM, Peter Stuge pe...@stuge.se wrote:
 Ben Kohler wrote:
  I am suggesting that the latest available upstream kernel should
  perhaps be the default for Gentoo users.

 You seem to be ignoring the regressions that often come with new kernel
 releases, the very common breakage caused in stable genkernel all, and
 other various complications.  Unleashing brand new kernel.org sources on
 stable users as soon as they are released seems crazy to me.

 I don't know, I think it makes a lot of sense..

 Users who upgrade their kernels (don't upgrade if you don't want to)
 would be able to participate upstream with reports and confirmations.

How will users know which kernels they should upgrade to.  If the
latest is always the greatest then:
1.  Why wouldn't users always update 2x/week?
2.  Why doesn't every other distro do this?

The reality is that there are multiple kernel versions that are
getting updates at any time.  The latest and greatest is also the one
where all the new features are introduced, and likely all the
regressions.  Fixes are backported to older kernels which are still
supported.

Stable shouldn't track the latest kernel.  At best it should track the
latest version of an older kernel series.  It need not be an LTS one,
but it shouldn't be the current dev branch.

Also, not all fixes are equal.  The ones that are the biggest concern
are security fixes.  If you tell me that the kernel has a new exploit
2x/week then I'll start to wonder when the kernel team started
outsourcing to MS.  Most fixes provide no benefit to most users.
Upgrading kernels on Gentoo is not automatic either, especially if you
have an initramfs, complex configuration, modules in outside packages
(nvidia, virtualization, etc), and so on.

It just seems like we should be able to get by without a semiweekly
kernel upgrade on our stable branch.

Rich



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Tom Wijsman
On Wed, 24 Jul 2013 21:15:15 +0200
Peter Stuge pe...@stuge.se wrote:

 Ben Kohler wrote:
   I am suggesting that the latest available upstream kernel should
   perhaps be the default for Gentoo users.
  
  You seem to be ignoring the regressions that often come with new
  kernel releases, the very common breakage caused in stable
  genkernel all, and other various complications.  Unleashing brand
  new kernel.org sources on stable users as soon as they are released
  seems crazy to me.
 
 I don't know, I think it makes a lot of sense..
 
 Users who upgrade their kernels (don't upgrade if you don't want to)
 would be able to participate upstream with reports and confirmations.

It isn't a necessity to run the latest kernels to be supported, it
suffices to test them to see if they fix the situation or not. We look
at the fault ourselves, check newer kernels for fixes, bisect and
upstream stuff if it is out of our hand; For example with

https://bugs.gentoo.org/show_bug.cgi?id=458746#c26

we are contributing to upstream bug

https://bugzilla.kernel.org/show_bug.cgi?id=55311#c40

Of course users can do this outside of us; it's up to them, but they
should know we're always there to aid them in troubleshooting whereas
upstream might not always answer or follow through closely.

Just saying, there isn't anything that prohibits them; as long as their
version is listed on https://www.kernel.org/ they are fine.

  These releases surely bring more than just the newest fixes.
 
 It varies but sure, I think users should inform themselves about the
 new version (of any package!) before they actually upgrade it.

Some people do, some people don't; it's though to do this for every
package and every release, it also requires some basic knowledge of the
kernel to understand what is really going in the kernel world.

I agree they should inform themselves; also, we should probably also
point them at the right resources, maybe http://kernelnewbies.org/
fits better than an incomprehensible git shortlog or changelog.

Will look at that in the near future; since some documentation
and project pages are moving to the Gentoo Wiki, it makes it more easy
and accessible to add useful resources for matters like these.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Ciaran McCreesh
On Wed, 24 Jul 2013 16:40:38 -0400
Rich Freeman ri...@gentoo.org wrote:
 Also, not all fixes are equal.  The ones that are the biggest concern
 are security fixes.

Why? Which is worse: a local denial of service attack when every user
on your box has sudo access anyway, or a random data corruption bug
that can't be triggered manually and is thus not a security issue?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Tom Wijsman
On Wed, 24 Jul 2013 20:16:59 +0200
Peter Stuge pe...@stuge.se wrote:

 Alex Xu wrote:
   Maybe it would make sense to automatically stabilize every v-s
   kernel right away?
  
   As has been stated, this implies that Gentoo QA has tested the
   packages and found them to be reasonably safe for use.
   ..
   Although stable kernels *have* been tested by many people before
   use, Gentoo QA has *not* (officially) tested them, at least not
   on every architecture.
   
   I don't think that matters.
  
  If you don't care too much for Gentoo QA
 
 The point is that when arch teams find that they can not keep up with
 the pace of upstream and choose never to attempt stabilize v-s then
 clearly Gentoo QA will also not be able to keep up with that pace and
 thus Gentoo QA becomes irrelevant for the particular package.

No, stabilization of vanilla-sources would be an addition in work
required; one can not assume that if gentoo-sources is stable than
vanilla-sources is or vice versa. Also, the premise here is that
vanilla-sources would need to be stabilized every version; and not just
once per branch (we would like two or three though) as gentoo-sources.

 The original post also mentioned that generally v-s has more fixes
 than anything coming from stabilization efforts.

More fixes; but also more regressions, new features, more 0-days, ...

 It seems that for this package Gentoo QA can not realistically add
 any value to this package, hence my suggestion not to pretend that
 they can, and just remove the distinction between ~arch and arch for
 v-s, and make the latest version available to users by default.

That's a contradiction; their added value is it being deemed stable,
they can't just pretend it is stable, that overrides the distinction.

For as far that I know there is nowhere in the tree we provide matters
that walk past Gentoo; so, why should they make an exception here?

   On a technical level, it's not that hard to put
   sys-kernel/vanilla-sources in your package.accept_keywords.
   
   But why should Gentoo users have to do that in order to use v-s?
  
  So they acknowledge that vanilla-sources has not been officially
  tested by Gentoo QA.
 
 Since v-s is a special case that Gentoo QA is known not to handle,
 this overhead seems completely unneccessary to me. And the usability
 is of course poor.

If Gentoo QA can't handle it, why could our users; if they are to make
a poor sense of stability, that suffices to make it an explicit choice.

   If it is intentional to push g-s onto users then it makes good
   sense
 ..
  I can't comment on that.
 
 I guess this is really the pivotal point. If Gentoo prefers to push
 g-s rather than v-s then adding overhead for v-s kernels is fine. I'd
 prefer Gentoo to push v-s instead.

If this weren't intentional, we wouldn't be doing this; the kernel team
exists to add value and not just to blindly follow upstream.

Let me quote the project description:

With an ever increasing userbase demanding a higher quality of stable,
production-ready kernel sources and featureful desktop support the
professionalism and staffing of the kernel project is very important.

Because we as users want the best from Gentoo Linux we supply a
selection of both generic and specialised sources capable of handling
the day-to-day grind to make life a little easier.

In order to provide a rich choice of high quality kernel trees Gentoo
Linux must apply, write and test several kernel patches to the official
upstream releases before they can offer finished ebuilds to the users.
This is where the Gentoo Kernel project comes into play.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Markos Chandras
On 24 July 2013 21:59, Tom Wijsman tom...@gentoo.org wrote:
 On Wed, 24 Jul 2013 20:16:59 +0200
 Peter Stuge pe...@stuge.se wrote:

 Alex Xu wrote:
   Maybe it would make sense to automatically stabilize every v-s
   kernel right away?
  
   As has been stated, this implies that Gentoo QA has tested the
   packages and found them to be reasonably safe for use.
   ..
   Although stable kernels *have* been tested by many people before
   use, Gentoo QA has *not* (officially) tested them, at least not
   on every architecture.
  
   I don't think that matters.
 
  If you don't care too much for Gentoo QA

 The point is that when arch teams find that they can not keep up with
 the pace of upstream and choose never to attempt stabilize v-s then
 clearly Gentoo QA will also not be able to keep up with that pace and
 thus Gentoo QA becomes irrelevant for the particular package.

 No, stabilization of vanilla-sources would be an addition in work
 required; one can not assume that if gentoo-sources is stable than
 vanilla-sources is or vice versa. Also, the premise here is that
 vanilla-sources would need to be stabilized every version; and not just
 once per branch (we would like two or three though) as gentoo-sources.

 The original post also mentioned that generally v-s has more fixes
 than anything coming from stabilization efforts.

 More fixes; but also more regressions, new features, more 0-days, ...

 It seems that for this package Gentoo QA can not realistically add
 any value to this package, hence my suggestion not to pretend that
 they can, and just remove the distinction between ~arch and arch for
 v-s, and make the latest version available to users by default.

 That's a contradiction; their added value is it being deemed stable,
 they can't just pretend it is stable, that overrides the distinction.

 For as far that I know there is nowhere in the tree we provide matters
 that walk past Gentoo; so, why should they make an exception here?

   On a technical level, it's not that hard to put
   sys-kernel/vanilla-sources in your package.accept_keywords.
  
   But why should Gentoo users have to do that in order to use v-s?
 
  So they acknowledge that vanilla-sources has not been officially
  tested by Gentoo QA.

 Since v-s is a special case that Gentoo QA is known not to handle,
 this overhead seems completely unneccessary to me. And the usability
 is of course poor.

 If Gentoo QA can't handle it, why could our users; if they are to make
 a poor sense of stability, that suffices to make it an explicit choice.

   If it is intentional to push g-s onto users then it makes good
   sense
 ..
  I can't comment on that.

 I guess this is really the pivotal point. If Gentoo prefers to push
 g-s rather than v-s then adding overhead for v-s kernels is fine. I'd
 prefer Gentoo to push v-s instead.

 If this weren't intentional, we wouldn't be doing this; the kernel team
 exists to add value and not just to blindly follow upstream.

 Let me quote the project description:

 With an ever increasing userbase demanding a higher quality of stable,
 production-ready kernel sources and featureful desktop support the
 professionalism and staffing of the kernel project is very important.

 Because we as users want the best from Gentoo Linux we supply a
 selection of both generic and specialised sources capable of handling
 the day-to-day grind to make life a little easier.

 In order to provide a rich choice of high quality kernel trees Gentoo
 Linux must apply, write and test several kernel patches to the official
 upstream releases before they can offer finished ebuilds to the users.
 This is where the Gentoo Kernel project comes into play.

 --
 With kind regards,

 Tom Wijsman (TomWij)
 Gentoo Developer

 E-mail address  : tom...@gentoo.org
 GPG Public Key  : 6D34E57D
 GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

This thread derailed as usual.

The kernel team made a decision. We can simply accept it and move on.
Stable keywords imply at least a minimal build and runtime testing by
arch teams.
Since we have no manpower to do it, then stabilizing them blindly is
not appropriate.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Greg KH
On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
 Also, not all fixes are equal.  The ones that are the biggest concern
 are security fixes.

How do you _know_ which fixes are security fixes?

 If you tell me that the kernel has a new exploit
 2x/week then I'll start to wonder when the kernel team started
 outsourcing to MS.  Most fixes provide no benefit to most users.
 Upgrading kernels on Gentoo is not automatic either, especially if you
 have an initramfs, complex configuration, modules in outside packages
 (nvidia, virtualization, etc), and so on.

I'm releasing, on the average, 3 new kernel versions a week, with 100+
patches in them (for different branches.)  Sometimes more.  Please tell
me exactly how you are going to evaluate which fixes I make are security
fixes, and you know which to pick and choose from.

Trust me, it's a hard problem, people have tried it in the past, and
failed horribly :)

 It just seems like we should be able to get by without a semiweekly
 kernel upgrade on our stable branch.

You want me to slow down and do releases in larger chunks then?  Hah,
not a chance...

good luck,

greg k-h



Re: [gentoo-dev] Vanilla sources stabilization policy change

2013-07-24 Thread Rich Freeman
On Wed, Jul 24, 2013 at 7:09 PM, Greg KH gre...@gentoo.org wrote:
 On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
 It just seems like we should be able to get by without a semiweekly
 kernel upgrade on our stable branch.

 You want me to slow down and do releases in larger chunks then?  Hah,
 not a chance...


To clarify - I wasn't criticizing your release schedule or making all
those builds available in ~arch.   I was only concerned with the idea
of making all those hit stable.  I think the kernel team (including
yourself) have been doing a great job with the stable kernels in
general.

Just one other note - stable packages in general don't just benefit
from arch testing.  They also benefit from users running ~arch and
reporting issues.  Stable ebuilds are ones that have generally been
used by many others for about a month already, so issues are likely to
have been caught.

I do agree with all that has been said about there being a tradeoff
between new regressions and new fixes.  Unless we run year-old kernels
with tons of backports we're going to have that problem.  We aren't
RHEL.

Rich