Finally, have we an idea about what to do :o) Do we need a vote for this ? Maybe a generalisation for "security" case as features to back port in any case ? Create release4.0 (and later when they will come) branches as proposed by Jonathon ?
Jacques De : "clearchris" <[EMAIL PROTECTED]> > I had no idea the can of worms this would open up when I entered the issue. > > I come down on the side of wanting this patch in the release branch. > > Further, as there is no defined release date for 4.0, I would consider it > still open for very high-priority issues that are not traditionally defined > as "bugs". Ofbiz customers, if they are using the release branch in > production or close to production would probably do well to lag a bit and > run with an older revision of the release branch. Regressions can always be > an issue, even with bug "fixes". > > Chris > > -----Original Message----- > From: David E Jones [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 15, 2007 4:11 PM > To: dev@ofbiz.apache.org > Subject: Re: release4.0: OFBIZ-1106 (in or out?) > > > On Nov 15, 2007, at 11:18 AM, Michael Jensen wrote: > > > 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.) > > It's really not that tough... As I described in depth in my previous > post in this thread there is no need to muddy the meaning of "bug". > > Maybe the word you are looking for is "issue"? > > This isn't a "bug" per-se, but certainly an "issue" and solving that > issue requires a new feature. That doesn't mean it can't go into the > release branch, but non-bug-fixes should be carefully considered > before being added. > > > 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. > > This is a common misconception. There are no "people driving ofbiz". > > OFBiz is a community-driven project and things happen when a user > needs something, implements it, and contributes it back to the > project. Even committers on OFBiz are just users who have a long > history of contributions and are invited to be committers to > facilitate further involvement. > > Security or not, things will only be fixed if someone cares enough. > The flip side of that is that if someone doesn't like how something is > in OFBiz and they don't do anything about it, they have only > themselves to blame, as uncomfortable and frighteningly empowering as > that may be. ;) > > -David > > > > 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 > >>> > >>> > >
