First 3.0.0 release date?

[aadrian]

Any news when the first version of 3.0.0 will be released?

Thank you.

[b-long]

:+1:

[kwwall]

Nothing specific is planned at this time. No volunteers. :(

[thesp0nge]

Kevin, maybe I'm missing the point but... ok no volunteers but does the project has a roadmap? does the project has a todo file? a github issue list?

I think we should start working on this and then look for the volunteers. Make sense?

paolo

On 14 March 2016 at 18:29, Kevin W. Wall notifications@github.com wrote:

Nothing specific is planned at this time. No volunteers. :(

— Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196423883.

$ cd /pub $ more beer

I pirati della sicurezza applicativa: https://codiceinsicuro.it

[kwwall]

Most of my energy is spent on ESAPI legacy, which has quite a few remaining issues and keeps me busy. (Plus I am also working on the crypto chapter to the OWASP DevGuide.)

If someone wants to jump in and fork the project, flesh out the remaining interfaces, that would help us get started. From there, they can submit a pull request. Between ESAPI 2.x and OWASP DevGuide, I don't personally have time to lead ESAPI 3.0 too unless I get some help--especially if the ZAP Google Summer of Code that I volunteered for gets selected.

So, please, pitch in. Propose a road map. Propose interfaces! Help in whatever manner you think you can!

Thanks, -kevin

On Mon, Mar 14, 2016 at 6:36 PM, Paolo Perego notifications@github.com wrote:

Kevin, maybe I'm missing the point but... ok no volunteers but does the project has a roadmap? does the project has a todo file? a github issue list?

I think we should start working on this and then look for the volunteers. Make sense?

paolo

On 14 March 2016 at 18:29, Kevin W. Wall notifications@github.com wrote:

Nothing specific is planned at this time. No volunteers. :(

— Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196423883.

$ cd /pub $ more beer

I pirati della sicurezza applicativa: https://codiceinsicuro.it

— Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196550295.

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

[b-long]

Kevin,

Thanks for providing that insight. I'm onboard to support as time permits, but my time is limited. Who are the folks with permission to accept merge requests? If I "at" @ESAPI , will my message land in your inbox?

Thanks, b-long

[ramzimaalej]

Hey Guys,

I can help as well.

Thanks, Ramzi

2016-03-14 19:00 GMT-04:00 Brian Long notifications@github.com:

Kevin,

Thanks for providing that insight. I'm onboard to support as time permits, but my time is limited. Who are the folks with permission to accept merge requests? If I "at" @ESAPI https://github.com/ESAPI , will my message land in your inbox?

Thanks, b-long

— Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196556702.

Cheers, Ramzi

[kwwall]

No. My @owasp.org address doesn't seem to be working. It doesn't bounce (or at least it didn't the last time I tried it), but simply disappeared into oblivion rather than showing up at my email address. If you want to contact me directly, send it to me kevin.w.wall@gmail.com. (Yes; that might get me a bit of additional spam too, but anyone who thinks that spammers haven't figured out how to parse pseudo-email addresses written like "kevin DOT w DOT wall AT gmail DOT com" seriously must be smokin' something.)

On Mon, Mar 14, 2016 at 7:00 PM, Brian Long notifications@github.com wrote:

Kevin,

Thanks for providing that insight. I'm onboard to support as time permits, but my time is limited. Who are the folks with permission to accept merge requests? If I "at" @ESAPI https://github.com/ESAPI , will my message land in your inbox?

Thanks, b-long

— Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196556702.

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

[b-long]

Thanks @ramzimaalej and @kwwall . I've opened #4 and submitted a pull request to address it. We'll need someone who is a part of the ESAPI organization to enable Travis. It's pretty simple if you'd like, I can support that effort.

[b-long]

If you're looking for volunteers, I'm happy to help! Are you accepting new folks in the ESAPI organization?

[chrisisbeef]

All - I've been out of town (and out of touch) for the last weeks - give me a little time to catch up on this (and a few others) threads over the weekend and let's come up with a plan of attack early next week. Sound good?

On Tuesday, March 15, 2016, Brian Long notifications@github.com wrote:

If you're looking for volunteers, I'm happy to help! Are you accepting new folks in the ESAPI organization?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ESAPI/esapi-java/issues/3#issuecomment-196803439

~C

[kwwall]

​On Thu, Mar 17, 2016 at 1:48 PM, Chris Schmidt notifications@github.com wrote:

All - I've been out of town (and out of touch) for the last weeks - give me a little time to catch up on this (and a few others) threads over the weekend and let's come up with a plan of attack early next week. Sound good?

@chrisisbeef - works for me. And also throw in your $.02 regarding the Jenkins vs. Travis CI discussion on a different GitHub issue #1 as well.

​Let's just not wait too long because Google Summer of Code is spinning up again and very soon I'll be knee deep in a ton of student proposals to review.

-kevin​

[chrisisbeef]

All -

1) WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both potential GSoC tasks as well as identifying the high level goals leading to an ESAPI 3.0.0 release.

2) WRT Travis v. Jenkins - I am partial to Jenkins, however no one presently owns our Jenkins instance (it just kind of chugs along) - if someone is willing to take ownership of either Jenkins or Travis I am impartial to what actually performs the builds. The key to me is that we have a continuous build, a nightly build artifact pushed to Maven Central, and trackable testing. The ability to automate the release process through CI/CD would also be ideal.

[chrisisbeef]

One last thing - I will be switching this project to Gitflow (introducing a devel branch and locking master) today. Please fork from devel for any work you would like to do specifically in this project and I will (for now) take the lead on reviewing PR's to devel from your fork.

[xeno6696]

I've volunteered for esapi-java-legacy, I can volunteer here as well. I can handle the CI pieces. I've never used Travis, but I have used Jenkins extensively.

On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt notifications@github.com wrote:

All -

1) WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both potential GSoC tasks as well as identifying the high level goals leading to an ESAPI 3.0.0 release.

2) WRT Travis v. Jenkins - I am partial to Jenkins, however no one presently owns our Jenkins instance (it just kind of chugs along) - if someone is willing to take ownership of either Jenkins or Travis I am impartial to what actually performs the builds. The key to me is that we have a continuous build, a nightly build artifact pushed to Maven Central, and trackable testing. The ability to automate the release process through CI/CD would also be ideal.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201318408

[jaxley]

Nobody owning Jenkins is a recipe for #fail. If we don't have that managed and patched, any builds off of that are going to be suspect and ripe targets for bad actors. There have been 4 RCE vulns in it lately. I see it is updated to the patched version at least so that's a good sign.

Jason

On Fri, Mar 25, 2016, 7:45 AM Matt Seil notifications@github.com wrote:

I've volunteered for esapi-java-legacy, I can volunteer here as well. I can handle the CI pieces. I've never used Travis, but I have used Jenkins extensively.

On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt notifications@github.com wrote:

All -

1) WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both potential GSoC tasks as well as identifying the high level goals leading to an ESAPI 3.0.0 release.

2) WRT Travis v. Jenkins - I am partial to Jenkins, however no one presently owns our Jenkins instance (it just kind of chugs along) - if someone is willing to take ownership of either Jenkins or Travis I am impartial to what actually performs the builds. The key to me is that we have a continuous build, a nightly build artifact pushed to Maven Central, and trackable testing. The ability to automate the release process through CI/CD would also be ideal.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201318408

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201319361

[ramzimaalej]

I can help on configuring Jenkins. Are we going to have a JIRA or we will stick to github for release management ?

2016-03-25 10:45 GMT-04:00 Matt Seil notifications@github.com:

I've volunteered for esapi-java-legacy, I can volunteer here as well. I can handle the CI pieces. I've never used Travis, but I have used Jenkins extensively.

On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt notifications@github.com wrote:

All -

1) WRT Roadmap - I checked in /ESAPI-3.0.0-ROADMAP.md highlighting both potential GSoC tasks as well as identifying the high level goals leading to an ESAPI 3.0.0 release.

2) WRT Travis v. Jenkins - I am partial to Jenkins, however no one presently owns our Jenkins instance (it just kind of chugs along) - if someone is willing to take ownership of either Jenkins or Travis I am impartial to what actually performs the builds. The key to me is that we have a continuous build, a nightly build artifact pushed to Maven Central, and trackable testing. The ability to automate the release process through CI/CD would also be ideal.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201318408

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201319361

Cheers, Ramzi

[kwwall]

PLEASE... move ESAPI 3.x wherever you want, but LEAVE esapi-java-legacy on GitHub where it is!!!

-kevin Sent from my Droid; please excuse typos. On Mar 25, 2016 10:44 AM, "Chris Schmidt" notifications@github.com wrote:

One last thing - I will be switching this project to Gitflow (introducing a devel branch and locking master) today. Please fork from devel for any work you would like to do specifically in this project and I will (for now) take the lead on reviewing PR's to devel from your fork.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201319111

[kwwall]

@chrisisbeef Disregard my previous comment. Initially, I thought you were talking about some new Git repository names something like gitflow.org or gitflow.com, but I realize now that you were talking about https://github.com/nvie/gitflow, so go for it!

[b-long]

I'll volunteer, but only if we're going with something more modern than Jenkins. It's a huge attack target, and honestly I don't think Jenkins core is very concerned with feature development and bug fixes. They're bogged down by exploits.

AppVeyor and Travis are all more robust and free when working in open source. On Mar 25, 2016 4:46 PM, "Kevin W. Wall" notifications@github.com wrote:

@chrisisbeef https://github.com/chrisisbeef Disregard my previous comment. Initially, I thought you were talking about some new Git repository names something like gitflow.org or gitflow.com, but I realize now that you were talking about https://github.com/nvie/gitflow, so go for it!

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-201492061

[bkimminich]

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?

Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?

If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...

...so, where's the sales pitch? :moneybag:

[chrisisbeef]

@bkimminich - The mission of ESAPI hasn't changed. The execution however is what is changing. ESAPI provides a central repository for security controls that developers can use. More importantly, it provides enterprise organizations with the ability to set a security policy and make security decisions that can be distributed across the entirety of the application portfolio.

[xeno6696]

As I understand the goal is to have a standardized security API so that backend implementations can be swapped out. Other security providers would have to conform to the OWASP interface, so it would be more or less an open standard... the sales pitch would be similar to using slf4j instead of concrete loggers, IMHO.

On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich notifications@github.com wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?

Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?

If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...

...so, where's the sales pitch? [image: :moneybag:]

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

[kwwall]

Yep. I think that's at least the theory. The reality is that 99% either use the ESAPI reference implementation or they don't use that feature at all. In fact the only exception that I've seen to that is other OWASP projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer, etc.). So there's that difference between theory and practice that seems to always come back and bite us in the ass.

The major downside to that IMO is that we have a lot of good security interfaces in ESAPI that are never used because all we have for the reference implementation are "toy" PoC implementations (e.g., authN & authZ). And if someone is building out implementations for them, they certainly are not being shared.

-kevin Sent from my Droid; please excuse typos. On Apr 1, 2016 10:39 AM, "Matt Seil" notifications@github.com wrote:

As I understand the goal is to have a standardized security API so that backend implementations can be swapped out. Other security providers would have to conform to the OWASP interface, so it would be more or less an open standard... the sales pitch would be similar to using slf4j instead of concrete loggers, IMHO.

On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich notifications@github.com wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?

Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?

If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...

...so, where's the sales pitch? [image: :moneybag:]

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

[ramzimaalej]

I believe that the first milestone should focus on a small set of interfaces (The most used ones) and provide a RI. We can then extend it later to add new features. I used OWASP when I was working for an insurance company. We mostly used the encoder to sanitize log entries and encode data. IMO, I think we should start off concrete use cases to better brainstorm the interfaces we need.

2016-04-01 11:19 GMT-04:00 Kevin W. Wall notifications@github.com:

Yep. I think that's at least the theory. The reality is that 99% either use the ESAPI reference implementation or they don't use that feature at all. In fact the only exception that I've seen to that is other OWASP projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer, etc.). So there's that difference between theory and practice that seems to always come back and bite us in the ass.

The major downside to that IMO is that we have a lot of good security interfaces in ESAPI that are never used because all we have for the reference implementation are "toy" PoC implementations (e.g., authN & authZ). And if someone is building out implementations for them, they certainly are not being shared.

-kevin Sent from my Droid; please excuse typos. On Apr 1, 2016 10:39 AM, "Matt Seil" notifications@github.com wrote:

As I understand the goal is to have a standardized security API so that backend implementations can be swapped out. Other security providers would have to conform to the OWASP interface, so it would be more or less an open standard... the sales pitch would be similar to using slf4j instead of concrete loggers, IMHO.

On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich < notifications@github.com> wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?

Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?

If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...

...so, where's the sales pitch? [image: :moneybag:]

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204435811

Cheers, Ramzi

[xeno6696]

I would be very interested to know if anyone IS building out authentication implementations... in my experience, (all with big companies) they use something like Oracle OAM/OID tied into LDAP, so there's little drive for an auth implementation.

On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall notifications@github.com wrote:

Yep. I think that's at least the theory. The reality is that 99% either use the ESAPI reference implementation or they don't use that feature at all. In fact the only exception that I've seen to that is other OWASP projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer, etc.). So there's that difference between theory and practice that seems to always come back and bite us in the ass.

The major downside to that IMO is that we have a lot of good security interfaces in ESAPI that are never used because all we have for the reference implementation are "toy" PoC implementations (e.g., authN & authZ). And if someone is building out implementations for them, they certainly are not being shared.

-kevin Sent from my Droid; please excuse typos. On Apr 1, 2016 10:39 AM, "Matt Seil" notifications@github.com wrote:

As I understand the goal is to have a standardized security API so that backend implementations can be swapped out. Other security providers would have to conform to the OWASP interface, so it would be more or less an open standard... the sales pitch would be similar to using slf4j instead of concrete loggers, IMHO.

On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich < notifications@github.com> wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?

Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?

If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...

...so, where's the sales pitch? [image: :moneybag:]

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204435811

[chrisisbeef]

Here's the problem guys - everyone's needs are completely different, and more often than not, even when people need the same controls, they need those controls implemented in different ways with different rules or leveraging different platforms. The aim of ESAPI 3.x was to allow people to truly use ESAPI as an API, there should be no focus on a RI because that's how ESAPI ended up the bloated massive framework that it has become. The focus of 3.x is to provide the interfaces and an extensible and pluggable framework wherein controls can be plugged in. This will allow enterprises and small development shops alike to use ESAPI without having a bunch of (as Kevin likes to call it) toy code and bloat that they will never use while providing all the benefits of a centrally managed repository of security controls that developers can use.

Does that clarify?

[kwwall]

On Sun, Apr 3, 2016 at 11:54 PM, Matt Seil notifications@github.com wrote:

I would be very interested to know if anyone IS building out authentication implementations... in my experience, (all with big companies) they use something like Oracle OAM/OID tied into LDAP, so there's little drive for an auth implementation.

On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall notifications@github.com wrote:

Yep. I think that's at least the theory. The reality is that 99% either use the ESAPI reference implementation or they don't use that feature at all. In fact the only exception that I've seen to that is other OWASP projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer, etc.). So there's that difference between theory and practice that seems to always come back and bite us in the ass.

The major downside to that IMO is that we have a lot of good security interfaces in ESAPI that are never used because all we have for the reference implementation are "toy" PoC implementations (e.g., authN & authZ). And if someone is building out implementations for them, they certainly are not being shared.

​I've spent the past 5 years in two primary capacities working for 2 different ​F200 companies--one in the telecom sector and one in the financial sector--doing secure architect / design reviews and secure code reviews respectively. During those 5 years, I have the perspective of being involved with close 200+ different (total) applications from 2 different companies. I did not keep exact figures, but if I had to hazard a guess based on my recollection (which shouldn't probably be trusted as I usually can't even remember what I ate for supper 2 days ago :), I would say that 25-35% of those applications built their own custom authentication system (90% of which used some sort of custom DB schema), around 30-40% used some sort of corporate directory solution (e.g., Active Directory, Integrated Windows Authentication, or corporate LDAP), and the remaining 25-45% used some sort of COTS web access management solution such as RSA Access Manager, CA SiteMinder, or Oracle OAM/OID. In my security architect reviewer role, I tried to steer people towards the WAM solution or at least towards something like IWA/AD/LDAP and away from a custom solution. But there is a lot more legacy software out there then one might realize. The strong "selling" point of WAM solutions is that they offer cheap yet simplistic (non-federated) SSO out-of-the-box. I think situation is much different in green field applications where they likely would chose a COTS security appliance if there is enterprise support for one and if their isn't they might choose something like some OAuth2 implementation or something supported out of the box by Spring Security, etc.

As an aside, I always felt that we blew it in not at least providing a simple LDAP reference implementation based on JNDI for ESAPI 2.x. That is very simple to implement and at least realistically useful (assuming one as a corporate LDAP infrastructure, which you do if you have Windows AD). The downside is that it would make testing it using JUnit a minor PITA since most ESAPI developers do not run there own LDAP servers on the dev boxes. Today, that probably isn't a major obstacle as one could set that up and deploy using some lightweight container management tool such as Docker, Vagrant, Puppet, Chef, etc. Sure, the container management would be an additional test-time dependency, but it would n ot be a run-time dependency. But back in the day when ESAPI 2.0 was first being rolled out all we had were more heavyweight VMs and many of us did not have the needed CPU or memory to get decent performance from those. Had we provided a reference implementation for authN, then some of the ESAPI Java servlet filters would also have been useful and I think we would have seen those have become heavily used ESAPI components, not quite as frequently used as ESAPI encoders and validators, but definitely more than an occasional blip on the radar.

​But hindsight is 20/20. I think our biggest mistake by far was trying to build a monolithic system--one security library to serve them all.

Anyhow, I've already rambled on long enough for this to be another TL;DR post.​

​kevin​

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

[kwwall]

On Mon, Apr 4, 2016 at 10:05 AM, Chris Schmidt notifications@github.com wrote:

Here's the problem guys - everyone's needs are completely different, and more often than not, even when people need the same controls, they need those controls implemented in different ways with different rules or leveraging different platforms. The aim of ESAPI 3.x was to allow people to truly use ESAPI as an API, there should be no focus on a RI because that's how ESAPI ended up the bloated massive framework that it has become. The focus of 3.x is to provide the interfaces and an extensible and pluggable framework wherein controls can be plugged in. This will allow enterprises and small development shops alike to use ESAPI without having a bunch of (as Kevin likes to call it) toy code and bloat that they will never use while providing all the benefits of a centrally managed repository of security controls that developers can use.

Does that clarify?

​Well, it makes sense to me, and I buy into the general sentiment at least. There is no doubt that ESAPI 2.x and earlier was designed as a bunch of monolithic components. (But even if we had zero RI for ESAPI, I still think that the 2.x and earlier interfaces were a little too co-mingled for my taste​. Indeed if that were not the case, why not just keep all the interfaces as-is for ESAPI 3.0 and simply ditch the reference implementation?)

However, I also want to say on thing here...except for very rare occasions where you are working either with either recognized standards bodies (like IETF, W3C, ISO, NIST, etc.) or a large industry-backed consortium, having a minimally useful working model (which is at least one step up from a "toy" implementation IMO) is essential, to getting developers to adopt your interfaces / API. In part, it goes back to that "the proof is in the pudding" mentality, but more-so, we hackers have to have something to get our hands on and be able to take apart and see how it works and put it back together (albeit possibly differently). A RI is important in being able to "play" with the API to see what it can do, to see how it can be extended. That is not to say that we need to write out own RI; we can get a lot of mileage by just taking someone else's Encoder (say) and packing them up by wrapping them behind some glue to our new interfaces. But we MUST NOT 1) deploy the RI as though it were part of the interfaces, and 2) deploy all the RI as one large monolithic RI jar.

I have always felt that the UNIX philosophy minimalist, modular software was the right approach. Each module doing one thing well, but having the ability to "hook into" other modules somehow. I am somewhat cautiously optimistic about the whole micro-services movement (versus the more monolithic SOA components that the past 10 years have tended toward). If we don't make the same security mistakes all over again (which, is the main reason for my caution), we could actually come out ahead.​ People are finally starting to realize the downside of software bloatware in terms of its added complexity, performance impact, etc. If you aren't interested in using it, then you shouldn't be forced to carry it around as part of your application.

Now, having said that, I think that we have a difficult task ahead of us. The expectations of developers who have used ESAPI are hire so 3.0 has to be way better than 2.x for them to let the latter go. (And while we could kill off 2.x officially now, I personally think that completely sends the wrong message. If we do that, I think dev teams considering adopting 3.0 will look and say "they dropped 2.x just like that and didn't support those users so what assurance do I have that they will support 3.0?) So that's one thing. The other is that this time around, I think it's going to be much more difficult getting a core group of volunteers on a long term basis to see this through. Chris and I are willing to help but we cannot carry the entire load ourselves.

​kevin​

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

[chrisisbeef]

I agree empirically with nearly everything @kwwall says here - the need to modernize and componentize ESAPI in a meaningful way that aligns with the way software is both written (framework-centric development) and deployed (micro-services) in modern applications is important, as is the ability to continue to support enterprise and legacy applications. The ability for an enterprise security team to distribute a central policy that is enforced in their entire application suite is as important as it is for the developer implementing a set of micro services for their mobile app to be able to quickly re-use policy and controls that they have used in the past, and the ability swap components in and out of the api on an as-needed basis (or consequently implement multiple controls to solve the same set of problems based on the constraints at runtime. Additionally the need for things to just happen is becoming more and more important - as a developer I should never have to explicitly verify a user is authenticated or output is escaped in the correct context, because we have proven time and again that when left to their own devices the vast majority of developers will do it wrong - not because they are incapable, but because they don't understand the intricacies (nor should they have to) of contextual property aware escaping or exactly how to ensure the validity of an OAuth token. These concerns all matter and should be reflected in the design of the API.

[ghost]

Count me in as a willing contributor. I've worked on the Legacy ESAPI a few years back, ~2009 (I think).

[kwwall]

At one point I contributed a JNDI LDAP implementation to OWASP AppSensor, although I don't know if they are still using it. Still, the implementation is easy enough and on the plus side, doesn't require any additional dependencies. IF we are going to provide a reference implementation, to me, that seems the better way to go than using a DB as almost everyone can either stand up an OpenLDAP instance or point it an AD LDAP interface. Of course, IMHO, the reason that it probably has not been done is because it makes the JUnit tests for authentication way more complicated because all of a sudden you have a dependency of a DB or LDAP instance that you have to preload with some data. I suppose we could figure all of that out using some sort of container like Docker, Vagrant, etc, or extensive scripting but it's difficult to make portable and back in 2009, I don't think light weight containers were probably viable options.

-kevin

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.

On Apr 3, 2016 23:54, "Matt Seil" notifications@github.com wrote:

I would be very interested to know if anyone IS building out authentication implementations... in my experience, (all with big companies) they use something like Oracle OAM/OID tied into LDAP, so there's little drive for an auth implementation.

On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall notifications@github.com wrote:

Yep. I think that's at least the theory. The reality is that 99% either use the ESAPI reference implementation or they don't use that feature at all. In fact the only exception that I've seen to that is other OWASP projects making drop in replacements (e.g., AppSensor, Java HTML Sanitizer, etc.). So there's that difference between theory and practice that seems to always come back and bite us in the ass.

The major downside to that IMO is that we have a lot of good security interfaces in ESAPI that are never used because all we have for the reference implementation are "toy" PoC implementations (e.g., authN & authZ). And if someone is building out implementations for them, they certainly are not being shared.

-kevin Sent from my Droid; please excuse typos. On Apr 1, 2016 10:39 AM, "Matt Seil" notifications@github.com wrote:

As I understand the goal is to have a standardized security API so that backend implementations can be swapped out. Other security providers would have to conform to the OWASP interface, so it would be more or less an open standard... the sales pitch would be similar to using slf4j instead of concrete loggers, IMHO.

On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich < notifications@github.com> wrote:

I've read the roadmap for GSoC, but it doesn't really give me a clear picture where this is going long term. You plan to wrap the "best available security libs out there" for each purpose behind common interfaces, right? This would make ESAPI something like a "Maven-plug-and-play-security-lib-collection" - is that the idea behind it?

Other than that, where is the unique benefit that ESAPI brings developers instead of just plugging libraries from here-and-there together themselves?

If I'm buying the reason why ESAPI 3.0 is going to be the best thing out there to me, I'm totally willing to help with some implementation, test automation and code analysis stuff...

...so, where's the sales pitch? [image: :moneybag:]

— You are receiving this because you commented. Reply to this email directly or view it on GitHub <https://github.com/ESAPI/esapi-java/issues/3#issuecomment-202847437

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204420907

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-204435811

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/ESAPI/esapi-java/issues/3#issuecomment-205123441

[jackycct]

@kwwall I am very interested to help as I am maintaining the ESAPI for my enterprise. There are a few fixes and enhancements on ESAPI 2.1.0.1 readily for contribution.

[kwwall]

@jackycct I am glad to hear that and we are eager to receive your contributions. However ESAPI 2.x is being maintained and developed under https://github.com/ESAPI/esapi-java-legacy, not here. This was intended to be for ESAPI 3.0, or ESAPI "next generation" if you will. Unfortunately, it never gained much traction and it's pretty much that all Matt (@xeno6696) and I can try to fix bugs in the ESAPI 2.x release and periodically put out a new release of that.

For starters, check out the README.md file in ESAPI 2.x, especially the section "Contributing to ESAPI legacy". If you need more information, the best way to contact the ESAPI developers is through the ESAPI-Developers mailing list mentioned at the end of the README file.

[jackycct]

Thanks @kwwall for your prompt reply.

I plan to contribute some dependencies upgrade to resolve opensource vulnerabilities as a start. Does it make sense to contribute to 2.x or 3.x?

[kwwall]

@jackycct Starting with ESAPI 2.x definitely makes more sense at this point. However, if you look at the latest pom.xml in the 'develop' branch as well as the PR for issue #419 for ESAPI 2.x that I pushed but is not yet merged, I think that covers all the vulnerable dependencies recognized by OWASP Dependency Check. Although feel free to double-check.

As far as the next ESAPI 2.x release, we've run into a bit of a hiccup in regards to some tests that have started failing that are pointing to deeper issues. @xeno6696 and @jeremiahjstacey are working that issue, but I feel its important enough to address before we push out a release.

In regards to ESAPI 3.x, I think there's a lot to debate there. One one hand, I'm not comfortable with all the current ESAPI 2.x interfaces (especially some of the crypto ones, which is where I've been focused), so I think it's fair game to propose alternatives for 3.x (if / when we ever get to that). But OTOH, I've seen first hand the disaster that resulted from (in part at least) from the lack of an adequate migration plan from Struts 1.x to Struts 2.x. Even to this day, I still encounter Struts 1.x applications. I don't want that to happen with ESAPI so we have to address such issues up front.

Anyway, for anyone wanting to continue the discussion of this, please sign up and more the discussion to the ESAPI-Developers mailing list. At this point, I'm closing this issue with an official "I don't know when the first ESAPI 3.0 release will be. It is still very much TBD."