struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <ted.hus...@gmail.com>
Subject Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Date Thu, 16 Feb 2006 15:51:02 GMT
If someone is going to manage a 1.2.9 release, then, yes, it would
make sense for someone to make the necessary changes to 1.3 before we
mark it GA. (It just isn't going to be me.)

But, if we are doing this because it's a security hole (and I don't
agree it is), then we should also patch and re-release Struts 1.1,
which many more people are using. The behavior has existed from day
one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1
obsolete, then perhaps we should focus on stablizing Struts 1.3 so as
to make 1.2 obsolete too.

As to any other changes, if Wendy doesn't mind, and someone wants to
make those and also help finish up on the 1.3.0 release, I'm not going
to argue. But, I would have to remove my name as release co-manager,
since I just don't have any more time to spend on 1.3.0 right now. If
someone else can do it, that would be great, it's just that I can't.

If some people feel these patches are a problem, then we can always
keep Action 1.3.0 as a test-build, until someone has time to apply
them and roll an Action 1.3.1 (note that the other six subprojects
would *not* have to tagged and rolled again, only the one we change).

The important thing, I think, is to get past the point having to
release everything all at once. Then we can address any other issues
in an agile, release-often, way. Otherwise, it will always be
something, and a week will turn into a month, which turns into another
quarter.

-Ted.

On 2/16/06, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> My view is that this is "security hole" that we are fixing, not adding
> a new feature. I also think that the original RequestProcessor and
> TilesRequestProcessor offer people a way of upgrading to 1.3 and use
> tried and tested code - without having to adopt the CoR
> implementation.
>
> Since I have implemented the Cancellable behaviour in the 1.2.x
> branch, then either it needs also applying to the 1.3 branch or that
> change needs to be reversed.
>
> We probably should release a Struts 1.2.9 to fix this issue and the
> "DOS attack" issue and I am willing to do that - probably have time in
> a couple of weeks.
>
> > If this change prompts anyone to change their vote, please chime-in
> > now. A release plan is a majority vote, so we need three binding +1s
> > from PMC members and more binding +1s than -1s. A +1 here is on the
> > tagging the repository. A quality vote would follow once the test
> > builds are posted.
>
> I realize the plan vote and quality vote are separte issues, but IMO
> the DOS attack bug is v.serious - you can stop a whole web app from
> working using it - and I don't understand why were not fixing it in
> 1.3.0. IMO 1.3.0 is never going to be more than a beta with this "DOS
> attack" bug - or with the original request processor "cancellable"
> security hole. Both are really bad.
>
> Niall

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message