Hi Arpad, On Tue, Aug 6, 2013 at 4:33 AM, Arpad Ray <array...@gmail.com> wrote:
> Hi Stas, > > On Mon, Aug 5, 2013 at 8:23 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote: > >> > I'm not going to repeat my arguments against the committed solution yet >> > again, but I really think we need a better one. >> >> You are free to propose a better one. Since this topic is being >> discussed for almost 2 years and nobody came with anything better, as >> far as I know, I think it is reasonable on this stage to go with what we >> have. If you have something better that is not BC - you're welcome to >> make a pull against master, if you have something that is better and is >> BC - that's excellent, let's see it and if it works better, no problem >> getting it into 5.5. >> But as far as I see now, that is the only viable patch that we had >> during pretty long time, so sitting and waiting that something better >> comes along doesn't look like the best course of action. I think we >> waited enough so that anybody who had better solution had a chance to >> propose it and develop it, and given it is a real problem, I think at >> least solution that works for now is a good thing to have. >> > > As I've said I actually think Yasuo's original patch was a better > approach, tackling the issue in session.c instead of leaving it up to all > the handlers to implement. This would break BC but solves the major flaw of > the ini setting working with some handlers and silently failing with > others. I think it's also a cleaner approach in general. > > It's a real pity that missed the 5.5 boat. > > I'll have a think if there's a way to do this with BC, or at least to fail > better. > There is "reason" that we agreed that we do not have vote for this patch. I'll write up full description after the release, since not many people understand true risk of session adoption vulnerable session management. (I have to check browser behaviors again, though.) Please wait. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
