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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f8c3da3a-4d19-60c6-66d3-afd0d56ef102@intel.com>
Date:   Wed, 16 Nov 2022 14:57:22 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>, Aaron Lu <aaron.lu@...el.com>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>,
        "Yin, Fengwei" <fengwei.yin@...el.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3] selftest/x86/meltdown: Add a selftest for meltdown

On 11/14/22 22:54, Greg KH wrote:
> On Tue, Nov 15, 2022 at 10:15:03AM +0800, Aaron Lu wrote:
>> I came to the conclusion that this work is OK to submit with all of the
>> steps I listed above (copyright notices, license terms and relicensing)
>> by strictly following all of the processes required by my employer.
>>
>> This does not include a Signed-off-by from a corporate attorney.
> Please get that, as that is what I asked for in order for us to be able
> to accept this type of change.

Hi Greg,

Can you share any more of what triggered this new requirement?

We can, for instance, be flexible on the license that this is submitted
with (original zlib versus GPLv2).  I've also been in contact with the
(presumed) original authors of this code in the past.  If there are
concerns about its provenance, I'd be happy to try to work with them to
get it in to shape.

But, I feel like I'm poking around in the dark here.  I'm not quite sure
what triggered this new requirement or quite how to remedy it.

I'm also a _bit_ worried that I as a maintainer was about to do
something wrong here.  Personally, I'm quite happy with Aaron's due
diligence here and I was *really* close to merging this code.  Is there
some documentation that could be improved here?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ