http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185460.html
to release branch without causing any problems. Even though this may not be
>
> 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" <
[hidden email]>
> > 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:
[hidden email]]
> > Sent: Thursday, November 15, 2007 4:11 PM
> > To:
[hidden email]
> > 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
> > >>>
> > >>>
> >
> >
>