De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > Still, I do understand that it's a hassle to have to apply 10s of mini > patches every time I deploy > a new 4.0 implementation.
You cant put them in one sole parch, this is not the harder part, collecting them might be > What does everyone think of labeling OFBiz 4.0 "beta", and creating an > "alpha" OFBiz 4.1 where we > can dump such critical enhancements? See my previous post in this thread for > that thing about "4.x > family". Mostly man power issue. This does not mean that we should not discuss about it but please keep in mind OFBis project human ressources reality Jacques > Jonathon > > BJ Freeman wrote: > > Lets remind everyone that there is a patch for the security. > > it is available to anyone that wants to apply it. > > I do this to my Ver 4.0 (not svn) on patches that have been done to the > > trunk. > > You can have access to all patches that are done to both the trunk and > > the branch by subscribing to the Commit ML. > > > > so the security has been addressed. > > > > this is a discussion about applying such patches to a release branch. It > > is applied to the trunk, so if you want to get the latests and greatest > > including possible bugs that the additions may cause. > > you can use the trunk for you purposes. > > > > > > Michael Jensen sent the following on 11/15/2007 10:18 AM: > >> Using that logic, you could say that almost any previous bugs were > >> really "as-implemented" features and no changes should ever be made to > >> the current release branch. > >> If it was found somewhere in ofbiz that sensitive information was > >> submitted over http instead of https, would that be considered a bug? > >> Or would it be discounted as "well, it's a bad choice but that's how it > >> was implemented"? > >> > >> I understand that the difficult thing about this is that the bug/feature > >> line has to be drawn somewhere. (I know where I'd draw it, especially > >> on security related issues.) > >> > >> I'm curious to see how things pan out on this. It will tell me how > >> seriously security is taken by the people driving ofbiz. > >> > >> Mike > >> > >> > >> > >> Ray Barlow wrote: > >>> As you say plenty of good points so rather than repeat lengthy arguments > >>> for or against I'll keep it simple and just say I don't think it should > >>> be described as a bug as it was implemented this way. Bad choice maybe > >>> but it's a feature change. > >>> > >>> Having said that I do think it should be seriously considered for the > >>> release branch because of it's small footprint and improvement on a very > >>> weak and insecure area. > >>> > >>> Ray > >>> > >>> > >>> Dan Shields wrote: > >>>> Thanks Jacques. Is there any further action by me that might be > >>>> advised? I was wondering because I was considering declaring a > >>>> referendum on the issue on the user list as per David Jones' > >>>> suggestion. > >>>> > >>>> Wow I guess that what we have here is "the absence of this new feature > >>>> is a bug". > >>>> > >>>> I must say, the dev-debate that it has inspired has been impressive! > >>>> There are good arguments both for viewing the patch as a bug, as well > >>>> as equally good arguments for viewing it as a feature. It really > >>>> surprised me because up until that point in time (when I blindly > >>>> stumbled into this) my view was entirely to think about it as a bug > >>>> only. The author of OFBIZ-1106 never knew the difference between > >>>> 'code that failed to hide the password' and 'the complete absence of > >>>> code that successfully hid the password', he just knew that the > >>>> software did not do 'as it should', and this was exactly my point of > >>>> view in devising a solution as well. It requires a strong > >>>> metaphysical argument to even tell the difference between the points > >>>> of fact that might exist in the software that would reveal the actual > >>>> intent of the original design. My feeling is that it was either > >>>> overlooked accidentally, or it was not convenient to declare the XUI > >>>> XPage in a manner that made sense to have both regular input and > >>>> password input in the same node of the tree but at different times > >>>> (this convenience is what I provided in the patch). > >>>> > >>>> As I said above I am willing to take this to the user list and invite > >>>> all users who run a release4.0 branch to submit an accept/reject vote, > >>>> as I think this feature/bug (or bug/feature) is important enough to > >>>> the success of release4.0 to warrant. > >>>> > >>>> I am happily sitting on the fence and content to let this issue go > >>>> either way. I am finding it fascinating. > >>>> > >>>> Cheers all > >>>> Dan > >>>> > >>>> > >> > >> > > > > >
