Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of ruchith.fernando@gmail.com
 designates 209.85.142.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=ONIEYCQGwJwLAWwPhMRjCk2xc5MJoiPvS2DzSuNZ9+X0tY0ZPNRMLSb8RGWrP3HA6m
         h77CHRk8SeSqtuqnssRjarLV0Ow84fFzUcP/AKK/NcY/KGJAZp9SInUvxjTc11sJJBss
         u3SRyCV/qCFijP78JF4am0/x8q+dxK/ztCu0Y=
Message-ID: <559c463d0807090344y67653acam58611bdd3a4bebd1@mail.gmail.com>
Date: Wed, 9 Jul 2008 16:14:13 +0530
From: "Ruchith Fernando" <ruchith.fernando@gmail.com>
To: axis-dev@ws.apache.org
Subject: Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in
 Axis2 1.4 + Rampart 1.4)
In-Reply-To: <aa8fdb10807090303v2ef179eese1dced4cf720366c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <19e0530f0807070533o38485e27kc5b60511386000a1@mail.gmail.com>
	 <60708f4b0807070609id1d6786w9ee73c00aee2fae4@mail.gmail.com>
	 <4872160B.1080601@gmail.com> <48721B37.1060208@thoughtcraft.com>
	 <48721CB9.3030503@gmail.com> <4874611E.1080204@opensource.lk>
	 <aa8fdb10807090303v2ef179eese1dced4cf720366c@mail.gmail.com>

IMHO when it comes to .mar files we should version them as "x.yz"

In the case of 1.4.1 release the mar file versions can be: 1.41

This confirms to the module version constraints of Axis2.

Thanks,
Ruchith

On Wed, Jul 9, 2008 at 3:33 PM, Saminda Abeyruwan <samindaa@gmail.com> wrote:
> Guys, Axis2 module follow the version semantics of
>
> [major.minor]
>
> Thus, having addressing-1.4.1.mar will cause problem in version resolution.
>
> Am I making an absurd assumption here ?
>
> Saminda
>
> On Wed, Jul 9, 2008 at 12:26 PM, Deepal Jayasinghe <deepal@opensource.lk>
> wrote:
>>
>> Hehe :)
>>
>> I was wondering why did Glen tell that , I even went and read old mails :)
>>
>> Davanum Srinivas wrote:
>>>
>>> s/Deepal/Dims/ ? :)
>>>
>>> Glen Daniels wrote:
>>> |
>>> | Deepal, what are you so worried about, exactly?  That it will take
>>> | forever to get the release out?
>>> |
>>> | IMHO, a point release is for fixing critical issues, and should not
>>> | necessarily be limited to one particular issue.  I think we should run
>>> | this basically just like a regular release but with a much shorter
>>> | timeframe.  My suggestion:
>>> |
>>> | - Let's aim to get 1.4.1 out the door at the end of next week, i.e.
>>> July
>>> | 18th (is that enough time, Nandana?).
>>> |
>>> | - As always it's good to go through at least one RC so people can kick
>>> | the tires, check the artifacts, etc.  So let's aim to get the RC out by
>>> | Tuesday the 15th.
>>> |
>>> | - Backing up, this allows a week (from today through next Monday) for
>>> | development work, during which time I think people should be able to
>>> fix
>>> | anything they consider critical (of course, with no new functionality).
>>> |
>>> | - As RM, Nandana gets the final say as to what gets checked in to the
>>> | branch and what does not.
>>> |
>>> | Thoughts?
>>> |
>>> | --Glen
>>> |
>>> | Davanum Srinivas wrote:
>>> | Exactly what i was afraid of :( Sigh! this is a *very* slippery slope.
>>> |
>>> | -- dims
>>> |
>>> | Amila Suriarachchi wrote:
>>> | | On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <davanum@gmail.com>
>>> | wrote:
>>> | |
>>> | |> Nandana,
>>> | |>
>>> | |> +1 from me for you to be the Release Manager for 1.4.1
>>> | |
>>> | |
>>> | | + 1 from me.
>>> | |
>>> | |>
>>> | |> IMHO, we should use 1.4 branch. The *ONLY* change should be the
>>> | |> security change. Nothing more.
>>> | |
>>> | | I think we need to fix any possible other critical issues as well.
>>> | | eg. https://issues.apache.org/jira/browse/AXIS2-3870
>>> | | This is a memory leak and we need to fix this.
>>> | |
>>> | | thanks,
>>> | | Amila.
>>> | |
>>> | |
>>> | |
>>> | |>
>>> | |> thanks,
>>> | |> dims
>>> | |>
>>> | |> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
>>> | |> <nandana.cse@gmail.com> wrote:
>>> | |>> I would like to volunteer to be the release manager for Axis2
>>> 1.4.1.
>>> | |>>
>>> | |>> I think we can fix the critical issues in the 1.4 branch (or a
>>> 1.4.1
>>> | |> branch
>>> | |>> ) and do the 1.4.1 release. I don't think doing 1.4.1 from the
>>> | trunk is
>>> | |> the
>>> | |>> appropriate way as trunk is now java 1.5 and has lot of major
>>> changes
>>> | |> after
>>> | |>> Axis2 1.4 . However we can fix any issues that are not already
>>> | fixed in
>>> | |> the
>>> | |>> trunk at the same time when we fix those in the branch.
>>> | |>>
>>> | |>> Hope this is oky with Axis2 release guidelines.
>>> | |>>
>>> | |>> thanks,
>>> | |>> nandana
>>> | |>>
>>> | |>> On Tue, Jul 1, 2008 at 6:39 PM, Davanum Srinivas
>>> <davanum@gmail.com>
>>> | |> wrote:
>>> | |>>> IMHO, The logic is the same as for blockers. If there is a work
>>> | |>>> around, it's not a blocker. So i am +0 on a 1.4.1 since there is a
>>> | |>>> work around that can be documented.
>>> | |>>>
>>> | |>>> That said, If someone is willing to drive a 1.4.1 as the release
>>> | |>>> manager, please do go ahead.
>>> | |>>>
>>> | |>>> thanks,
>>> | |>>> dims
>>> | |>>>
>>> | |>>> On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake
>>> | <ssanka@gmail.com>
>>> | |>>> wrote:
>>> | |>>>> Hi,
>>> | |>>>>
>>> | |>>>> For the users who is already using 1.4 version, the workaround
>>> | would
>>> | |> be
>>> | |>>>> to
>>> | |>>>> define policies in services.xml without using
>>> | <wsa:PolicyAttachment>.
>>> | |>>>> Then
>>> | |>>>> the problem is that those policies will appear in <wsdl:PortType>
>>> | |> which
>>> | |>>>> is
>>> | |>>>> not correct but security will apply for both format of service
>>> | URLs.
>>> | |>>>>
>>> | |>>>> Hence +1 for fixing that issue and do 1.4.1 release.
>>> | |>>>>
>>> | |>>>> Thanks,
>>> | |>>>> Sanka
>>> | |>>>>
>>> | |>>>>
>>> | |>>>> On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya
>>> | |>>>> <nandana.cse@gmail.com> wrote:
>>> | |>>>>> Hi,
>>> | |>>>>>    There are few issues with Axis2 1.4 / Rampart 1.4 with the
>>> new
>>> | |>>>>> policy
>>> | |>>>>> configuration. The new policy configuration which allows us to
>>> | apply
>>> | |>>>>> policies to binding hierarchy is a great feature when in comes
>>> | to ws
>>> | |>>>>> security policy configuration. It allows security policies to be
>>> | |>>>>> attached to
>>> | |>>>>> the correct attachment points. But there are few issues that
>>> | need to
>>> | |> be
>>> | |>>>>> fixed in Axis2 1.4. I will list them below.
>>> | |>>>>>     1.) If we configure security using new configuration,
>>> | service can
>>> | |>>>>> be
>>> | |>>>>> accessed without security.
>>> | |>>>>>          In Axis2 1.4, a service is exposed in two EPRs
>>> (consider
>>> | |> SOAP
>>> | |>>>>> 1.1
>>> | |>>>>> binding).
>>> | |>>>>>            eg.
>>> | |>>>>>
>>> | |>>>>>
>>> | |>>>>>
>>> | |>
>>> |
>>> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>>> |
>>> | |>>>>>
>>>  http://localhost:8080/axis2/services/SecureService
>>> | |>>>>>           But if we you set the policies using the new
>>> | configuration,
>>> | |>>>>> if
>>> | |>>>>> you do a web service call to the older EPR, you can access the
>>> | |> service
>>> | |>>>>> without any security even though it is secured using the binding
>>> | |>>>>> hierarchy.
>>> | |>>>>> This happens because if we call the old EPR, it is not
>>> | dispatched to
>>> | |> a
>>> | |>>>>> binding. But this leaves the service vulnerable. I think we
>>> should
>>> | |>>>>> dispatch
>>> | |>>>>> to one of the bindings may be using soap envelope version if we
>>> | have
>>> | |>>>>> only
>>> | |>>>>> one binding with that soap version. We should have a way to
>>> | dispatch
>>> | |>>>>> messages which comes to old EPR to one of the bindings else we
>>> | should
>>> | |>>>>> have
>>> | |>>>>> an option to disable that EPR.
>>> | |>>>>>
>>> | |>>>>>     2.) In the out flow, policies are not set correctly in the
>>> | |> binding
>>> | |>>>>> message.
>>> | |>>>>>           This is fixed in the trunk but this bug is there in
>>> | Axis2
>>> | |>>>>> 1.4.
>>> | |>>>>>
>>> | |>>>>>    So the option we have is to configure security using the old
>>> | |>>>>> configuration. But then the problem is policies are attached to
>>> | the
>>> | |>>>>> port
>>> | |>>>>> type which is the correct way to do if we have policies using
>>> | |>>>>> <service>,<operation><message> tags. But this makes Axis2 not
>>> | |>>>>> interoperable
>>> | |>>>>> as security policies should be attached to binding hierarchy
>>> | |> according
>>> | |>>>>> WS
>>> | |>>>>> Security policy specification. Ideally we should always use the
>>> | new
>>> | |>>>>> configuration to apply security. And code generation also
>>> doesn't
>>> | |> work
>>> | |>>>>> correctly when the policies attached to the port type (polices
>>> are
>>> | |> not
>>> | |>>>>> correctly attached to the stub).
>>> | |>>>>>
>>> | |>>>>>    So I think it would be great if can consider a Axis2 1.4.1
>>> with
>>> | |>>>>> these
>>> | |>>>>> things fixed.
>>> | |>>>>>
>>> | |>>>>> thanks,
>>> | |>>>>> nandana
>>> | |>>>>
>>> | |>>>> --
>>> | |>>>> Sanka Samaranayake
>>> | |>>>> WSO2 Inc.
>>> | |>>>>
>>> | |>>>> http://sankas.blogspot.com/
>>> | |>>>> http://www.wso2.org/
>>> | |>>>
>>> | |>>>
>>> | |>>> --
>>> | |>>> Davanum Srinivas :: http://davanum.wordpress.com
>>> | |>>>
>>> | |>>>
>>> | ---------------------------------------------------------------------
>>> | |>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> | |>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>> | |>>>
>>> | |>
>>> | |>
>>> | |> --
>>> | |> Davanum Srinivas :: http://davanum.wordpress.com
>>> | |>
>>> | |>
>>> ---------------------------------------------------------------------
>>> | |> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> | |> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>> | |>
>>> | |>
>>> | |
>>> | |
>>> |>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>> |>
>>>
>>> | ---------------------------------------------------------------------
>>> | To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> | For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>>
>>
>> --
>> Thanks,
>> Deepal
>> ................................................................
>> http://blogs.deepal.org/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>
>
>
> --
> Saminda Abeyruwan
>
> Senior Software Engineer
> WSO2 Inc. - www.wso2.org


-- 
http://blog.ruchith.org
http://wso2.org

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