[OWASP-ESAPI] New ESAPI Java 2.0 encryption code committed to 2.0_quality branch

Jim Manico jim.manico at owasp.org
Tue Aug 25 01:50:48 EDT 2009


Ouch, public admission of test-last coding is definately poor form on  
my part. Especially for a utility library of this nature, unit tests  
are fundametal. (yes Jeff you can quote me on that)

Kevin, can we compromise on the process:
1) first code review the quality 2.0 branch
2) then add unit tests
3) then migrate into trunk?

And Kevin, thank you for all of your hard work on ESAPI. I realize  
your time with us is waning since your kids sports start soon, so I'm  
willing to speed up the process.

Does anyone wish to be a part of Kevins' Encryptor augmentation code  
review?

Jim Manico

On Aug 25, 2009, at 1:34 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> All OWASPI ESAPI developers...
>
> Had discussion w/ Jim Manico (see below) and he was in favor of me  
> getting these
> changes for the new ESAPI 2.0 encryption code committed ASAP even  
> though I have
> barely started unit testing. (I will try to start that tomorrow.)
>
> However, Jim and I are looking for volunteers to assist with a code  
> inspection.
> It probably would be helpful if you know some basic cryptography,  
> but that is
> not required.
>
> I will leave it up to Jim to select representatives from those among  
> you who
> volunteer--that way I will not unknowingly introduce any bias, etc.  
> So if
> you are interested in participating in a code inspection of the new  
> ESAPI
> encryption code, please contact Jim Manico and I'll leave it to him to
> arrange the logistics of the inspection. I imagine that we might want
> to use one of those free conference calling sites such as FreeConferenceCall.com
> etc.
>
> At the very end of this email--if you are interested--is a summary  
> of all the
> commits that I did in relation to this code. There is about 20 or so  
> files in
> all.
>
> Also please at least read through the thread below so you will  
> understand why
> I have not yet unit tested this code. It's not (just) because I'm  
> lazy. ;-)
>
> Regards,
> -kevin wall
> P.S.- I am seeing what can be done to stage a version of the Javadoc  
> for those
>      of you who are more ESAPI users rather than developers and who  
> wish to
>      take a look at what this is like. Jeff, Jim: Is there somewhere  
> we can
>      put this up at either owasp.org or at Google Code,
>      http://code.google.com/p/owasp-esapi-java/   ???
>
> Jim Manico wrote:
>> I'm in support of this methodology - I think GROUP code review like  
>> you
>> describe is the perfect way to go. Encryptor one review sounds  
>> reasonable.
>>
>> I'm especially a fan of "test last coding" - test first is a nice  
>> theory
>> but is also a huge time hit.
>>
>> So let's Rock! I want to be in on this code review....
>>
>> ... very glad this is all working out so well!
>>
>> Jim Manico
>>
>> On Aug 23, 2009, at 11:07 PM, "Kevin W. Wall"  
>> <kevin.w.wall at gmail.com>
>> wrote:
>>
>>> Jim,
>>>
>>> Just wanted to let you know where I am at. I did a bit of  
>>> refactoring
>>> of things
>>> which simplified some stuff a bit and also allowed me to support
>>> encryption /
>>> decryption with a specified SecretKey rather than just using the
>>> master key.
>>> (Using the master key is just a special case of this.)
>>>
>>> I pretty much have everything written EXCEPT JUnit tests. That
>>> probably will
>>> take another 6-8 hrs or so.
>>>
>>> Usually, at Qwest, we do our code inspections BEFORE writing /  
>>> running
>>> all
>>> the JUnit tests so we can get the biggest benefit from the many eyes
>>> looking
>>> at the code. If one is humble enough to accept others pointing out  
>>> the
>>> obvious
>>> flaws in your code, then one can benefit from them finding the  
>>> bugs so
>>> you
>>> don't have to spend as much time debugging your code while testing  
>>> it.
>>>
>>> So... I was thinking of approaching it this way, but let me know  
>>> your
>>> thoughts.
>>> I figure I'd commit all the code that I have changed to the
>>> 2.0_quality branch
>>> and then try to schedule 2 to 4 others for code inspections. (I  
>>> figure
>>> two is a
>>> minimum, and 4 others is probably a max, since w/ me that would make
>>> 5. However,
>>> I'm willing to do it "the OWASP way" if you have some inspection
>>> process you
>>> generally use.)  At Qwest, the roles that we have are a reader
>>> (usually the
>>> author), a moderator, a scribe, and N inspectors and usually try to
>>> keep the
>>> total # of participants to <= 5 and we usually try to hit an
>>> inspection rate
>>> of between 150-200 non-commentary source LOC / hour. But, like I  
>>> said,
>>> if OWASP
>>> as a different way, we can do it the OWASP way. NP with that.
>>>
>>> Anyway, my preference would be to commit my changes, then schedule
>>> inspections
>>> while continuing to write JUnit tests. I would then fix things  
>>> that as
>>> I find
>>> them, but would not necessarily commit those changes unless you  
>>> think
>>> it would
>>> be beneficial or unless the changes are major. (Could let those
>>> planning on
>>> participating in the inspection that changes were made and let them
>>> rule on
>>> whether I should commit those changes too. If they hadn't started
>>> reviewing that
>>> particular code, that probably would be the best approach.)
>>>
>>> Anyhow, let me know how to proceed from here. Shall I commit  
>>> changes,
>>> how to
>>> schedule the inspections, etc.?
>>>
>>> Thanks,
>>> -kevin
>>> P.S.- Also, assuming you have already inspected the 1.4 baseline  
>>> code,
>>> do we
>>>     only want to inspect the changes for things line Encryptor or
>>> reinspect
>>>     everything? That makes a big difference in how much time we  
>>> need to
>>>     schedule.
>>> -- 
>>> Kevin W. Wall
>>> "The most likely way for the world to be destroyed, most experts  
>>> agree,
>>> is by accident. That's where we come in; we're computer  
>>> professionals.
>>> We cause accidents."        -- Nathaniel Borenstein, co-creator of  
>>> MIME
>>>
>>
>
> ======================== Summary of Commits =========================
>
> pom.xml
>    Tried to fix jar signing. Still needs lots of work. See comments  
> therein.
>
> documentation/ESAPI_2.0_ReleaseNotes_CryptoChanges.html
>    New file -- Explains why we are making changes to the Encryptor  
> encrypt /
> decrypt methods in ESAPI Java 2.0 and gives some examples of use.
>
> src/main/resources/owasp-esapi-dev.jks
>    New; a Java keystore file with a self-signed cert to be used for  
> jar signing
> the ESAPI 2.0 jar.
>
> src/main/resources/.esapi/ESAPI.properties
>    Summarized crypto changes, added new properties to support new  
> Encryptor
> encrypt / decrypt methods, briefly explained backward compatibility  
> for Encryptor.
>
> src/main/java/**
>    org.owasp.esapi
>        CipherText - Untested! Made Serializable, added several new  
> methods,
> flushed out Javadoc
>        Encryptor - Flushed out Javadoc. Added 2 new methods (encrypt 
> () and
> decrypt() that take a SecretKey).
>        ESAPI - Added some comments for discussion (marked 'DISCUSS').
>        PreparedString - Fixed Javadoc so it wouldn't prematurely die.
>        Randomizer - `Added new method, getRandomBytes(int n).
>        SecurityConfiguration - Fixed misc Javadoc, added several new  
> mthods to
> support new Encryptor encrypt / decrypt methods.
>
>    org.owasp.esapi.codecs
>        Hex - New class to do hexadecimal encoding / decoding.
>
>    org.owasp.esapi.reference
>        DefaultCipherText - Untested! Completed implementation and  
> Javadoc.
>        DefaultRandomizer - Untested! Implemented new gentRandomBytes 
> (int) method.
>        DefaultSecurityConfiguration - Untested! - Implemented new  
> methods to
> support new Encryptor encrypt / decrypt methods, Javadoc corrections.
>        JavaEncryptor - Untested! Lots of Javadoc changes.  
> Implemented 2 new
> encrypt() and 2 new decrypt() methods.
>
>    org.owasp.esapi.util
>        CipherSpec - Untested! New class. A Serializable class that  
> carries all
> info about a specific cipher specification that was used to encrypt  
> some
> particular ciphertext (other than the SecretKey of course). Main  
> intent is to be
> used with CipherText, but may be used alone.
>        CryptoHelper - Untested! New class. Some static methods to  
> simplify
> encryption and decryption of plaintext Strings, to be used as a  
> replacement for
> the deprecated Encryptor encrypt() and decrypt() methods if ESAPI  
> users find the
> newer methods too inconvenient to use.
>        ObjFactor - Mostly tested (except for one or 2 'catch'  
> clauses). Fixed
> some Javadoc. Made CTOR public (probably is a way to just do this  
> using a static
> method, but it wasn't obvious and I didn't want to screw with it).  
> Improved some
> internal documentation. Added OWASP copyright notice.
>        StringUtils - Added new notNullOrEmpty() method used in  
> assertions.
> (untested).
>
>
> -- 
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts  
> agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of  
> MIME


More information about the OWASP-ESAPI mailing list