I've been playing with pos for the last week and I've also reviewed this commit and found no problems with it, I'm quite confident it can be applied to release branch without causing any problems. Even though this may not be a bug in the traditional sense, it does plug a big enough security hole to, in my opinion, go into the branch.
We could ask for opinions on the user list, but really, is anyone who is using pos going to prefer unmasked passwords? Regards Scott On 17/11/2007, Jacques Le Roux <[EMAIL PROTECTED]> wrote: > > 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 > > >>> > > >>> > > > > >
