Security Redesign and Release 10.x Branch
Locked
1234
1234
Re: Security Redesign and Release 10.x Branch
 
|
Today I learnt that Command + Shift + D means Send Message and doesn't activate the mouse over dictionary in OSX.
Regards Scott On 7/04/2010, at 4:57 PM, Scott Gray wrote: > I would suggest to: > 1) release 10.04 before the merge is done > 2) merge the code to the trunk, switch to it, fix any possible issue > 3) do another release (10.06?) > > I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) > > Jacopo > > On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: > >> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >> >> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >> >> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >> >> -Adrian >> >> >> >> > |
smime.p7s (3K)
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Question:
What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. Regards Scott On 7/04/2010, at 5:14 PM, Adrian Crum wrote: > If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. > > At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? > > I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. > > :-) > > -Adrian > > > Scott Gray wrote: >> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >> HotWax Media >> http://www.hotwaxmedia.com >> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>> I would suggest to: >>> 1) release 10.04 before the merge is done >>> 2) merge the code to the trunk, switch to it, fix any possible issue >>> 3) do another release (10.06?) >>> >>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>> >>> Jacopo >>> >>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>> >>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>> >>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>> >>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>> >>>> -Adrian >>>> >>>> >>>> >>>> |
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Well I don't see any problem with dropping it in right now then. The real question will be what do people want to be able to backport once the release branch is created.
Regards Scott On 7/04/2010, at 5:35 PM, Adrian Crum wrote: > The security redesign implementation itself is mostly finished. There are a few TODOs and they can be found in the BranchReadMe.txt file. > > I recently synchronized the branch with the trunk and there is a remote chance something in the design might have broken in the process. I need to run some tests and review the code to see if that happened. > > The Example component has been switched over to the new design. > > There is a user login called "artifact-user" that demonstrates the new design. That user login is restricted to using the Example component. > > If the branch was merged back to the trunk and the new security design was enabled, the Example component would use the new design and the remaining components would still use the current security design. The two can co-exist. > > I imagine the process after that would be similar to when we introduced the permission checking services - contributors can contribute code that converts parts of the project over to the new security design. Conversion involves removing hard-coded permission checks and creating seed data to grant permission to component artifacts. > > As I mentioned before, switching a component over to the new design can create some unexpected problems. That's because our existing code has security holes in it, and the new design plugs those holes - making parts of the component unreachable. In other words, parts of code that happily allow you to do things you don't have permission to do will start to throw exceptions in the new design. > > -Adrian > > > Scott Gray wrote: >> Question: >> What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? >> I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. >> Regards >> Scott >> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>> If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. >>> >>> At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? >>> >>> I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. >>> >>> :-) >>> >>> -Adrian >>> >>> >>> Scott Gray wrote: >>>> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>> I would suggest to: >>>>> 1) release 10.04 before the merge is done >>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>> 3) do another release (10.06?) >>>>> >>>>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>>>> >>>>> Jacopo >>>>> >>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>> >>>>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>>>> >>>>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>>>> >>>>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> >>>>>> |
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
That is a slippery slope to walk on and as soon as we begin backporting features we just end up with another trunk. Why not just wait until the features we deem important are ready before branching?
Regards Scott On 7/04/2010, at 6:06 PM, Anil Patel wrote: > I am yet to see contents of BranchReadMe.txt. In case it has some todo that are not classified as bug fix but are instead classified as enhancements, I will like it better if we officially allowed back porting such code to release branch. > > Similarly, Jacques will like to get layered lookup part also included in release branch. Lets say if we allowed back porting of that feature as well. It will make him happy :) I also see it as major upgrade and will like to see it in release. > > If community does not officially do it, then I will have to create vendor branch in my private repository of community release branch anyway :) > > Other then this, Most of the code changes these days are in ofbiz trunk are at framework level. I am interested in branch so I get isolation from continues changes in framework. Most of those changes increase risk for delivery of project. I found myself in tough spot because of those and finally decide to not use trunk for projects. > > All these little things are my reason for pushing for release branch sooner then later. > > Thanks and Regards > Anil Patel > HotWax Media Inc > Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" > > On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: > >> Well I don't see any problem with dropping it in right now then. The real question will be what do people want to be able to backport once the release branch is created. >> >> Regards >> Scott >> >> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >> >>> The security redesign implementation itself is mostly finished. There are a few TODOs and they can be found in the BranchReadMe.txt file. >>> >>> I recently synchronized the branch with the trunk and there is a remote chance something in the design might have broken in the process. I need to run some tests and review the code to see if that happened. >>> >>> The Example component has been switched over to the new design. >>> >>> There is a user login called "artifact-user" that demonstrates the new design. That user login is restricted to using the Example component. >>> >>> If the branch was merged back to the trunk and the new security design was enabled, the Example component would use the new design and the remaining components would still use the current security design. The two can co-exist. >>> >>> I imagine the process after that would be similar to when we introduced the permission checking services - contributors can contribute code that converts parts of the project over to the new security design. Conversion involves removing hard-coded permission checks and creating seed data to grant permission to component artifacts. >>> >>> As I mentioned before, switching a component over to the new design can create some unexpected problems. That's because our existing code has security holes in it, and the new design plugs those holes - making parts of the component unreachable. In other words, parts of code that happily allow you to do things you don't have permission to do will start to throw exceptions in the new design. >>> >>> -Adrian >>> >>> >>> Scott Gray wrote: >>>> Question: >>>> What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? >>>> I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. >>>> Regards >>>> Scott >>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>> If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. >>>>> >>>>> At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? >>>>> >>>>> I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. >>>>> >>>>> :-) >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> Scott Gray wrote: >>>>>> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>> I would suggest to: >>>>>>> 1) release 10.04 before the merge is done >>>>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>>>> 3) do another release (10.06?) >>>>>>> >>>>>>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>>>> >>>>>>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>>>>>> >>>>>>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>>>>>> >>>>>>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> > |
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Just to be clear though, I am NOT in favor of back-porting large chunks of functionality to the release branch under the guise of bug fixes.
Regards Scott On 8/04/2010, at 12:06 PM, Anil Patel wrote: > Looks like, none who participated in this thread have objections for merging of securitycontext20091231 branch with trunk. > > Thanks and Regards > Anil Patel > HotWax Media Inc > Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" > > On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: > >> Well I don't see any problem with dropping it in right now then. The real question will be what do people want to be able to backport once the release branch is created. >> >> Regards >> Scott >> >> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >> >>> The security redesign implementation itself is mostly finished. There are a few TODOs and they can be found in the BranchReadMe.txt file. >>> >>> I recently synchronized the branch with the trunk and there is a remote chance something in the design might have broken in the process. I need to run some tests and review the code to see if that happened. >>> >>> The Example component has been switched over to the new design. >>> >>> There is a user login called "artifact-user" that demonstrates the new design. That user login is restricted to using the Example component. >>> >>> If the branch was merged back to the trunk and the new security design was enabled, the Example component would use the new design and the remaining components would still use the current security design. The two can co-exist. >>> >>> I imagine the process after that would be similar to when we introduced the permission checking services - contributors can contribute code that converts parts of the project over to the new security design. Conversion involves removing hard-coded permission checks and creating seed data to grant permission to component artifacts. >>> >>> As I mentioned before, switching a component over to the new design can create some unexpected problems. That's because our existing code has security holes in it, and the new design plugs those holes - making parts of the component unreachable. In other words, parts of code that happily allow you to do things you don't have permission to do will start to throw exceptions in the new design. >>> >>> -Adrian >>> >>> >>> Scott Gray wrote: >>>> Question: >>>> What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? >>>> I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. >>>> Regards >>>> Scott >>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>> If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. >>>>> >>>>> At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? >>>>> >>>>> I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. >>>>> >>>>> :-) >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> Scott Gray wrote: >>>>>> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >>>>>> HotWax Media >>>>>> http://www.hotwaxmedia.com >>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>> I would suggest to: >>>>>>> 1) release 10.04 before the merge is done >>>>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>>>> 3) do another release (10.06?) >>>>>>> >>>>>>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>>>> >>>>>>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>>>>>> >>>>>>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>>>>>> >>>>>>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> > |
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
In reply to this post by Jacopo Cappellato-3
Hi Jacopo,
What exactly does it mean to create an "alpha" release, compared to what we have now where we create a release branch? Thanks Scott On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote: > Sorry if I am hijacking this thread, but the more I think of it the more I believe we should officially create an "alpha" release 10.04, instead of simply creating a release candidate for 10.04. > In this way we will have two official current releases: > 09.04 Stable Release > 10.04 Alpha Release > > Intended audiences: > 09.04: final users with no interest (or resources) in helping the community to build and maintain stable releases > 10.04: users (they could be service providers, end user companies with internal resources or longer term goals etc...) that are willing to help the community to build and maintain a stable release > > If there will be interest around the 10.04 alpha release, we will get bug fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than the predecessor). > > Jacopo > > On Apr 8, 2010, at 8:11 PM, Scott Gray wrote: > >> Just to be clear though, I am NOT in favor of back-porting large chunks of functionality to the release branch under the guise of bug fixes. >> >> Regards >> Scott >> >> On 8/04/2010, at 12:06 PM, Anil Patel wrote: >> >>> Looks like, none who participated in this thread have objections for merging of securitycontext20091231 branch with trunk. >>> >>> Thanks and Regards >>> Anil Patel >>> HotWax Media Inc >>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>> >>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: >>> >>>> Well I don't see any problem with dropping it in right now then. The real question will be what do people want to be able to backport once the release branch is created. >>>> >>>> Regards >>>> Scott >>>> >>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >>>> >>>>> The security redesign implementation itself is mostly finished. There are a few TODOs and they can be found in the BranchReadMe.txt file. >>>>> >>>>> I recently synchronized the branch with the trunk and there is a remote chance something in the design might have broken in the process. I need to run some tests and review the code to see if that happened. >>>>> >>>>> The Example component has been switched over to the new design. >>>>> >>>>> There is a user login called "artifact-user" that demonstrates the new design. That user login is restricted to using the Example component. >>>>> >>>>> If the branch was merged back to the trunk and the new security design was enabled, the Example component would use the new design and the remaining components would still use the current security design. The two can co-exist. >>>>> >>>>> I imagine the process after that would be similar to when we introduced the permission checking services - contributors can contribute code that converts parts of the project over to the new security design. Conversion involves removing hard-coded permission checks and creating seed data to grant permission to component artifacts. >>>>> >>>>> As I mentioned before, switching a component over to the new design can create some unexpected problems. That's because our existing code has security holes in it, and the new design plugs those holes - making parts of the component unreachable. In other words, parts of code that happily allow you to do things you don't have permission to do will start to throw exceptions in the new design. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> Scott Gray wrote: >>>>>> Question: >>>>>> What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? >>>>>> I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. >>>>>> Regards >>>>>> Scott >>>>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>>>> If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. >>>>>>> >>>>>>> At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? >>>>>>> >>>>>>> I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. >>>>>>> >>>>>>> :-) >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> Scott Gray wrote: >>>>>>>> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >>>>>>>> HotWax Media >>>>>>>> http://www.hotwaxmedia.com >>>>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>>>> I would suggest to: >>>>>>>>> 1) release 10.04 before the merge is done >>>>>>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>>>>>> 3) do another release (10.06?) >>>>>>>>> >>>>>>>>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>>>>>> >>>>>>>>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>>>>>>>> >>>>>>>>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>>>>>>>> >>>>>>>>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> >>> >> > |
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
In reply to this post by Jacopo Cappellato-3
On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote:
> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote: > >> Hi Jacopo, >> >> What exactly does it mean to create an "alpha" release, compared to what we have now where we create a release branch? > > It fundamentally means that we can distribute it outside of the inner group of contributors because the we can guarantee that it is full compliant with ASF license requirements. Ah okay I see what you mean and that sounds fine to me. I'm not entirely clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the stable one), 10.04.1 (post stable bug fix release?) > > Kind regards, > > Jacopo > >> >> Thanks >> Scott >> >> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote: >> >>> Sorry if I am hijacking this thread, but the more I think of it the more I believe we should officially create an "alpha" release 10.04, instead of simply creating a release candidate for 10.04. >>> In this way we will have two official current releases: >>> 09.04 Stable Release >>> 10.04 Alpha Release >>> >>> Intended audiences: >>> 09.04: final users with no interest (or resources) in helping the community to build and maintain stable releases >>> 10.04: users (they could be service providers, end user companies with internal resources or longer term goals etc...) that are willing to help the community to build and maintain a stable release >>> >>> If there will be interest around the 10.04 alpha release, we will get bug fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than the predecessor). >>> >>> Jacopo >>> >>> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote: >>> >>>> Just to be clear though, I am NOT in favor of back-porting large chunks of functionality to the release branch under the guise of bug fixes. >>>> >>>> Regards >>>> Scott >>>> >>>> On 8/04/2010, at 12:06 PM, Anil Patel wrote: >>>> >>>>> Looks like, none who participated in this thread have objections for merging of securitycontext20091231 branch with trunk. >>>>> >>>>> Thanks and Regards >>>>> Anil Patel >>>>> HotWax Media Inc >>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>>> >>>>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: >>>>> >>>>>> Well I don't see any problem with dropping it in right now then. The real question will be what do people want to be able to backport once the release branch is created. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >>>>>> >>>>>>> The security redesign implementation itself is mostly finished. There are a few TODOs and they can be found in the BranchReadMe.txt file. >>>>>>> >>>>>>> I recently synchronized the branch with the trunk and there is a remote chance something in the design might have broken in the process. I need to run some tests and review the code to see if that happened. >>>>>>> >>>>>>> The Example component has been switched over to the new design. >>>>>>> >>>>>>> There is a user login called "artifact-user" that demonstrates the new design. That user login is restricted to using the Example component. >>>>>>> >>>>>>> If the branch was merged back to the trunk and the new security design was enabled, the Example component would use the new design and the remaining components would still use the current security design. The two can co-exist. >>>>>>> >>>>>>> I imagine the process after that would be similar to when we introduced the permission checking services - contributors can contribute code that converts parts of the project over to the new security design. Conversion involves removing hard-coded permission checks and creating seed data to grant permission to component artifacts. >>>>>>> >>>>>>> As I mentioned before, switching a component over to the new design can create some unexpected problems. That's because our existing code has security holes in it, and the new design plugs those holes - making parts of the component unreachable. In other words, parts of code that happily allow you to do things you don't have permission to do will start to throw exceptions in the new design. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> Scott Gray wrote: >>>>>>>> Question: >>>>>>>> What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? >>>>>>>> I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. >>>>>>>> Regards >>>>>>>> Scott >>>>>>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>>>>>> If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. >>>>>>>>> >>>>>>>>> At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? >>>>>>>>> >>>>>>>>> I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. >>>>>>>>> >>>>>>>>> :-) >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> Scott Gray wrote: >>>>>>>>>> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >>>>>>>>>> HotWax Media >>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>>>>>> I would suggest to: >>>>>>>>>>> 1) release 10.04 before the merge is done >>>>>>>>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>>>>>>>> 3) do another release (10.06?) >>>>>>>>>>> >>>>>>>>>>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>>>>>>>>>> >>>>>>>>>>> Jacopo >>>>>>>>>>> >>>>>>>>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>>>>>>>> >>>>>>>>>>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>>>>>>>>>> >>>>>>>>>>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>>>>>>>>>> >>>>>>>>>>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>>>>>>>>>> >>>>>>>>>>>> -Adrian >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>> >>>> >>> >> > |
Re: Security Redesign and Release 10.x Branch
|
|
In reply to this post by Jacopo Cappellato-3
On 13/04/2010, at 9:41 PM, Jacopo Cappellato wrote:
> > On Apr 13, 2010, at 11:36 AM, Jacopo Cappellato wrote: > >> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote: >> >>> Hi Jacopo, >>> >>> What exactly does it mean to create an "alpha" release, compared to what we have now where we create a release branch? >> >> It fundamentally means that we can distribute it outside of the inner group of contributors because the we can guarantee that it is full compliant with ASF license requirements. >> > > But apart from this (important, in my opinion) difference the "alpha" release will be used exactly as we have used the release candidate: to build (with the help of the community) a "stable" release. > Having the ability of distribute it will increase our chances to get more help (tests and bug fixes but also documentation) from the community and the "stable" release will be an effort of the community (instead of the result of backported patches done by committers only). > > Jacopo Regards Scott >> Kind regards, >> >> Jacopo >> >>> >>> Thanks >>> Scott >>> >>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote: >>> >>>> Sorry if I am hijacking this thread, but the more I think of it the more I believe we should officially create an "alpha" release 10.04, instead of simply creating a release candidate for 10.04. >>>> In this way we will have two official current releases: >>>> 09.04 Stable Release >>>> 10.04 Alpha Release >>>> >>>> Intended audiences: >>>> 09.04: final users with no interest (or resources) in helping the community to build and maintain stable releases >>>> 10.04: users (they could be service providers, end user companies with internal resources or longer term goals etc...) that are willing to help the community to build and maintain a stable release >>>> >>>> If there will be interest around the 10.04 alpha release, we will get bug fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable than the predecessor). >>>> >>>> Jacopo >>>> >>>> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote: >>>> >>>>> Just to be clear though, I am NOT in favor of back-porting large chunks of functionality to the release branch under the guise of bug fixes. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 8/04/2010, at 12:06 PM, Anil Patel wrote: >>>>> >>>>>> Looks like, none who participated in this thread have objections for merging of securitycontext20091231 branch with trunk. >>>>>> >>>>>> Thanks and Regards >>>>>> Anil Patel >>>>>> HotWax Media Inc >>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>>>> >>>>>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: >>>>>> >>>>>>> Well I don't see any problem with dropping it in right now then. The real question will be what do people want to be able to backport once the release branch is created. >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >>>>>>> >>>>>>>> The security redesign implementation itself is mostly finished. There are a few TODOs and they can be found in the BranchReadMe.txt file. >>>>>>>> >>>>>>>> I recently synchronized the branch with the trunk and there is a remote chance something in the design might have broken in the process. I need to run some tests and review the code to see if that happened. >>>>>>>> >>>>>>>> The Example component has been switched over to the new design. >>>>>>>> >>>>>>>> There is a user login called "artifact-user" that demonstrates the new design. That user login is restricted to using the Example component. >>>>>>>> >>>>>>>> If the branch was merged back to the trunk and the new security design was enabled, the Example component would use the new design and the remaining components would still use the current security design. The two can co-exist. >>>>>>>> >>>>>>>> I imagine the process after that would be similar to when we introduced the permission checking services - contributors can contribute code that converts parts of the project over to the new security design. Conversion involves removing hard-coded permission checks and creating seed data to grant permission to component artifacts. >>>>>>>> >>>>>>>> As I mentioned before, switching a component over to the new design can create some unexpected problems. That's because our existing code has security holes in it, and the new design plugs those holes - making parts of the component unreachable. In other words, parts of code that happily allow you to do things you don't have permission to do will start to throw exceptions in the new design. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> Scott Gray wrote: >>>>>>>>> Question: >>>>>>>>> What exactly is the current status of the execution branch? What is it that needs to be done for it to be enabled in the trunk? >>>>>>>>> I'm sorry if you feel you've already answered that question but I'm afraid it still isn't entirely clear to me. >>>>>>>>> Regards >>>>>>>>> Scott >>>>>>>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>>>>>>> If we wait, then we're waiting for evaluation and testing of the branch. I've done all I can do - the code is written, I suggested we do the merge before the release branch, and I gave my reasons for suggesting it. >>>>>>>>>> >>>>>>>>>> At this point in time I have stepped out of the discussion (in a positive way) to give others a chance to look at the design and the code and decide for themselves if it should be included. In other words, I don't want to be in a position where I have to convince the community what it should do. If the design and the implementation are good, then there will be no need to convince anyone, right? >>>>>>>>>> >>>>>>>>>> I'll answer questions about the executioncontext branch, and I'll continue to work on it here and there when I have the time. If the release branch is created without it, then that will be fine with me. >>>>>>>>>> >>>>>>>>>> :-) >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Scott Gray wrote: >>>>>>>>>>> Considering we have yet to do an official release after 3.5 years and the lack of user interest in our release branches (partly because we recommend the trunk to everybody), I think it would be a waste of time and effort to create more than one release branch per year. If we want the security branch in there then lets wait, there is no good reason for us to release this month, it's just an arbitrary date. >>>>>>>>>>> HotWax Media >>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>>>>>>> I would suggest to: >>>>>>>>>>>> 1) release 10.04 before the merge is done >>>>>>>>>>>> 2) merge the code to the trunk, switch to it, fix any possible issue >>>>>>>>>>>> 3) do another release (10.06?) >>>>>>>>>>>> >>>>>>>>>>>> I know this is not inline with what we currently think a release should be, but this is very inline with what the ASF practices and so I will continue to insist with the release-often practice. :-) >>>>>>>>>>>> >>>>>>>>>>>> Jacopo >>>>>>>>>>>> >>>>>>>>>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I would like to start bringing parts of the executioncontext20091231 branch into the trunk before we create the next release branch. The implementation of the new security design is not finished, but it will be disabled - so everything will still work the same. >>>>>>>>>>>>> >>>>>>>>>>>>> My goal is to allow users of the 10.x release to plan for the forthcoming changes, and maybe have the conversion to the new design completed by the release that follows 10.x. >>>>>>>>>>>>> >>>>>>>>>>>>> I will wait a few days, and if there are no objections I will begin merging the design into the trunk. >>>>>>>>>>>>> >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
Re: Security Redesign and Release 10.x Branch
|
|
Re: Security Redesign and Release 10.x Branch
|
|
| Free forum by Nabble | Edit this page |