linux-kernel - Re: [PATCH v6 0/7] refactor file signing program

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <730c8712-1553-63e5-ffa1-d75a922f4a42@gmail.com>
Date:   Thu, 1 Jun 2023 14:33:23 +0530
From:   Shreenidhi Shedi <yesshedi@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     dhowells@...hat.com, dwmw2@...radead.org,
        linux-kernel@...r.kernel.org, sshedi@...are.com
Subject: Re: [PATCH v6 0/7] refactor file signing program

On Wed, 31-May-2023 22:20, Greg KH wrote:
> On Wed, May 31, 2023 at 09:01:24PM +0530, Shreenidhi Shedi wrote:
>> On Wed, 31-May-2023 20:08, Greg KH wrote:
>>> On Tue, Apr 25, 2023 at 04:14:49PM +0530, Shreenidhi Shedi wrote:
>>>> On Wed, 22-Mar-2023 01:03, Shreenidhi Shedi wrote:
>>>> Can you please review the latest patch series? I think I have addressed your
>>>> concerns. Thanks.
>>>
>>> The big question is, "who is going to use these new features"?  This
>>> tool is only used by the in-kernel build scripts, and if they do not
>>> take advantage of these new options you have added, why are they needed?
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> Hi Greg,
>>
>> Thanks for the response.
>>
>> We use it in VMware Photon OS. Following is the link for the same.
>> https://github.com/vmware/photon/blob/master/SPECS/linux/spec_install_post.inc#L4
>>
>> If this change goes in, it will give a slight push to our build performance.
> 
> What exactly do you mean by "slight push"?

Instead of invoking the signing tool binary for each module, we can pass 
modules in bulk and it will reduce the build time by couple of seconds.

> 
>> Can you please take these changes?
> 
> Why would we take changes for something that will not benifit us at all?

There were no remarks regarding this change being useful to all in the 
earlier review comments so I thought this will make things better.

And it is humanly impossible to create something which will benefit 
everyone. And I think this applies for lot of things that are already 
present in kernel and being maintained.

> You are asking us to maintain code that only benifits your out-of-tree
> usecase, which is not how kernel development works (and you don't want
> it to work that way...)

No problem, feel free to discard this PR.
Thanks for your time and inputs. Have a nice time ahead.

> thanks,
> 
> greg k-h

-- 
Shedi