[Owasp-esapi-ruby] ESAPI Updates, News, and Summit Results

Chris Schmidt chris.schmidt at owasp.org
Tue Sep 27 13:03:14 EDT 2011

Hash: SHA1
All -
First off, I apologize if you receive this email more than once, there
are *a lot* of various ESAPI Mailing Lists and contacts (to be addressed
later in this message) and I wanted to make sure everyone was on this
update. Also, I apologize for the length of this message, however -
there is a lot of updates and a lot of information to pass on so please
bare with me.
As you may have heard by now, there are some really great changes coming
down the pipe from the Global Projects Committee which will be great for
ESAPI, being one of the most successful and by far the largest code
project at OWASP. Among these changes are a new OWASP Projects Portal
hosted by SourceForge. This will open up the visibility of ESAPI to an
even larger audience and draw more attention to it from both open source
developers and development teams looking for solutions.
That being said, there are some changes being made to the ESAPI Project
as a whole, which affect all of us.
The first big change is the merging of the projects - one of the big
takeaways from the Summit and even prior to that is that it is far too
difficult to assess the health of the project due to the complexity of
it's structure. What it boils down to is the project has outgrown it's
Wild Wild West roots and it is time to step it up to the next level.
What does this mean for the project leaders? You will still lead the
charge on your implementations, you are the subject matter experts in
your language implementation and that will be incredibly important as we
charge forward. Details follow on what these changes imply.
IMPORTANT - Leaders, please register for a sourceforge account, and send
me your sourceforge username so I can add you to the project. I need
this information ASAP!
- ---
Chapter 1: Technical and Infrastructure Changes:
1) Create a master Git Repository on SourceForge.Net for *new* ESAPI
with the following structure:
    + java
       + source
       + documentation
       + contrib
    + dotnet
       + source
       + documentation
       + contrib
    + php
       + source
       + documentation
       + contrib
    + (etc)
2) Merge Issue Trackers - Add a *Language field to specify which
language a bug exists in. This will facilitate the ability for users to
report bugs that effect *all* or *single* versions of ESAPI and will
allow developers to filter on issues specific to their implementation or
work on issues across various implementations.
3) Align Releases - Once we have a solid leadership and development team
in place across the various implementations, we will align the releases
so that all the various implementations of ESAPI are in-line with
eachother. This will require collaboration and strategic planning on all
of our parts to ensure that we are not holding up releases due to a lack
of resources.
All of these things may seem a little daunting at first glance, but
before you groan and flicker away, there is one last *large* technical
change that we are making that should help to alleviate a good deal of
the pain.
4) Modularization/Componentization - This is a very loaded couple terms,
but is paramount to taking the next steps as a whole with the project.
So what does this mean:
   A) Seperate the API from the Reference Implementation
      1) For most of the implementations, this will mean a complete
fresh start on the API. The API should simply be the hooks into the
reference implementations and will be based off of the ESAPI 2.0 Java
   B) Write Reference Implementations of Controls as *Standalone* units
that can be plugged into the API
      1) This will be the more complex part of the undertaking for most.
We will have to work to see what even makes sense as a reference
implementation. In most of the implementations, the RI component may
simply be a wrapper around an existing control (IE: .Net Encoders will
wrap the AntiXSS library, Java Validators will wrap the Hibernate
Vaildator and/or JSR-303 validation framework, Authenticators should
wrap something usable and standard like OAuth)
      2) Each component will have it's own configuration needs and will
be responsible for self-configuring using a standard configuration
mechanism (more info in next bullet)
5) Enterprise Security Configuration - This is something I had
originally slotted for 2.2 or 3.0, but I am bumping up the priority on
this initiative because it is paramount to the success of the
Componentization and Modularization effort. I am currently drafting a
design document for what this new configuration design will look like,
which I will share with all the various project leaders to ensure that
we meet all the needs that are feasible for the next release.
- ---
Chapter 2: What I need from you!
There are currently 14 language implementations that I am aware of
(according to the wiki) and it is time to assess the health, desire, and
drive of each. What this means is that each language needs to have a
documented champion, or project leader to head up the effort and
collaborate with myself and the rest of the leadership to ensure that
the project is moving along according to schedule.
Currently I have the following:
    * Project Leader - Chris Schmidt
    * Java - Kevin Wall
    * .Net - Joe Gerber (Welcome Joe!)
    * Classic ASP - Juan Carlos Calderon
    * PHP - Andrew Van Der Stock
    * Coldfusion - Damon Miller
    * Python - Craig Younkins
    * Javascript/jQuery - Chris Schmidt
    * Objective-C - Deepak Subramanian
    * Force.com - Yoel Gluck (SalesForce)
    * Ruby - Paolo Perego
    * C - David Anderson
    * C++ - David Anderson
    * Perl - Sterling Hanenkamp
    * Project Contributors
        * Jeff Williams - Advisory, Documentation
        * John Steven - Advisory, Documentation
        * Jim Manico - Advisory, Funding/Sponsorship/Grants
I need to know that all of the listed leaders are indeed actively
leading their project, and if they are still willing to champion their
language going forward. Leaders, please respond to this email with that
information as well as who your active contributors are.
- ---
Chapter 3: Where do we get started???
So now that the high level stuff is out of the way, I would like to get
a conference call between myself and all the project leaders to lay out
our plan of attack. I would like to schedule this call on Saturday Oct
8th at 18:00GMT.
- ---
Please feel free to contact me on or off-list with any questions
regarding this email or the plans for the project going forward.
- ---
Final Thoughts:
I want to thank everyone that made it to the summit and the overwhelming
crowd that was at my final ESAPI talk (full room, people standing in
back, sitting on floor, etc). The summit was a huge success and we got a
lot of work accomplished. John Steven blogged about the Summit here
and I think he did a fantastic job of capturing the energy and outcomes
of the meeting. I will be releasing a full report on my blog and
cross-posting to the new ESAPI site on SourceForge this weekend
Also a special thank you to Aspect Security for sponsoring the ESAPI 2.0
Release Party at the end of AppSecUSA - it was a great time and we
appreciate the contributions!
Lastly, leaders - once you have created your sourceforge userid - please
go to the ESAPI Project and register for the phpBB forums - this will be
a much simpler way to discuss a lot of these changes over an email list.
Thank you all for all your hard work and I can't wait to see where we go
from here!
Chris Schmidt
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

More information about the Owasp-esapi-ruby mailing list