First 3.0.0 release date? about esapi-java HOT 35 CLOSED

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" [email protected] 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

from esapi-java.

👍

from esapi-java.

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

from esapi-java.

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 [email protected] 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

from esapi-java.

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 [email protected]
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 [email protected] 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.

from esapi-java.

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

from esapi-java.

Hey Guys,

I can help as well.

Thanks,
Ramzi

2016-03-14 19:00 GMT-04:00 Brian Long [email protected]:

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

from esapi-java.

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 [email protected].
(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 [email protected]
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.

from esapi-java.

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.

from esapi-java.

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

from esapi-java.

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 [email protected] 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

from esapi-java.

​On Thu, Mar 17, 2016 at 1:48 PM, Chris Schmidt [email protected]
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​

from esapi-java.

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.

from esapi-java.

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.

from esapi-java.

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 [email protected]
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

from esapi-java.

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 [email protected] 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 [email protected]
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

from esapi-java.

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 [email protected]:

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 [email protected]
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

from esapi-java.

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" [email protected] 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

from esapi-java.

@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!

from esapi-java.

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? 💰

from esapi-java.

@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.

from esapi-java.

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 [email protected]
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: 💰]

—
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

from esapi-java.

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" [email protected] 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 [email protected]
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: 💰]

—
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

from esapi-java.

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 [email protected]:

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" [email protected] 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 <
[email protected]>
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: 💰]

—
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

from esapi-java.

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 [email protected]
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" [email protected] 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 <
[email protected]>
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: 💰]

—
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

from esapi-java.

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?

from esapi-java.

On Sun, Apr 3, 2016 at 11:54 PM, Matt Seil [email protected] 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 [email protected]
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.

from esapi-java.

On Mon, Apr 4, 2016 at 10:05 AM, Chris Schmidt [email protected]
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.

from esapi-java.

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.

from esapi-java.

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

from esapi-java.

from esapi-java.

@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.

from esapi-java.

@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.

from esapi-java.

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?

from esapi-java.

@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."

from esapi-java.