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
> > >
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
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
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
>
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
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
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
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
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
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
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,
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
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
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
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
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
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?
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
>
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
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.
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
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
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.
> >
>
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?
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
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
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
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
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
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 :)
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
-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
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
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
-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,
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,
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
-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 --
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
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
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
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
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
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,
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
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*
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
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
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
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
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
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
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
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
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
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
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
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
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
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
76 matches
Mail list logo