[Owasp-board] ESAPI - results

Kevin W. Wall kevin.w.wall at gmail.com
Sun Jun 15 00:34:41 UTC 2014


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