axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruchith Fernando" <ruchith.ferna...@gmail.com>
Subject Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)
Date Wed, 09 Jul 2008 10:44:13 GMT
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


Mime
View raw message