linux-kernel - Re: [PATCH 5.2 000/135] 5.2.10-stable review

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: <20190824011805.GH1581@sasha-vm>
Date:   Fri, 23 Aug 2019 21:18:05 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Stefan Lippers-Hollmann <s.l-h@....de>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 5.2 000/135] 5.2.10-stable review

On Fri, Aug 23, 2019 at 10:36:27AM -0700, Greg KH wrote:
>On Fri, Aug 23, 2019 at 02:28:53AM -0400, Sasha Levin wrote:
>> On Fri, Aug 23, 2019 at 02:42:48AM +0200, Stefan Lippers-Hollmann wrote:
>> > Hi
>> >
>> > On 2019-08-22, Greg KH wrote:
>> > > On Fri, Aug 23, 2019 at 12:05:27AM +0200, Stefan Lippers-Hollmann wrote:
>> > > > On 2019-08-22, Greg KH wrote:
>> > > > > On Thu, Aug 22, 2019 at 01:05:56PM -0400, Sasha Levin wrote:
>> > [...]
>> > > > It might be down to kernel.org mirroring, but the patch file doesn't
>> > > > seem to be available yet (404), both in the wrong location listed
>> > > > above - and the expected one under
>> > > >
>> > > > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz
>> > [...]
>> > > Ah, no, it's not a mirroring problem, Sasha and I didn't know if anyone
>> > > was actually using the patch files anymore, so it was simpler to do a
>> > > release without them to see what happens. :)
>> > >
>> > > Do you rely on these, or can you use the -rc git tree or the quilt
>> > > series?  If you do rely on them, we will work to fix this, it just
>> > > involves some scripting that we didn't get done this morning.
>> >
>> > "Rely" is a strong word, I can adapt if they're going away, but
>> > I've been using them so far, as in (slightly simplified):
>> >
>> > $ cd patches/upstream/
>> > $ wget https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.2.9.xz
>> > $ xz -d patch-5.2.9.xz
>> > $ wget https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz
>> > $ gunzip patch-5.2.10-rc1.gz
>> > $ vim ../series
>> > $ quilt ...
>> >
>> > I can switch to importing the quilt queue with some sed magic (and I
>> > already do that, if interesting or just a larger amounts of patches are
>> > queuing up for more than a day or two), but using the -rc patches has
>> > been convenient in that semi-manual workflow, also to make sure to really
>> > get and test the formal -rc patch, rather than something inbetween.
>>
>> An easy way to generate a patch is to just use the git.kernel.org web
>> interface. A patch for 5.2.10-rc1 would be:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.2.y&id2=v5.2.9
>>
>> Personally this patch upload story sounded to me like a pre-git era
>> artifact...
>
>Given that we no longer do patches for Linus's -rc releases for the past
>few years, maybe it is time to move to do the same for the stable
>releases to be consistent.

Or tarballs? Why do we generate tarballs (and go through kup)?
git.kernel.org already does it for us.

--
Thanks,
Sasha