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] [day] [month] [year] [list]
Message-ID: <YfVjQw1i9AYVz9e3@kroah.com>
Date:   Sat, 29 Jan 2022 16:54:43 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Kangjie Lu <kjlu@....edu>
Cc:     Karol Herbst <kherbst@...hat.com>,
        Alex Deucher <alexdeucher@...il.com>,
        Lyude Paul <lyude@...hat.com>,
        Zhou Qingyang <zhou1615@....edu>,
        David Airlie <airlied@...ux.ie>,
        nouveau <nouveau@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>, Ben Skeggs <bskeggs@...hat.com>
Subject: Re: [PATCH] drm/nouveau/acr: Fix undefined behavior in
 nvkm_acr_hsfw_load_bl()

On Sat, Jan 29, 2022 at 09:19:18AM -0600, Kangjie Lu wrote:
> > So to be explicit, so you do not misunderstand me somehow:
> >
> >         No more patches from umn.edu should be accepted into the Linux
> >         kernel until further public notice.
> 
> This is clear to me.
> 
> > They should be considered a
> >         "bad actor" given their prior history of submissions and lack of
> >         complying with the kernel community's prior requirements to
> >         them.
> 
> I am sorry for the delay of the last process which is unfortunately
> not under the control of the researchers. According to our
> administration, the process has started and is moving forward. I hope
> that can be done soon.

Given that our previously agreed-upon requirements were not met, I do
not think that finally meeting these requirements when caught that you
were not following them is going to be acceptable to allow your
organization to return to the kernel community.

Your people have shown bad-faith toward us too many times, and we have
wasted too much of our own time and energy on this for absolutely no
benefit at all, except as an example to point others at and say "do not
be like them."

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ