linux-kernel - Re: Linux-4.X-rcY patches can't be applied with git?

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: <CA+5PVA75o-_7GKQE58=B-Cuf9FVguHV3FbQgVN2uZaM4QC3tHg@mail.gmail.com>
Date:   Tue, 25 Oct 2016 07:36:00 -0400
From:   Josh Boyer <jwboyer@...oraproject.org>
To:     Jarod Wilson <jarod@...hat.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: Linux-4.X-rcY patches can't be applied with git?

On Mon, Oct 24, 2016 at 10:49 PM, Jarod Wilson <jarod@...hat.com> wrote:
> On Mon, Oct 24, 2016 at 05:06:42PM -0700, Linus Torvalds wrote:
>> On Mon, Oct 24, 2016 at 4:18 PM, Jarod Wilson <jarod@...hat.com> wrote:
>> >
>> > But in that case, what if your patch generation script used a filter to
>> > exclude those binary files? No harm to that target audience, and it would
>> > actually make them behave better for distro builds. Though that might be
>> > counter to the goal of making them disappear entirely. :)
>>
>> Heh, I'd rather people get the warning that "oops, something is
>> incomplete". They can still work with the end result, but at least
>> they got some indication that hey, that patch didn't work wonderfully
>> well...
>>
>> To be honest, I really would like to not do the tar-balls and patches at all.
>>
>> But maybe rather than saying "it's only for legacy 'patch' users", I
>> could just say that it's getting phased out, and say "you have to use
>> 'git apply' to apply them".
>>
>> Then I could just enable "--binary" and "-M", and see what happens.
>
> I like this idea!
>
>> I suspect that these days, git is so ubiquitous that it's ok.
>>
>> And then in a few years, maybe I can just stop doing patches entirely,
>> having proved the point that everybody already has git ;)
>
> Honestly, the only people that don't have access to git to pull down
> kernel sources? People who haven't yet got a kernel up and running, who
> will probably get there via a distro kernel. ;)

Possibly.  And to your earlier idea of generating our own diffs, we do
that for the subset of git snapshot builds we do in Rawhide between
the -rcX releases.  The problem with doing that all the time for
everything is that today the -rcX patches are signed by Linus.  Doing
it ourselves means they aren't.  Fedora/other distros could have the
maintainers sign their generated diffs but it loses some of the
verification chain.

> Side note in favor of tarballs: I know Fedora likes upstream to have
> tarballs, with checksums provided, so that packages can be verified to
> contain a legitimate upstream source tarball, rather than a random tarball
> created by the packager that could have some extraneous bits (possibly
> malicious) added to them. One can certainly examine and validate a
> generated tarball too, but it's a fair bit more work than just "does the
> checksum match?" and not as easily automated.

Right, this and the signing issue I pointed to above.

josh