First 3.0.0 release date? #3
Comments
|
👍 |
|
Nothing specific is planned at this time. No volunteers. :( |
|
Kevin, maybe I'm missing the point but... ok no volunteers but does the I think we should start working on this and then look for the volunteers. paolo On 14 March 2016 at 18:29, Kevin W. Wall [email protected] wrote:
$ cd /pub I pirati della sicurezza applicativa: https://codiceinsicuro.it |
|
Most of my energy is spent on ESAPI legacy, which If someone wants to jump in and fork the project, So, please, pitch in. Propose a road map. Propose interfaces! Thanks, On Mon, Mar 14, 2016 at 6:36 PM, Paolo Perego [email protected]
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall |
|
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, |
|
Hey Guys, I can help as well. Thanks, 2016-03-14 19:00 GMT-04:00 Brian Long [email protected]:
Cheers, |
|
No. My @owasp.org address doesn't seem to be working. On Mon, Mar 14, 2016 at 7:00 PM, Brian Long [email protected]
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall |
|
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. |
|
If you're looking for volunteers, I'm happy to help! Are you accepting new folks in the ESAPI organization? |
|
All - I've been out of town (and out of touch) for the last weeks - give me On Tuesday, March 15, 2016, Brian Long [email protected] wrote:
~C |
|
On Thu, Mar 17, 2016 at 1:48 PM, Chris Schmidt [email protected]
@chrisisbeef - works for me. And also throw in your $.02 Let's just not wait too long because Google Summer of Code -kevin |
|
All -
|
|
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. |
|
I've volunteered for esapi-java-legacy, I can volunteer here as well. I On Fri, Mar 25, 2016 at 9:43 AM Chris Schmidt [email protected]
|
|
Nobody owning Jenkins is a recipe for #fail. If we don't have that managed Jason On Fri, Mar 25, 2016, 7:45 AM Matt Seil [email protected] wrote:
|
|
I can help on configuring Jenkins. Are we going to have a JIRA or we will 2016-03-25 10:45 GMT-04:00 Matt Seil [email protected]:
Cheers, |
|
PLEASE... move ESAPI 3.x wherever you want, but LEAVE esapi-java-legacy on -kevin
|
|
@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! |
|
I'll volunteer, but only if we're going with something more modern than AppVeyor and Travis are all more robust and free when working in open
|
|
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? 💰 |
|
@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. |
|
As I understand the goal is to have a standardized security API so that On Tue, Mar 29, 2016 at 6:50 AM Björn Kimminich [email protected]
|
|
Yep. I think that's at least the theory. The reality is that 99% either The major downside to that IMO is that we have a lot of good security -kevin
|
|
I believe that the first milestone should focus on a small set of 2016-04-01 11:19 GMT-04:00 Kevin W. Wall [email protected]:
Cheers, |
|
I would be very interested to know if anyone IS building out authentication On Fri, Apr 1, 2016 at 10:19 AM Kevin W. Wall [email protected]
|
|
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? |
|
On Sun, Apr 3, 2016 at 11:54 PM, Matt Seil [email protected] wrote:
I've spent the past 5 years in two primary capacities working for 2 As an aside, I always felt that we blew it in not at least providing a But hindsight is 20/20. I think our biggest mistake by far was trying to Anyhow, I've already rambled on long enough for this to be another TL;DR kevin Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall |
|
On Mon, Apr 4, 2016 at 10:05 AM, Chris Schmidt [email protected]
Well, it makes sense to me, and I buy into the general sentiment at least. However, I also want to say on thing here...except for very rare occasions I have always felt that the UNIX philosophy minimalist, modular software Now, having said that, I think that we have a difficult task ahead of us. kevin Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall |
|
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. |
|
Count me in as a willing contributor. I've worked on the Legacy ESAPI a few years back, ~2009 (I think). |
|
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" ***@***.***> 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 ***@***.***>
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" ***@***.***> 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 <
> ***@***.***>
> > 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
> > > <#3 (comment)
>
> > >
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly or view it on GitHub
> > <#3 (comment)>
> >
>
> —
> You are receiving this because you commented.
>
> Reply to this email directly or view it on GitHub
> <#3 (comment)>
>
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<#3 (comment)>
|
|
@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. |
|
@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. |
|
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? |
|
@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." |
Any news when the first version of 3.0.0 will be released?
Thank you.
The text was updated successfully, but these errors were encountered: