geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Geronimo 2.0 Release suspended due to security issue found before release
Date Tue, 14 Aug 2007 18:24:08 GMT
At this point, I am not really sure. We can always easily move them around.

If you have or can envision a lot of CLI tests, we can create a
separate testsuite for it. This separate testsuite won't have to
start/stop selenium server too since it is cmdline.

If you want to drop it under deployment-testsuite for now, that's fine too.

Cheers
Prasad

On 8/14/07, Donald Woods <drw_web@yahoo.com> wrote:
>
> Where were you thinking?  Should we start a new subdirectory for cmdline
> tests?  Or could it go under deployment-testsuite?
>
> -Donald
>
>
> Prasad Kashyap wrote:
> > Good catch Donald. Can you please throw in a small test(s) in our
> > testsuite framework so that we can catch things like this ? There are
> > a lot of tests there already that can act as a template/example and
> > help you with your testcase.
> >
> > Let me know if you need more help.
> >
> > Cheers
> > Prasad
> >
> > On 8/13/07, Donald Woods <dwoods@apache.org> wrote:
> >>
> >> Matt Hogstrom wrote:
> >>> All,
> >>>
> >>> Earlier today one of the Geronimo committers discovered a bug in the
> >>> command line deployer where a null user / password on the deployer
> >>> command line will allow a user to deploy modules to a 2.0 server.  This
> >>> is an unacceptable security exposure and as such we have abandoned the
> >>> release of Geronimo 2.0.
> >>>
> >>> Donald Woods is going to open a JIRA for this issue and Hernan will
> >>> create a news item on our web page.
> >> GERONIMO-3404 was opened for this.
> >>
> >>> At this point we need to discuss how to move forward with a 2.0 release.
> >>>
> >>> I think we should delete the tags/2.0.0 entry and replace it with a text
> >>> file that notes the svn rev of the tree before deletion.  The purpose of
> >>> this is to avoid anyone from picking up that source tree and using it to
> >>> build a server with a known security exposure.  Unless there is
> >>> disagreement I'd like to do that tomorrow allowing some time for
> >>> discussion.  We can always put it back.
> >>>
> >>> There are several options for the 2.0 release:
> >>>
> >>> 1. Use the branches/2.0 to spin up a new release as 2.0.1.
> >>>   If we do this there are a number of fixes that need to be verified,
> >>> We'd need to close out the SNAPSHOT releases again, or at least revisit
> >>> them.
> >>>   Respin and re-tck a new release.
> >>>
> >>> 2. Take the tags/2.0.0 to create a branches/2.0.1
> >>>   This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT
> >>>   Copy the existing tag over and apply the security fixes.  Repsin and
> >>> release.
> >>>
> >>> Personally, I vote for option 2.  Based on my experience, closing out
> >>> the SNAPSHOTs is and introducing little changes will cause us to restart
> >>> the release process.
> >> +1 on option #2.
> >>
> >>
> >>> I'd like to hear other people's input but having done the release
> >>> several times option 2 is the fastest.  I think option 1 will cause us
> >>> to not release until September.
> >>>
> >>>
> >>
> >
> >
>
>

Mime
View raw message