linux-kernel - Re: Some questions about the patching process

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: <CAMV6ehF_ExXybMO=_hZLkughDt07FkaoDLUgO0vrtZXp=f8+fg@mail.gmail.com>
Date:   Fri, 28 Aug 2020 04:11:46 -0500
From:   Qiushi Wu <wu000273@....edu>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>, Kangjie Lu <kjlu@....edu>
Subject: Re: Some questions about the patching process

On Fri, Aug 28, 2020 at 3:25 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Fri, Aug 28, 2020 at 02:59:25AM -0500, Qiushi Wu wrote:
> > Hi Greg,
> > Thanks for your response!
> >
> > > You responded in html format which got rejected by the public list,
> > > please resend in text-only and I will be glad to reply.
> > >
> > Sorry about this!
> >
> >
> > > > 1. Linux allows anyone to submit a patch because it is an open community.
> > > >
> > > And how is 1. a "risk"?
> >
> > We are assuming the possibility of potential malicious commit contributors
> > and want to reduce the risk of accepting vulnerable patches from them.
>
> No, you are thinking about this all wrong.
>
> ALL contributors make mistakes, you should not be treating anyone
> different from anyone else.  I think I probably have contributed more
> bugs than many contributors, does that make me a "malicious"
> contributor?  Or just someone who contributes a lot?

Sorry for my confusion!  I don't mean to say that our kernel
contributors are 'malicious' or some similar, and previously I have also
made mistakes and send buggy code into the kernel accidentally.
Also, we are trying to summarize the methods to efficiently auditing
patches to prevent potential issues in the patch.


> So checking on patches needs to be done for everyone, right?
>
> We have an idea of "trust" in kernel development, it's how we work so
> well.  I don't trust people not that they will always get things
> "correct", but rather that they will be around to fix it when they get
> it "wrong", as everyone makes mistakes, we are all human.
>
> So we trust people who we accept pull requests from, we don't review
> their contributions because we trust that they did, and again, they will
> fix it when it goes wrong.

agree : )


> We use lots, everything we do is in the open, I suggest doing some
> research first please.
> > Also, can these tools have a
> > high coverage rate to test corner cases like error-paths, indirect calls,
> > concurrency issues, etc?
>
> Since when does code coverage actually matter as a viable metric?
>
> Look at the tools we use, again, it's all in the open, and tell us what
> we could be doing differently by offering to help us implement those
> tools into our workflows.  That would be the best way to contribute
> here, don't you agree?
Okay, I see.

Thanks again for your patient reply, and apologies for my confusing description.

Best regards,
Qiushi