Message-ID: <dee25159-4d17-4f07-9ce5-5d23dae81301@schaufler-ca.com>
Date: Fri, 11 Oct 2024 11:01:15 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: "Dr. Greg" <greg@...ellic.com>
Cc: Paul Moore <paul@...l-moore.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Jonathan Corbet <corbet@....net>,
 Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 LKML <linux-kernel@...r.kernel.org>, linux-security-module@...r.kernel.org,
 Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [GIT PULL] tomoyo update for v6.12

On 10/11/2024 10:06 AM, Dr. Greg wrote:
> On Tue, Oct 08, 2024 at 11:25:16AM -0700, Casey Schaufler wrote:
>
> Good morning, I hope the week has gone well for everyone.
>
>> On 10/8/2024 4:14 AM, Dr. Greg wrote:
>>> ...
>>>
>>> Which we also believe justifies more attention than what it has been
>>> able to receive in 20 months.
>> You're right. You're also not alone. There are things that you can do
>> that will help get the review you're looking for. Developers who attend
>> to the needs and preferences of reviewers get a whole lot more attention
>> than those who fuss and fume about not getting what they "deserve". My
>> hopefully constructive recommendations are:
> We put a significant body of code and engineering time on the table to
> try and improve the Linux security ecosystem.  We did this because in
> certain circles the value of our approach is understood and there was
> a desire to have it more generally available.
>
> We don't believe we 'deserve' anything, review or don't review, it is
> completely up to everyone involved.
>
> Believe me when I say we are perfectly capable of supporting our
> constituencies without contributing a single line of code or comment
> back to the good of the Linux security commons.
>
> Our aggravation in all of this is when statements are made regarding
> serious and supposedly well understood flaws in our approach that
> 'everyone' agrees to be the case.  Statements that are a complete and
> utter crock of bullshit meant to simply gaslight the situation that
> has gone down.

Inflammatory claims regarding motivation are not helpful.

> Hopefully our choice of lingua franca is sufficiently simple and
> unsophisticated.

Err, no, it's not. For a complete explanation see "When Jargon Becomes Gibberish":
https://www.youtube.com/watch?v=-7cUnID7vFs

> We would, again, encourage everyone to re-read our previous e-mail
> where we outlined our concerns over the status of the review that did
> occur.
>
> We do respect reviewers, but let's engage in some sense of
> intellectual honesty.  This is not a situation of some poor lonely
> overworked individual reviewing Linux code in their mother's basement
> at night in Gulley, Minnesota while they work at the Cenex Station
> during the day.

HeeHee. There really are hobbyists in situations similar to that.
I've been one of them. To dismiss them as fictional is pretty insulting.

> Paul has publically stated that Microsoft employees him to maintain
> the Linux security system because of Microsoft's concern for the long
> term health and well being of Linux.  In case anyone doubts this or
> missed it, here is the link:

It's pretty rare that a Linux maintainer is paid to do nothing but maintain
Linux code. Developers who are qualified to be kernel maintainers are usually
in demand for other, more directly profitable, projects as well. I can't
speak directly for Paul, but I would be shocked if he gets anywhere close to
half his work time allocated to the maintainer role.

> https://lore.kernel.org/linux-security-module/20230608191304.253977-2-paul@paul-moore.com/
>
> Unfortunately our experience seems to challenge Linus' mantra of:
>
> "Code talks, bullshit walks".
>
> Perhaps times have changed for Linux in this new custodial
> environment.
>
>> 1.	Lead with code. Save the documentation for later.
>> 2.	Incremental implementation. Don't drop the whole mess on the
>> 	reviewers at once. A patch set should be a story, with each patch
>> 	introducing one new element.
>> 3.	Emphasize the similarities with existing implementations. No one
>> 	wants to deal with novel or clever code. If it is familiar, it is
>> 	easy to understand.
>> 4.	Thank your reviewers. Complaints about review latency typically
>> 	increase it.
>> 5.	Do some reviews yourself. That will get in the good graces of other
>> 	reviewers.
>> 6.	Be brief. The biggest single problem with reviewing TSEM has been that
>> 	doing anything takes so long. Multiple paragraph responses to an issue
>> 	don't help. Say it, say it once, say it in small words, and use as
>> 	few of those as possible.
> We appreciate the insight and recommendations, we will see how and
> where all of this ends up getting litigated.
>
> Given the zeal for simplicity embodied in these recommendations, we
> will assume that adversaries targeting Linux from a security
> perspective will also choose to limit themselves to simple and
> unsophisticated means and methods of attack.

Gordian Knot. Alexander. Just saying. 

>
> Have a good weekend.

Likewise.

>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
>               https://github.com/Quixote-Project
>

Powered by blists - more mailing lists