linux-kernel - Re: AUTOSEL 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxiJPvKh5VzoP=9xamFfU78r3J25pwW6GQyAUN7YPJk=dQ@mail.gmail.com>
Date:   Sun, 12 Mar 2023 09:42:59 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Willy Tarreau <w@....eu>, "Theodore Ts'o" <tytso@....edu>,
        Sasha Levin <sashal@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, viro@...iv.linux.org.uk,
        linux-fsdevel@...r.kernel.org,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: AUTOSEL process

On Sun, Mar 12, 2023 at 7:41 AM Eric Biggers <ebiggers@...nel.org> wrote:
>
...
> I mean, "patches welcome" is a bit pointless when there is nothing to patch, is
> it not?  Even Sasha's stable-tools, which he finally gave a link to, does not
> include anything related to AUTOSEL.  It seems AUTOSEL is still closed source.
>
> BTW, I already did something similar "off to the side" a few years ago when I
> wrote a script to keep track of and prioritize syzbot reports from
> https://syzkaller.appspot.com/, and generate per-subsystem reminder emails.
>
> I eventually ended up abandoning that, because doing something off to the side
> is not very effective and is hard to keep up with.  The right approach is to
> make improvements to the "upstream" process (which was syzbot in that case), not
> to bolt something on to the side to try to fix it after the fact.
>
> So I hope people can understand where I'm coming from, with hoping that what the
> stable maintainers are doing can just be improved directly, without first
> building something from scratch off to the side as that is just not a good way
> to do things.  But sure, if that's the only option to get anything nontrivial
> changed, I'll try to do it.
>

Eric,

Did you consider working to improve or add functionality to b4?

Some of the things that you proposed sound like a natural extension of
b4 that stable maintainers could use if they turn out to be useful.

Some of the things in your wish list, b4 already does - it has a local
cache of messages from query results, it can find the latest submission
of a patch series.

When working on backporting xfs patches to LTS, I ended up trying to
improve and extend b4 [1].

My motivation was to retrieve the information provided in the pull request
and cover letters which often have much better context to understand
whether patches are stable material.

My motivation was NOT to improve automatic scripts, but I did make
some improvement to b4 that could benefit automatic scripts as well.

Alas, despite sending a pull request via github and advertising my work
and its benefits on several occasions, I got no feedback from Konstantin
nor from any other developers, so I did not pursue upstreaming.

If you find any part of this work relevant, I can try to rebase and
post my b4 patches.

Thanks,
Amir.

[1] https://github.com/mricon/b4/pull/1