Re: release4.0: OFBIZ-1106 (in or out?)

[David E Jones]

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?

was implemented"?


line has to be drawn somewhere.  (I know where I'd draw it, especially
on security related issues.)

Or would it be discounted as "well, it's a bad choice but that's how it I understand that the difficult thing about this is that the bug/ feature

Maybe the word you are looking for is "issue"?

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". 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".





-David

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. ;)

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

weak and insecure area.

Ray


Dan Shields wrote:

release branch because of it's small footprint and improvement on a very

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.


is a bug".

I must say, the dev-debate that it has inspired has been impressive!

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

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 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

Wow I guess that what we have here is "the absence of this new feature There are good arguments both for viewing the patch as a bug, as well of fact that might exist in the software that would reveal the actual 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,

smime.p7s
Description: S/MIME cryptographic signature