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

Kevin W. Wall kevin.w.wall at gmail.com
Sat Jul 31 15:02:04 EDT 2010

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

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.

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

More information about the Esapi-user mailing list