[Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Davanum Srinivas]

Nandana,

+1 from me for you to be the Release Manager for 1.4.1

IMHO, we should use 1.4 branch. The *ONLY* change should be the
security change. Nothing more.

thanks,
dims

On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> wrote:
>> > Hi,
>> >
>> > For the users who is already using 1.4 version, the workaround would be
>> > to
>> > define policies in services.xml without using .
>> > Then
>> > the problem is that those policies will appear in  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
>> > <[EMAIL PROTECTED]> 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
>> >> , 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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Amila Suriarachchi]

On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> >> wrote:
> >> > Hi,
> >> >
> >> > For the users who is already using 1.4 version, the workaround would
> be
> >> > to
> >> > define policies in services.xml without using .
> >> > Then
> >> > the problem is that those policies will appear in 
> 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
> >> > <[EMAIL PROTECTED]> 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
> >> >> , 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/
> >>
> >>

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Davanum Srinivas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 <[EMAIL PROTECTED]> 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
|> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
|> 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 <[EMAIL PROTECTED]>
|>>> wrote:
| Hi,
|
| For the users who is already using 1.4 version, the workaround would
|> be
| to
| define policies in services.xml without using .
| Then
| the problem is that those policies will appear in 
|> 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
| <[EMAIL PROTECTED]> 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
|> , 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 Sama

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Glen Daniels]

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:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 <[EMAIL PROTECTED]> 
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
|> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
|> 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 <[EMAIL PROTECTED]>
|>>> wrote:
| Hi,
|
| For the users who is already using 1.4 version, the workaround would
|> be
| to
| define policies in services.xml without using .
| Then
| the problem is that those policies will appear in 
|> 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
| <[EMAIL PROTECTED]> 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, polic

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Davanum Srinivas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 <[EMAIL PROTECTED]>
| 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
| |> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
| |> 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
| <[EMAIL PROTECTED]>
| |>>> wrote:
| | Hi,
| |
| | For the users who is already using 1.4 version, the workaround
| would
| |> be
| | to
| | define policies in services.xml without using
| .
| | Then
| | the problem is that those policies will appear in 
| |> 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
| | <[EMAIL PROTECTED]> 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

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Glen Daniels]

Davanum Srinivas wrote:

s/Deepal/Dims/ ? :)


Oh for crying out... sorry Dims!!!  I was just reading a bunch of the 
JIRA edits from Deepal (and haven't had coffee yet today).  *blush*


--G

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Glen Daniels]

Two more things.

1) Obviously +1 to Nandana as RM, which I forgot to say explicitly. :)

2) To be crystal clear, my suggestion is to time-bound the release and 
ONLY fix what can be finished in the allotted time, which should prevent 
the slippery slope problem.  If people want we can also switch to a 
review-then-commit pattern for the branch, where patches get submitted 
and Nandana commits them after vetting


--Glen

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:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 <[EMAIL PROTECTED]> 
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
|> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
|> 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 
<[EMAIL PROTECTED]>

|>>> wrote:
| Hi,
|
| For the users who is already using 1.4 version, the workaround 
would

|> be
| to
| define policies in services.xml without using 
.

| Then
| the problem is that those policies will appear in 
|> 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
| <[EMAIL PROTECTED]> 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 t

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Nandana Mihindukulasooriya]

Hi Glen,

- 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?).


I  think we have to check Sanka's input on this. He will be fixing the major
issue in policy.

- 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.


+1 for the RC.

thanks,
nandana

Davanum Srinivas wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> 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 <[EMAIL PROTECTED]>
>> 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
>> |> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> |> 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 <[EMAIL PROTECTED]
>> >
>> |>>> wrote:
>> | Hi,
>> |
>> | For the users who is already using 1.4 version, the workaround would
>> |> be
>> | to
>> | define policies in services.xml without using
>> .
>> | Then
>> | the problem is that those policies will appear in 
>> |> 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
>> | <[EMAIL PROTECTED]> 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 

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Asankha C. Perera]

Nandana,

+1 from me for you to be the Release Manager for 1.4.1


+1 for Nandana as the release manager

Nandana
I would also like to suggest 
https://issues.apache.org/jira/browse/AXIS2-3887 for inclusion, as this 
prevents Synapse from using the servlet transport effectively, since it 
sends faults always using an HTTP 200 instead of 500. This is a 10 line 
fix, and I can commit it to the 1.4.1 branch if you approve this


thanks
asankha

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Sanka Samaranayake]

On Mon, Jul 7, 2008 at 7:39 PM, Nandana Mihindukulasooriya <
[EMAIL PROTECTED]> wrote:

> Hi Glen,
>
> - 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?).
>
>
> I  think we have to check Sanka's input on this. He will be fixing the
> major issue in policy.
>


IMO, proper fix would be to improve Axis2 Dispatchers to set the
AxisBindings in the MessageContext during the dispatch phase based on
properties of incoming message even if client request came to the old format
of service URL. For example for a message that came to older format of the
service URL, the Dispatches can decide whether it belongs to the SOAP11 or
SOAP12 or HTTP binding based on envelope namespace URI and content type .
That way effective policy calculation will always happen based on the
AxisBindings which will ensure the application of security irrespective of
the format of service URL.

Thanks,
Sanka





>
>
> - 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.
>
>
> +1 for the RC.
>
> thanks,
> nandana
>
> Davanum Srinivas wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> 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 <[EMAIL PROTECTED]>
>>> 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
>>> |> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>> |> 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 <
>>> [EMAIL PROTECTED]>
>>> |>>> wrote:
>>> | Hi,
>>> |
>>> | For the users who is already using 1.4 version, the workaround
>>> would
>>> |> be
>>> | to
>>> | define policies in services.xml without using
>>> .
>>> | Then
>>> | the problem is that those policies will appear in 
>>> |> 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
>>> | <[EMAIL PROTECTED]> 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
>>> confi

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Ruchith Fernando]

+1 for Nandana as the release manager.

Thanks,
Ruchith

On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Nandana,
>
> +1 from me for you to be the Release Manager for 1.4.1
>
> IMHO, we should use 1.4 branch. The *ONLY* change should be the
> security change. Nothing more.
>
> thanks,
> dims
>
> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>> wrote:
>>> > Hi,
>>> >
>>> > For the users who is already using 1.4 version, the workaround would be
>>> > to
>>> > define policies in services.xml without using .
>>> > Then
>>> > the problem is that those policies will appear in  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
>>> > <[EMAIL PROTECTED]> 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
>>> >> , 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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>
>
>
> --
> Davanum Srinivas :: http://davanum

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Deepal Jayasinghe]

+1

Thank you!
Deepal

Davanum Srinivas wrote:

Nandana,

+1 from me for you to be the Release Manager for 1.4.1

IMHO, we should use 1.4 branch. The *ONLY* change should be the
security change. Nothing more.

thanks,
dims

On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
wrote:
  

Hi,

For the users who is already using 1.4 version, the workaround would be
to
define policies in services.xml without using .
Then
the problem is that those policies will appear in  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
<[EMAIL PROTECTED]> 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
, 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  




  


--
Thanks,
Deepal

http://blogs.deepal.org/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Deepal Jayasinghe]

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 <[EMAIL PROTECTED]>
| 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
| |> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
| |> 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
| <[EMAIL PROTECTED]>
| |>>> wrote:
| | Hi,
| |
| | For the users who is already using 1.4 version, the workaround
| would
| |> be
| | to
| | define policies in services.xml without using
| .
| | Then
| | the problem is that those policies will appear in 
| |> 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
| | <[EMAIL PROTECTED]> 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 servi

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Saminda Abeyruwan]

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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
>> | 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
>> | |> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
>> >
>> | |> 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
>> | <[EMAIL PROTECTED]>
>> | |>>> wrote:
>> | | Hi,
>> | |
>> | | For the users who is already using 1.4 version, the workaround
>> | would
>> | |> be
>> | | to
>> | | define policies in services.xml without using
>> | .
>> | | Then
>> | | the problem is that those policies will appear in 
>> | |> 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
>> | | <[EMAIL PROTECTED]> 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

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Nandana Mihindukulasooriya]

But it seems that we have done an Axis2 1.1.1 with adressing-1.1.1.mar and
soapmonitor-1.1.1.mar modules.  Will this be a problem ?

thanks,
nandana

On Wed, Jul 9, 2008 at 3:33 PM, Saminda Abeyruwan <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
>>> | 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
>>> | |> <[EMAIL PROTECTED]> 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 <
>>> [EMAIL PROTECTED]>
>>> | |> 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
>>> | <[EMAIL PROTECTED]>
>>> | |>>> wrote:
>>> | | Hi,
>>> | |
>>> | | For the users who is already using 1.4 version, the workaround
>>> | would
>>> | |> be
>>> | | to
>>> | | define policies in services.xml without using
>>> | .
>>> | | Then
>>> | | the problem is that those policies will appear in 
>>> | |> 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
>>> | | <[EMAIL PROTECTED]> 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 

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Ruchith Fernando]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
>>> | 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
>>> | |> <[EMAIL PROTECTED]> 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
>>> <[EMAIL PROTECTED]>
>>> | |> 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
>>> | <[EMAIL PROTECTED]>
>>> | |>>> wrote:
>>> | | Hi,
>>> | |
>>> | | For the users who is already using 1.4 version, the workaround
>>> | would
>>> | |> be
>>> | | to
>>> | | define policies in services.xml without using
>>> | .
>>> | | Then
>>> | | the problem is that those policies will appear in 
>>> | |> 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
>>> | | <[EMAIL PROTECTED]> 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 fea

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Lahiru Sandakith]

+1 for Nandana as the Release Manager

Regards
Lahiru Sandakith

On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED]> wrote:

> Nandana,
>
> +1 from me for you to be the Release Manager for 1.4.1
>
> IMHO, we should use 1.4 branch. The *ONLY* change should be the
> security change. Nothing more.
>
> thanks,
> dims
>
> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> >> wrote:
> >> > Hi,
> >> >
> >> > For the users who is already using 1.4 version, the workaround would
> be
> >> > to
> >> > define policies in services.xml without using .
> >> > Then
> >> > the problem is that those policies will appear in 
> 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
> >> > <[EMAIL PROTECTED]> 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
> >> >> , 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
> >>
> >> 

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Thilina Gunarathne]

+1 for Nandana as the release manager..

thanks,
Thilina

On Wed, Jul 9, 2008 at 4:55 AM, Lahiru Sandakith <[EMAIL PROTECTED]>
wrote:

>
> +1 for Nandana as the Release Manager
>
> Regards
> Lahiru Sandakith
>
>
> On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED]>
> wrote:
>
>> Nandana,
>>
>> +1 from me for you to be the Release Manager for 1.4.1
>>
>> IMHO, we should use 1.4 branch. The *ONLY* change should be the
>> security change. Nothing more.
>>
>> thanks,
>> dims
>>
>> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > For the users who is already using 1.4 version, the workaround would
>> be
>> >> > to
>> >> > define policies in services.xml without using .
>> >> > Then
>> >> > the problem is that those policies will appear in 
>> 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
>> >> > <[EMAIL PROTECTED]> 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
>> >> >> , 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,
>> >> >> na

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[sumedha rubasinghe]

+1 for Nandana as the release manager.
/sumedha

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Amila Suriarachchi]

On Wed, Jul 9, 2008 at 9:40 AM, Sanka Samaranayake <[EMAIL PROTECTED]> wrote:

>
>
> On Mon, Jul 7, 2008 at 7:39 PM, Nandana Mihindukulasooriya <
> [EMAIL PROTECTED]> wrote:
>
>> Hi Glen,
>>
>> - 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?).
>>
>>
>> I  think we have to check Sanka's input on this. He will be fixing the
>> major issue in policy.
>>
>
>
> IMO, proper fix would be to improve Axis2 Dispatchers to set the
> AxisBindings in the MessageContext during the dispatch phase based on
> properties of incoming message even if client request came to the old format
> of service URL. For example for a message that came to older format of the
> service URL, the Dispatches can decide whether it belongs to the SOAP11 or
> SOAP12 or HTTP binding based on envelope namespace URI and content type .
> That way effective policy calculation will always happen based on the
> AxisBindings which will ensure the application of security irrespective of
> the format of service URL.
>

Seems to be good. What happens,
1. There is not SOAP 11Binding for a SOAP 11 message
2. There are two SOAP 11 Bindings for a SOAP 11 message.

I think in both cases we have to throw an exception.

thanks,
Amila.

>
>
> Thanks,
> Sanka
>
>
>
>
>
>>
>>
>>  - 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.
>>
>>
>> +1 for the RC.
>>
>> thanks,
>>  nandana
>>
>> Davanum Srinivas wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 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 <[EMAIL PROTECTED]>
 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
 |> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]
 >
 |> 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 <
 [EMAIL PROTECTED]>
 |>>> wrote:
 | Hi,
 |
 | For the users who is already using 1.4 version, the workaround
 would
 |> be
 | to
 | define policies in services.xml without using
 .
 | Then
 | the problem is that those policies will appear in 
 |> 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
 | <[EMAIL PROTECTED]> 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
 

Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)

[Hans Guldager Knudsen]

+1 for Nandana as the Release Manager


I would also like to see the memory leak fixed for a 1.4.1 release : 
https://issues.apache.org/jira/browse/AXIS2-3870


How do we suggest bugs/fixes to be included in the 1.4.1 release ? In Jira ?

/hans


Amila Suriarachchi wrote:



On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED] 
> 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
<[EMAIL PROTECTED] > 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
<[EMAIL PROTECTED] > 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
<[EMAIL PROTECTED] >
>> wrote:
>> > Hi,
>> >
>> > For the users who is already using 1.4 version, the
workaround would be
>> > to
>> > define policies in services.xml without using
.
>> > Then
>> > the problem is that those policies will appear in
 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
>> > <[EMAIL PROTECTED] > 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
>> >> , tags. But thi