Repository navigation
Split ESAPI into Components #196
Description
From chrisisbeef on November 20, 2010 16:13:38
Splitting ESAPI into manageable components to reduce the footprint and allow developers to customize their implementation to fit their specific needs.
Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=186
Activity
xeno6696 commentedon Jul 31, 2017
@jeremiahjstacey
This sounds like something you'd be interested in too.
kwwall commentedon Jul 31, 2017
jackycct commentedon Oct 8, 2018
This is a very interesting story and we have been longing for this.
xeno6696 commentedon Oct 10, 2018
This was one of the reasons I came to this project actually... just... so many other issues to clear up first!
xeno6696 commentedon Oct 10, 2018
@jeremiahjstacey actually had a version of this in a test branch. I've long since lost the email, but I recall he had successfully splitted all of the components.
jeremiahjstacey commentedon Oct 10, 2018
Started down that path with https://github.com/jeremiahjstacey/esapi_reorg
The intention was to break the current implementation into API and Lib artifacts. API would be restricted to interfaces and contracts that can be applied to a solution. Lib would be the default implementation of the api offered by the ESAPI library. Most of what's there is focused around validation. I started to play with codecs but didn't have much momentum with it.
kwwall commentedon Jul 5, 2019
It is hard to conceive how we can easily do this without 1) a drastic re-architecture and decoupling of ESAPI, and 2) such changes are likely to impact the ESAPI interfaces. Changing interfaces would break backward compatibility of applications using ESAPI 2.x, so I think this needs deferred to ESAPI 3.0, which were are not going to promise as backward compatible with ESAPI 2.x. Therefore marking this as milestone 3.0.
AveryRegier commentedon Apr 3, 2020
The biggest issue for us with ESAPI is that it has a boatload of dependencies. These dependencies get out of date and themselves get security issues reported against them. Its just too much when all you need is one of the utility methods that Veracode trusts.
Perhaps the project could start with componentization by breaking out the things that have no dependencies into their own core library. Things like static methods that people often need would then be available without all the extra cruft.
After a review, the packages
org.owasp.esapi,org.owasp.esapi.utilandorg.owasp.esapi.errorscould be extracted into a core package completely backwards compatible. Those three have only references to each other, the JDK, and the servlet-api, which can be included as a provided dependency.Then start breaking things out by major dependency sets. Have a specific extension lib for SLF4J for instance. This should be backwards compatible. The biggest issue is supporting the module system. The module system requires that a given package be contained in just one jar. If there are multiple dependencies associated with a given package, then that's a point where you need to break compatibility and go to solve that issue in v3.
kwwall commentedon Apr 3, 2020
kwwall commentedon Apr 4, 2020
@AveryRegier - A longer answer, which I think you deserve. The biggest single problem is that ESAPI 1.x and 2.x were designed and packaged as a monolithic library of security controls. A decade or more ago, we talked about at least splitting out ESAPI into an ESAPI core and ESAPI reference implementation. The core would only contain the ESAPI interfaces and only the essential functionality (basically enough to more or less bootstrap the reference implementation. The 'core' would have very little dependencies, in fact not much more than what you describe. But we realized that if we packaged the 'reference implementation' part, it would pretty much have all the dependencies that the current ESAPI jar has, so that really wouldn't be a substantial win. So then we thought, well, we could split the reference implementation more granularly so would have separate reference implementation jars for each of the major components: one for the ESAPI Encoder, one for the ESAPI Validator, one for the ESAPI crypto, etc. The problem is that while most (we may have missed a few, but we could hunt those down and eliminate them) of the reference components used the ESAPI interfaces when they needed to access another component, in reality, there is way too much interdependencies on the components. For example, the DefaultSecurityConfiguration class in reality is used in every component so one automatically gets it plus any dependencies it requires. Everything also uses the ESAPI Logger so we would need an ESAPI-Logger dependency and since we defer the internal logging to what the requires, it would mean all those dependencies. Likewise the ESAPI Validator reference has dependencies on some of the ESAPI Encoder components (notably the Codecs). For that matter, even the ESAPI Logger has dependencies on the Codecs. So the bottom line, it gets pretty ugly the deeper you look.
That is not to say that this is a non-solvable problem, but rather one that just doesn't be solving in ESAPI 2.x. (There are a lot of other major design issues with ESAPI 2.x that need addressed as well besides the large number of dependencies. For example, the fact that almost every component is implemented as a singleton pattern which causes massive headaches for some of the components. Also many of the interfaces for the various components are way too bloated.) So the plan is to fix some of the major esapi-java-legacy GitHub issues and then wide down and start work on ESAPI 3.0. But we do not intend on fixing this in ESAPI 2.x.
kwwall commentedon Apr 4, 2020
@xeno6696 and @jeremiahjstacey - I've already marked this for the '3.0' milestone, but I was wondering if I should just close this issue (since 2.x is as far as we plan on going for esapi-java-legacy) and marking it as 'wontfix'. What are your thoughts about that vs just leaving it open? I technically don't think that we even need to mention this GitHub issue for https://github.com/ESAPI/esapi-java since getting rid of the huge # of dependencies by making it more modular has always been the main design goal for that. (Plus, I think in the not too distant future should work on a high level design proposal for ESAPI 3.x where we would include the design goals and we surely would mention this there.)