[Esapi-user] [Esapi-dev] What can I do next for ESAPI?

Chris Schmidt chrisisbeef at gmail.com
Sat Jul 31 16:34:46 EDT 2010

There are a couple of outstanding things if I remember correctly.

1) breaking out ESAPI core and components into modules and/or separate jars. 

In my mind this is one of the most important things we need to work on for future versions. This has been a huge hurdle for a lot of the adopters that I have spoken to, the large number of dependencies introduces a pretty significant amount of risk into getting esapi into existing applications. People should be able to integrate the esapi in smaller pieces to minimize risk and scope of impact on their app.

2) usable contrib components structure.

Another important piece. A lot of people are already using libs for a lot of these concerns and it would make adoption a great deal easier if they could drop a contrib jar into the classpath, make some configuration changes and have a working component based on what they already have - for example Spring Security authentication and access control.

I am sure there are more, but these are some of the larger more impactful changes that we have talked about.

Sent from my iPwn

On Jul 31, 2010, at 1:02 PM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:

> I just wondered if Jim and/or Jeff had any grand plans of features to work
> on with ESAPI? Do we have any grand scheme for new features w/ proposed
> release schedule? (Maybe just in your heads.)
> Specifically, I want to start getting a bit more involved again in some
> coding.
> I have only one other open issue (# 114). Not sure if people think it's that
> important or not. (Listed as 'High', but that's probably an exaggeration.
> 'Medium' probably more appropriate, especially since the README file describes
> what needs to be changed.)
> So, I could work on issue #114 (boring!) or maybe some other open issue.
> Or I could continue working on extensions to crypto...e.g., may provide
> an out-of-the-box EncryptedCookie, say. Or tweak the crypto to make it
> simpler to switch crypto algorithms? Or provide better support for
> public key encryption -- e.g., tie the keys to certificates and keystores
> rather than working with raw keys, etc.  Alternately, I don't *have* to
> even stay working on the Java version. I also comfortable enough with
> Python and .NET (C#, no VB please! :) that I probably could contribute to
> porting the ESAPI 2.0 crypto to there. (Though I wouldn't volunteer for the
> .NET port unless it is something that would be compatible w/ Mono. Really do
> not wish to have to run Windows to do development.) Could also work on
> the few crypt examples in Swingset to change them to work with the new
> ESAPI 2.0 crypto.
> Something else that I thought about is doing a usable LdapAuthenticator
> and putting it into the 'contrib' or 'examples' section. (Still don't
> see 'contrib' though on the main trunk. Was that 'contrib' work being done
> on some branch?) I'm pretty experienced with LDAP that I could do that.
> (Note that I don't think and LdapAuthenticator is appropriate for the
> reference implementation though, simply because the JUnit tests really
> should have a real LDAP available to test against. Only alternative I
> know would be build a bunch of mock interfaces to LDAP which would take
> longer than it would to write the Authenticator in the first place. So
> leaving it out of the reference wouldn't cause JUnit tests to fail if
> you didn't have an LDAP to test it against. Plus I probably would use
> the Mozilla LDAP Java SDK as I much prefer that over using JNDI. Done
> both, but ldapsdk.jar is much easier to use for most things, but using it
> would add yet another dependency.)
> Anyhow, am looking for something to do so I am open to suggestions.
> -kevin
> P.S.- Given that Jim and Jeff are project owners, I will give their
>      suggestions more weight than the others. Just so you know...
> -- 
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev

More information about the Esapi-user mailing list