linux-kernel - Re: [ 00/78] 3.3.2-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]

Date:	Mon, 16 Apr 2012 07:39:11 +0200
From:	Willy Tarreau <w@....eu>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk,
	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	Sujith Manoharan <c_manoha@....qualcomm.com>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [ 00/78] 3.3.2-stable review

On Mon, Apr 16, 2012 at 01:12:48AM +0300, Felipe Contreras wrote:
> I'm not going to argue the semantics of what is a revert, but I am
> going to show the difference between the two situations:
> 
> a) v3.0* (good), v3.1* (good), v3.2* (good), v3.3 (good), v3.3.1
> (bad), v3.3.2 (good), v3.4 (bad)

This situation is not possible thanks to the process : if v3.3.2 has
a fix that was not in 3.3.1, then this fix is also in 3.4.

> b) v3.0* (bad), v3.1* (bad), v3.2* (bad), v3.3 (bad), v3.3.1 (good), v3.4 (bad)

Same here.

> Maybe they are the same from certain point of view, but you just
> argued that what *others* see is what makes the patch unrevertable,
> well, it's obvious that from the point of view of the users the two
> situations are clearly different. I believe it was you who said that
> breaking user experience is the absolute no-no any project could
> make[1]--so from that point of view a) is *much* worst.
> 
> But what is done is done, and as you said, you can't change the past,
> now the important thing is what to do next. And here are the two
> options' worst-case scenarios:
> 
> a.1) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (bad), v3.3.3
> (bad), v3.3.4 (bad), v3.3.5 (bad), v3.4 (good)

This situation is stupid as it means we'd refuse to fix the issue.

> a.2) v3.0* (good), ... v3.3 (good), v3.3.1 (bad), v3.3.2 (good),
> v3.3.3 (good), v3.3.4 (good), v3.3.5 (good), v3.4 (bad)

Not possible.

> These two scenarios are unlikely, but either way, in order to
> guarantee that you don't end up with a.2) You are willing to risk
> going into a.1)

You don't seem to understand that 3.4 is not *after* 3.3.x, but in parallel.
This is more like this :

  3.2 ----- 3.3 --------- 3.4-rc* ------------- 3.4 ----- 3.5-rc* --------
               \                                    \
                \                                    `--- 3.4.1 ---- 3.4.2 --
                 \
                  `--- 3.3.1 ----- 3.3.2 ---- 3.3.3 ---- 3.3.4 --- 3.3.5 ---

Here you clearly see why everything in 3.3.x must come from upstream and
why it's important that 3.4 has every fix that 3.3 has.

> So, *obviously* v3.4 is more important than v3.3.x. I could argue that
> the users out there would prefer a.1) any day, because it's unlikely
> anyway (v3.4 would be good), but I won't.

No because for them it would mean end of support at one point when 3.3 dies,
with no ability to upgrade.

> All I want now is to agree on a reason, you have finally pointed out
> that the reason for this different treatment is the user's visibility,

It's not the user's visibility, it's published code. Once code is published,
you cannot magically fix it without emitting a new patch for this code and
announcing so that users apply it. These patches are called stable releases.
Users want a good reason to apply these patches, rebuild and reboot, and
that's one reason we absolutely want to have the commit descriptions from
upstream which detail the exact reason for the patch (even if it's a revert).

> but that still doesn't explain why the rules for b) automatically
> apply to a), since it's clearly different from the users's point of
> view; if you agree that v3.4 is more important than v3.3.x, I believe
> we have the reason right there.

It's not "more important", it's important for long-term stability. For
3.3 users, 3.3.x is more important that 3.4. However one thing is certain:
3.4 users are not going to push fixes into 3.3.x, but thanks to the process
we have, 3.3.x users are going to ask for a fix to be pushed upstream. So
users pressure ensure long-term stability.

Willy

--
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/