netdev - Re: syzcaller patch postings...

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: <87d10xhxhy.fsf@linkitivity.dja.id.au>
Date:   Fri, 23 Feb 2018 02:09:29 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     Dmitry Vyukov <dvyukov@...gle.com>,
        David Miller <davem@...emloft.net>
Cc:     Paolo Abeni <pabeni@...hat.com>, syzkaller-bugs@...glegroups.com,
        netdev <netdev@...r.kernel.org>, Florian Westphal <fw@...len.de>
Subject: Re: syzcaller patch postings...

Dmitry Vyukov <dvyukov@...gle.com> writes:

> On Thu, Feb 22, 2018 at 3:35 PM, David Miller <davem@...emloft.net> wrote:
>> From: Dmitry Vyukov <dvyukov@...gle.com>
>> Date: Thu, 22 Feb 2018 10:58:07 +0100
>>
>>> Do I understand it correctly that if syzbot replies to the CC list
>>> that was in the testing request, it will resolve the problem? So if
>>> netdev wasn't in CC, it will not be added to CC.
>>>
>>> I will go and fix it now.
>>
>> I don't want syzbot to send the patch to netdev, even if it
>> was in the CC: list.
>>
>> And again this goes for netfilter-devel and linux-wireless as
>> well.
>>
>> There is no reason whatsoever for syzbot to ever post an already
>> posted patch back to the list again, even if it was on the CC:
>> list.
>>
>> In fact netdev will be on that CC: list most of the time.
>
> But if the list on CC the first time, then the patch is already on
> Patchwork, right? When syzbot replies it will add In-Reply-To, so this
> should be treated as a comment to the existing patch? Will it still
> cause problems?

You would think that it would treat it as a comment, but it doesn't.  We
treat something as a comment if and only if the subject begins with some
variant of Re:.  An I-R-T is not enough: I think the reasoning was that
people sometimes post their v2 series as replies to their v1 series,
which is bad; but we erred on the side of not losing patches.

There's not really a solid conceptual framework for this - in part
because parsing the sheer variety of mail people post is really, really
hard. Suggestions on a better algorithm are of course welcome.

> How does Patchwork understand that an email contains a patch? Perhaps
> if we make these emails appear as they don't contain a patch, it will
> solve the problem.

We have a pretty sophisticated parser that looks for things that look
like the output of diff. [FWIW, the algorithm is at
https://github.com/getpatchwork/patchwork/blob/master/patchwork/parser.py#L688 ]

You *could* try to trick it: looking at the code, probably the simplest
way would be to replace '---' in '--- a/foo/bar.c' with something else,
but I'm really quite uncomfortable with that.

Regards,
Daniel