[Owasp-board] ESAPI - results

Jim Manico jim.manico at owasp.org
Sun Jun 15 00:48:37 UTC 2014


I will jump back in and help, but I want to say it again, my only goal
here is to make sure we do not call a security library a production
ready security library when it itself has significant security
vulnerabilities and functionality bugs.

But let me flip the question, what bugs do •you• think needs fixing
before ESAPI for Java can be deemed production quality?

Perhaps we could triage the list and make a proposal/suggestion to
Johanna? I'll help rally other folks to help if you do....

Jim Manico
(808) 652-3805

> On Jun 15, 2014, at 8:34 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:
>> On Sat, Jun 14, 2014 at 6:48 PM, Jim Manico <jim.manico at owasp.org> wrote:
>> Kevin,
>> I see this as not about you or me and I'm not trying to put pressure
>> on you.
> Jim,
> Oh, I know that. I was JK about you fixing bugs that were in any ESAPI
> code you wrote. The "you touched it last, you fix it rule" works better in
> the commercial world than it doe in the FOSS world where it's
> almost all volunteers. (Rather the rule in the FOSS world seems
> to be the new, shiny projects are the ones that attract the most
> volunteers; and unfortunately, ESAPI is no longer shiny. It if
> were smaller and more manageable by an indivual, that might
> be okay, but that's not the case. Of course the discussion of
> the whys and wherefores of that would take us down another
> rabbit trail.)
>> I just want to be honest to the user community about the
>> quality of our projects. That's it. ESAPI makes a fine labs project,
>> and I have no problem leaving it there if you and others do not have
>> time (or support) to fix the bugs.
> Sure; and I would want nothing less. I was just trying to make the point
> that IMHO, a project's health is more accurately reflected by the the
> community involvement than it is by the # of outstanding bugs. I personally
> would have major concerns with ESAPI even if it had zero outstanding
> bugs because of the lack of volunteers. No activity means ill health.
> To me, the fact that there are 169 outstanding bugs is as much a
> reflection that ESAPI 2.0 was release prematurely as it is a reflection
> that there is no support. This is especially true when you consider that
> we've not added ANY new functionality since 2.0, so all the bugs are
> against that code base. One reason for that is because we had
> inadequate test coverage, and to my earlier point about singletons
> making it difficult to use mock testing, that IMO is one reason we
> had poor code coverage in our tests....some things were just too difficult
> to test.
> Going back to being honest with the OWASP community regarding the
> state of ESAPI, I think members would have to be asleep for the past
> 2 or 3 months not to understand that. Certainly, I think it is at least
> clear to all the project leaders and the board and anyone else
> paying attention. Anyone subscribing to the ESAPI-Users or
> ESAPI-Dev mailing lists should be clued in by now as well.
> I have no problem with ESAPI being demoted to 'lab' status. (See
> http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp-flagship-project.html.)
> However, if the OWASP community wants to get the bugs fixed and
> continue to see ESAPI supported long term, there's GOT to be additional
> volunteer help. Demoting it to "lab" status may manage the expectations
> of those looking to use it and influence them to use a better alternative
> for some specific task (e.g., use the OWASP Java Encoder Project
> for encoding needs), but that's going to do nothing to help the thousands
> of projects already using ESAPI. And those people deserve some
> support as well. They certainly shouldn't get screwed because ESAPI
> is getting demoted to a lab status. And I think that has been the concern
> of many, myself included. If there is no community support while ESAPI
> was a flagship project, what will it be like once it is lab status? (Although,
> I guess it could be argued that it can't get much worse than it's been.)
> What started my dialog with Johanna on all of this was me trying to understand
> if ESAPI needed to have it's status as a whole (e.g., ESAPI C, ESAPI C++,
> ESAPI .NET, ESAPI PHP, ESAPI Java, ESAPI JavaScript, etc.)
> considered with respect to its status or could we just consider ESAPI Java
> and forget all the others. I asked this because I personally have no
> intention and certainly no time trying to carry the other ESAPI projects
> forward. From the sounds of it, it seems as though none of the other
> project leaders have an interest in that either.
> So, I think the main point of all this is I'm okay with demoting ESAPI
> (and when I say ESAPI, I really only mean ESAPI Java) to lab status,
> but I think the bottom line and what most ESAPI users are concerned
> about is what does that imply for the thousands of applications who have
> invested at lot in using ESAPI already. Ideally, those who have invested
> something in using ESAPI within their project would step up and help support
> it, but if that hasn't happened over the past 2+ years, it is unlikely
> that it is going to happen now. I just feel bad about leaving all those
> users high and dry, but that's my main concern in all this. That's why
> I'm appealing for help for a call for volunteers. I'm okay with making
> ESAPI a lab status project, but I'm not okay letting it die.
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/
> NSA: All your crypto bit are belong to us.

More information about the Owasp-board mailing list