linux-kernel - Re: [GIT] Security subsystem changes for 2.6.38

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: <AANLkTikDBpw17OwKvhpq3LqPrurCseWrCyw4VQF=xZY4@mail.gmail.com>
Date:	Thu, 13 Jan 2011 13:39:49 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Morris <jmorris@...ei.org>
Cc:	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT] Security subsystem changes for 2.6.38

On Thu, Jan 13, 2011 at 1:29 PM, James Morris <jmorris@...ei.org> wrote:
>
> The most common cases are to resolve a conflict, or to apply a patch which
> depends on something in your tree, neither of which are really directly
> associated with tags.

So? Seriously. Neither are they "really directly associated with
branch 'linus'". So what's the advantage of picking a random spot, and
not even explaining it?

At least with "Merge tag 'v2.6.37'" or similar, there's some reason to
believe that the spot you picked was meaningful.

The thing is, those back-merges make it much harder to bisect stuff,
and make it much harder to test the things you send me independently -
because the commits don't exist independently, but are tied in to
random daily snapshots. If somebody reports a problem, I can't ask
them to just check the tip commit of the merge, they'll have to test
all the random stuff that went into my tree too.

Right now, for example, depending on your graphics card, you may not
have working X at all. Did you happen to merge one of those trees? I
don't know, and you don't know. So imagine that your tree introduces
some problem, and somebody who happens to have one of those graphics
cards would notice. How does he test?

And if it was _one_ merge, I'd understand. But there's several. Why
would you care about "resolve a conflict" anyway? The conflict doesn't
even _exist_ unless you merge, so merging to resolve a conflict is a
nonsensical notion. And during the merge window, we'd certainly hope
that your code doesn't depend on other peoples code, since that hasn't
been merged yet, and the merge window was for merging code that was
ready _before_ the merge window.

Yes, yes, there can sometimes be real dependencies. It happens. But it
should be rare, and it should be seen as a problem, not a "ok, let's
do several merges".

So the mindset people should have is to avoid back-merges,
_especially_ the "random daily" ones. And if you do them, explain
them.

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/