On 9/15/2022 7:27 AM, Tetsuo Handa wrote:
> On 2022/09/14 22:56, Paul Moore wrote:
>> On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa
>> wrote:
>>> Inclusion into upstream is far from the goal.
>> For better or worse, there is a long history of the upstream Linux
>> Kernel focusing only on in-tree ke
On 9/15/22 07:27, Tetsuo Handa wrote:
On 2022/09/15 0:50, Casey Schaufler wrote:
On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
Please distinguish the difference between "enable" and "support" at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
I hate the word "support", for nobo
On 2022/09/15 16:45, John Johansen wrote:
> On 9/14/22 06:57, Tetsuo Handa wrote:
> for some users, but having a very well defined support surface also has its
> place. From a distro POV support is expensive and its amazing what users
> will do and try to hide while trying to get support.
>
I kno
On 2022/09/15 0:50, Casey Schaufler wrote:
> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>> Please distinguish the difference between "enable" and "support" at
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>> I hate the word "support", for nobody can share agreed definition.
On 2022/09/14 22:56, Paul Moore wrote:
> On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa
> wrote:
>> Inclusion into upstream is far from the goal.
>
> For better or worse, there is a long history of the upstream Linux
> Kernel focusing only on in-tree kernel code, I see no reason why we
> should cha
On 9/14/22 06:57, Tetsuo Handa wrote:
On 2022/09/13 23:45, Casey Schaufler wrote:
. A security module that manages loadable LSM modules cannot give us a good
answer
if there is a kernel config option to disable the manager security module.
The community that is absolutely opposed to loadable
