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:	Fri, 13 Apr 2012 13:29:46 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Adrian Chadd <adrian@...ebsd.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, torvalds@...ux-foundation.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 Fri, Apr 13, 2012 at 11:57 AM, Stefan Richter
<stefanr@...6.in-berlin.de> wrote:
> On Apr 12 Felipe Contreras wrote:
>> But this is exactly the opposite; the patch that broke things is in
>> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
>> also on a later upstream, which is also broken.
>            ^^^^^
> No, upstream /earlier/ than 3.3.1 contains the defect.

Time is not relevant for the point being made, but fine:

But this is exactly the opposite; the patch that broke things is in
the 'release branch' (3.3.1); it's not in the upstream release from
where stable began (3.3). Sure, it's also on upstream, which is also
broken.

> Furthermore, consider this:  You as user of the 3.3.y series are using a
> temporary, dead-end side branch.  Its maintenance will stop at some point,
> and you will be left looking for a different, maintained series to migrate
> to.  You will be most interested in that series /not/ containing any
> regressions that you suffered already through the 3.3.y lifetime.

Of course, I will be interested in that, although most likely I would
be switching to another stable release (v3.4.1), not the upstream
release (v3.4), and most distros would do the same. Even in the
unlikely event that v3.4 is broken, most likely v3.4.1 would contain
the fix. But I'm also interested in v3.3.2 working.

So you are saying that:

a) v3.3.1 (bad), v3.3.2 (bad), v3.4 (good)
b) v3.3.1 (bad), v3.3.2 (good), v3.4 (bad)
c) v3.3.1 (bad), v3.3.2 (good), v3.4 (good)

b) is clearly better than a). Well, I don't see how; both situations
have the same number of releases broken, plus b) is very unlikely
anyway and we would end up with c). Plus, in all situation v3.4.1
would most likely contain the fix anyway.

> The rule is there to protect you, as a user of the stable series, from
> repeated regressions.

So in order to avoid b), you would rather go into a), than c)? Sorry,
I most definitely don't *need* that "protection". I guess I should
avoid the "stable" series then.

Cheers.

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