[Esapi-user] Speak Louder + Ethics

Jim Manico jim.manico at owasp.org
Sun Jan 17 05:31:02 EST 2010


> *_And, I will stop offering my opinion on this item if you ask_*

I will answer this email in more detail later - but I want to stop you
in your tracks over the issue of stopping in your tracks, Mike. ;)
Please never stop offering you opinion - ESPECIALLY if you are getting
flack from everyone. Leaders charge forward, often against the grain. We
are braving new territory here for OWASP and we need all the advice we
can get.

So hang tight, I (and I'm sure others) will respond to this soon. And if
anyone every tells you to "be quiet" on the ESAPI team, especially me,
that's really a code word to _*speak louder*_. :)

On this note, lets talk ethics for just a moment. I'm taking a page from
the Apache foundation http://www.apache.org/foundation/glossary.html -
they judge merit with only three simple criteria:

- technical competence 
- ability to get along with others 
- positive contributions to discussions and code

The other key point is to "criticize the person rather than the idea".
While it is acceptable (indeed, encouraged) to criticize an idea, it is
not acceptable to criticize the person suggesting the idea. The
foundation lists must be a safe place where developers can brainstorm
without fear of being insulted or flamed.
(http://wiki.apache.org/incubator/CodeOfConduct)

I am far from perfect when it comes to these ideas, so I post them on a
somewhat regular basis to remind myself as well.

Short answer: /Bring It On/, Mike! :)

More soon,

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net







> Since you ask... I'll continue to offer... this is not a good idea in
> my opinion. I don't see an "issue" here in the first place. I don't
> think "destructive" is too strong a word actually, don't mean to flame
> though. *_And, I will stop offering my opinion on this item if you
> ask, no worries. _*I am offering it since you continue to ask with the
> broadcast requests.
>
> There needs to be at least one "release" version, however you want to
> do it. The cat's out of the bag, having two "major.minor" releases
> (1.4 and 2.0) already in the wild. So, plan on a 3.0 if there are
> major things that you think are still lacking. It'd be great to have
> such a product roadmap or have this survive that long before someone
> productizes this/something equivalent and this project becomes
> marginalized. Hopefully there will be a surge of open source resources
> before that happens, a la Red Hat model.
>
> Not having at least one "good" (before jump on the use of this word,
> please read next paragraph after carefully reading this one) baseline
> takes the legs out from under this project. _*The argument that any
> use of any variation or extension or adaptation of ESAPI is at least
> designed for/based on a proven stable definitive solution goes away.*_
> The basic argument in my neck of the woods against using OWASP
> documents and tools in general is that customers don't ask for them,
> and the basic explanation of why customers don't ask for them is that
> the perception is they are all just kind of fun science experiments
> with perhaps little bits of helpful things here and there, but that's
> it. Not trying to be harsh or mean, I have had this feedback nearly
> verbatim many times, and there were those earlier emails on this list
> saying that it's important to listen to feedback.
>
> So, adoption is really based on perception, not technical merit.
> Technical stuff can always be fixed, can always add another function
> or some such. The business (no-technical) stuff can't, can't make
> someone like something or someone. This toolkit is _*so *_specialized,
> this is WAY more specialized that even OpenSSL which keeps being
> mentioned, there is never going to be the same uptake as some generic
> library or widget, holding it to that sort of a measure is a standard
> that's not achievable. I wrote earlier, you guys aren't realizing how
> much magic there is in what you've got so far. The current Java should
> be a 5.x release or something, not exaggerating too terribly much. In
> my mind, so what if it's not super-pretty for example from a generic
> design patterns point of view. The goal of ESAPI is to help guard
> against data spills by making it as easy as possible on the developer.
> Most of the "problems" that I see on the lists are with ESAPI are due
> to lack of instruction, of written down knowledge that can be
> transferred. A lot of the more detailed problems talked about on this
> list, most new adopters won't hit those for quite some time, if ever.
> When to use it. How to plan for its use. How to roll it out. How to
> select combinations of controls to target a level of assurance. What
> combinations of platforms will it work on. On and on. Commercial
> products have ideas of "supported configurations", where only usages
> according to their documentation are supported by the company. Do that
> here and I guarantee that (1)any immediate problems will be found
> faster than they are now, and (2)problems will taper off dramatically.
>
> No apologies for long email, again I have been asked to explain what
> otherwise I would have left a 2-3 sentence first paragraph. So, flame
> off, if that's how it was read. I hope not though. Trying to help. To
> try to be a little bit "lighter" about this, picture me as the Mr. T
> of app sec world: I don't like to talk, I prefer to take action and
> build something or whatever, but if I'm going talk, I'm going to speak
> my mind. I actually grew up as a neighbor to Mr. T, so that may also
> explain certain similarities in terms of any perceived grumpiness.
> Man, I wish I had at least enough hair for a mohawk, though.
>
> Best,
>
> Mike/Mr. B
>
>
> On Sat, Jan 16, 2010 at 10:11 PM, Jim Manico <jim.manico at owasp.org
> <mailto:jim.manico at owasp.org>> wrote:
>
>     I think this is an excellent compromise, and it's my favorite
>     solution to this issue so far.
>
>     +1 (3 votes so far).
>
>     I'm not going to make this change right away (still on track for
>     1.4.2 this weekend) - but I would like to fairly soon.
>
>     This is a very critical change; I'd be curious to hear what others
>     have to say.
>
>     - Jim
>
>>     I agree with you here. I am in a similar situation (discounting
>>     the waiting for legal) with finally getting the buy-in from the
>>     company to integrate ESAPI into our codebase. Had it carried with
>>     it a BETA label it definately would have made it far more
>>     difficult, if not impossible, to get the buy in from management.
>>
>>     I think that where we are right now is acceptable, and if
>>     anything, taking it back to a pre 1.0 release level would have
>>     the same basic effect without the negative stigma that goes along
>>     with labeling software as "beta" quality.
>>
>>     My alternate proposal would be to prefix the current ESAPI
>>     version with a 0.
>>
>>     So esapi 0.1.4.2 and esapi 0.2.0 respectively.
>>
>>     This allows us the luxery of time before a full 1.0 GA release of
>>     the API and carries a positive stigma with the development world.
>>     Plenty of libraries are in use and have been in use for years
>>     before they ever get to a 1.0 release. Had those same libraries
>>     been labeled beta, I highly doubt they would have gotten the
>>     adoption and implementation rates that they did (an example would
>>     be just about an utility that has ever been released for *nix)
>>
>>     Thoughts?
>>
>>     On Fri, Jan 15, 2010 at 4:39 PM, Ed Schaller
>>     <schallee at darkmist.net <mailto:schallee at darkmist.net>> wrote:
>>
>>         I guess I'll throw my $0.02 in.
>>
>>         > > 1) 100% Unit tests pass.
>>         > > 2) All classes must have unit tests.
>>         > > 3) Test coverage must test 100% of the "sunny day" paths
>>         and at least
>>         > >   80% of the total paths. (This will require using some
>>         sort of code
>>         > >   coverage during unit testing.)
>>         > > 4) At least 3 independent adoptions of the previous beta
>>         RC for the
>>         > >   given release must provide their approval.
>>         > > 5) All public features must be documented in terms of:
>>         > >   a) API documentation (e.g., Javadoc)
>>         > >   b) Document when this feature should be considered / used
>>         > >   c) Example(s) showing how this feature should be used
>>         > > 6) Once all these things are completed, we open it up to
>>         a formal
>>         > >   vote by the ESAPI-Users group and then it is only made
>>         GA if
>>         > >   they approve. (I would say by at least 60%, but your
>>         opinion may
>>         > >   vary.)
>>
>>
>>         I like your list a log Kevin and have some thoughts, but first:
>>
>>         <rant topic="esapi4j unit tests">
>>         I completely agree with the test parts and would add that
>>         those tests
>>         should use the test framework so we know about their passing
>>         instead of
>>         just System.out'ing it, don't create test files all over your
>>         system,
>>         clean up any test files that are created and don't assume
>>         that Redmond
>>         os is the only os.
>>
>>         Frankly, how can we ask people to trust easpi4j when our own unit
>>         tests fail?
>>
>>         To this end I've put in a lot of effort and I believe, and
>>         please correct
>>         me if I am wrong, that at least surefire thinks that all the
>>         unit tests
>>         in the 2.0 branch pass so we are making progress here.
>>         </rant>
>>
>>         Ah....sorry. To much SafeFileTest on the brain. Now that I
>>         have that
>>         out of my system...
>>
>>         Your list is an excellent list and it would be awesome if we
>>         could
>>         achieve it. My concern is that we may not have the resources
>>         to achieve
>>         this in a timely manner. Application developers need such
>>         tools now,
>>         even if they aren't perfect. They are far better than nothing.
>>
>>         I spend most of my time looking for ways to break into
>>         systems and
>>         writing reports on such. I got into esapi because I was asked
>>         to put
>>         together a "secure coding training pilot." XSS was the topic
>>         finally
>>         settled on. Putting such together it became very clear that
>>         there was
>>         a great lack of tools even for such a simple matter as
>>         encoding. ESAPI
>>         was the only one I found that met my requirements. I
>>         certainly could
>>         have implemented my own encoders (which is what I ultimately
>>         had to do
>>         in JS for DOM based XSS).
>>
>>         It took a month to work through the technical reviews where I
>>         work and
>>         this is astounding in it's speed (yes... it's that bad). Two
>>         months
>>         later and after a lot of pestering on my part it finally
>>         received legal
>>         approval. (I'm glad neither party knew the unit tests didn't
>>         pass...;)
>>
>>         I'm getting somewhere with this I hope....
>>
>>         Open source efforts will never be glossy and shiny as the
>>         marketing
>>         people make commercial software look because open source
>>         can't hide the
>>         broken parts. It thrives because it provides a standard and
>>         allows people
>>         to easily acquire and use it. If something doesn't work or do
>>         exactly
>>         what it is supposed to, like the JSP tags for example, it
>>         gives them a
>>         place to start instead building from scratch and trying to
>>         maintain it
>>         latter. I would probably never have gotten as far as JSP tags
>>         in my own
>>         implementation in the time and budget ($0.00) that I was
>>         given. With the
>>         starting place of ESAPI, even with it's flaws, I was able to
>>         take the time
>>         to learn how to fix up JSP tags and even add EL methods. This
>>         provides
>>         much better tools for my employer's developers and
>>         potentially helps a
>>         lot of others. Additionally, when I found that the encoders
>>         only white
>>         listed below 0x100 I could fix it. It would have taken months
>>         or years
>>         to release a fix if they ever would as they wouldn't see it
>>         as important.
>>
>>         Through this process I have also gained our developers a set
>>         of security
>>         tools that they can use and that I can point to when they
>>         don't do xyz
>>         I can point them to abc in ESAPI instead of telling them to
>>         implement
>>         it themselves. This is a great advantage moving forward.
>>
>>         As dumb as it sounds, if ESAPI 1.4 is ALPHA and ESAPI 2.0 is
>>         BETA than
>>         it would have taken far longer if ever to get it approved.
>>         Not releasing
>>         means only the folks who are willing to build from svn will
>>         use and
>>         test what's current. This can hurt the potential uptake of
>>         ESAPI. The
>>         encoders that spurred the whole thing are also stable even if
>>         the rest
>>         is not. They meet our current needs and I hope that my
>>         contributions
>>         have helped the project as a whole.
>>
>>         Open source projects need to "Release Early, Release Often"
>>         (http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html).
>>         If we wait until it's perfect it will never happen (I have
>>         plenty of
>>         code rotting on my disk to prove this).
>>
>>         When our user base is large enough to better support more formal
>>         requirements and testing we should reconsider but until then
>>         I'd suggest
>>         rolling out releases more quickly and get what we can out to
>>         the folks
>>         who need it. If it doesn't quite work for them we can fix it
>>         and maybe
>>         they'll help;)
>>
>>         I don't know. I hope my random meanderings help the
>>         discussion some and
>>         that folks will forgive my occasional ranting... Now I need
>>         to go eat
>>         my words and release some of my own rotting code.... after I
>>         feed the
>>         circling children plundering any food they can get their
>>         hands on.
>>
>>         >>>------>
>>
>>         -----BEGIN PGP SIGNATURE-----
>>         Version: GnuPG v1.4.10 (GNU/Linux)
>>
>>         iEYEARECAAYFAktQ/L4ACgkQ8kiOCKEpeEG+agCcDwtdBcTOu+1wtaGN7fgP4pim
>>         7nMAn1tKw3KIRYVAjbEvsswlsLWt14ti
>>         =AdHz
>>         -----END PGP SIGNATURE-----
>>
>>         _______________________________________________
>>         Esapi-dev mailing list
>>         Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>>         https://lists.owasp.org/mailman/listinfo/esapi-dev
>>
>>
>>
>>
>>     -- 
>>     -- Chris
>>
>>     OWASP ESAPI Developer
>>     http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
>>
>>     Check out OWASP ESAPI for Java
>>     http://code.google.com/p/owasp-esapi-java/
>>
>>     Coming soon OWASP ESAPI for JavaScript
>>     http://code.google.com/p/owasp-esapi-js/
>
>
>     -- 
>     Jim Manico
>     OWASP Podcast Host/Producer
>     OWASP ESAPI Project Manager
>     http://www.manico.net
>
>
>     _______________________________________________
>     Esapi-dev mailing list
>     Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100117/14a9775e/attachment.html 


More information about the Esapi-user mailing list