Whitespace check-in (#720)

@xeno6696 - Since @noloader touched all these files last, he owns them and is forever stuck doing bug fixes on them, right?
Seriously, thanks Jeff. This is one of those bookkeeping matters that I generally don't require a GitHub issue for, but feel free to create one, assign it to yourself, and reference this PR if you would like. Up to you.

Author: noloader

README.md

@@ -184,7 +184,7 @@ ONLY use GitHub Issues for reporting bugs.
 # References: Where to Find More Information on ESAPI
 **OWASP Uncyclo:** https://owasp.org/www-project-enterprise-security-api/
 
-**GitHub ESAPI Uncyclo:** https://github.com/ESAPI/esapi-java-legacy/wiki 
+**GitHub ESAPI Uncyclo:** https://github.com/ESAPI/esapi-java-legacy/wiki
 
 **General Documentation:** Under the '[documentation](https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation)' folder.
 

documentation/ESAPI-configuration-user-guide.md

@@ -41,15 +41,15 @@ until these deprecated methods are removed, but it will be a minumum of 2 years
 or 1 major release [e.g., 3.x], whichever comes first. Also, we may not
 necessarily remove all of them at once, depending on community feedback.)
 
-DefaultSecurityConfiguration implements the new contract. New contract methods implementations work as described in 
+DefaultSecurityConfiguration implements the new contract. New contract methods implementations work as described in
 'Multiple configuration files support' paragraph.
 
 ## Multiple configuration files support
 
 EsapiPropertyManager is the new implementation for getting properties, which uses prioritized property loaders (each one associated with a specific configuration file). This allows to have multiple configuration files existing with priority connected to each one. At this moment, there
 are two configuration files possible to use, the path to them is set through following Java
 system properties:
- 
+
 * org.owasp.esapi.opsteam = <full_path_to_file> (higher priority config)
 * org.owasp.esapi.devteam = <full_path_to_file> (lower priority config)
 
@@ -86,9 +86,9 @@ ESAPI.securityConfiguration().getBooleanProp("propertyXXX");
 where "propertyXXX" is some property name relevant to ESAPI (and
 in this case, one that would hold a boolean value). See ESAPI.properties
 for a list of current property names known to ESAPI.
- 
+
 In above example, following happens:
-  
+
 1. org.owasp.esapi.opsteam configuration is used to get propertyXXX and return it as boolean.
 2. If (1) fails to find property, org.owasp.esapi.devteam is used to get propertyXXX and return it as boolean.
 3. If (2) fails to find property, ESAPI.properties is used to get propertyXXX and return it as boolean.

documentation/esapi4java-2.0-readme.txt

@@ -7,7 +7,7 @@ Here are the most significant directories and files included the zip file for th
 
 File / Directory                                                        Description
 =========================================================================================
-<root>/	
+<root>/
 |
 +---configuration/                                                      Directory of ESAPI configuration files
 |     |

documentation/esapi4java-2.0rc6-override-log4jloggingfactory.txt

@@ -1,4 +1,4 @@
-This release includes critical changes to the ESAPI Log4JLogger that will now allow you to over-ride the user specific 
+This release includes critical changes to the ESAPI Log4JLogger that will now allow you to over-ride the user specific
 message using your own User or java.security.Principal implementation.
 
 There are a three critical steps that need to be taken to over-ride the ESAPI Log4JLogger:
@@ -23,8 +23,8 @@ ESAPI.Logger=com.yourcompany.logging.ExtendedLog4JFactory
 
 And you should be all set!
 
-PS: The original ESAPI Log4JLogging class used a secure random number as a replacement to logging the session ID. This allowed 
-us to tie log messages from the same session together, without exposing the actual session id in the log file. The code looks 
+PS: The original ESAPI Log4JLogging class used a secure random number as a replacement to logging the session ID. This allowed
+us to tie log messages from the same session together, without exposing the actual session id in the log file. The code looks
 like this, and you may wish to use it in your over-ridden version of getUserInfo.
 
 HttpServletRequest request = ESAPI.httpUtilities().getCurrentRequest();
@@ -40,7 +40,7 @@ if ( request != null ) {
     }
 }
 
-In fact, here is the entire original getUserInfo() implementation (that was tied to the ESAPI request and user object) – 
+In fact, here is the entire original getUserInfo() implementation (that was tied to the ESAPI request and user object) –
 you may wish to emulate some of this.
 
 public String getUserInfo() {
@@ -58,14 +58,14 @@ public String getUserInfo() {
             }
         }
     }
-    
+
     // log user information - username:session@ipaddr
-    User user = ESAPI.authenticator().getCurrentUser();            
+    User user = ESAPI.authenticator().getCurrentUser();
     String userInfo = "";
     //TODO - make type logging configurable
     if ( user != null) {
         userInfo += user.getAccountName()+ ":" + sid + "@"+ user.getLastHostAddress();
     }
-    
+
     return userInfo;
 }

documentation/esapi4java-core-2.0-readme-crypto-changes.html

@@ -63,7 +63,7 @@ <H3>Symmetric Encryption in ESAPI 2.0rc1 and 2.0rc2</H3>
 always encrypt to the same ciphertext block, thus revealing patterns
 in the plaintext input. For example, these images from Uncyclopedia's
 <A HREF="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation">Block
-cipher modes of operation</A> illustrate this point well: 
+cipher modes of operation</A> illustrate this point well:
 </P>
 <TABLE BORDER=0 CELLPADDING=4 CELLSPACING=0>
 	<TR>
@@ -92,7 +92,7 @@ <H3>Symmetric Encryption in ESAPI 2.0rc1 and 2.0rc2</H3>
 <P>Ciphertext encrypted with ECB cipher mode are also subject to
 &quot;block replay attacks&quot;. See Bruce Schneier's <A HREF="http://www.google.com/url?sa=t&amp;source=web&amp;ct=res&amp;cd=2&amp;url=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DA6ZO2D6ayNwC%26pg%3DPT216%26lpg%3DPT216%26dq%3Decb%2B%2522block%2Breplay%2522%26source%3Dbl%26ots%3DiEbAWQpu0e%26sig%3D8xiUva4XKaAOfPJEPsULPAJPk88%26hl%3Den%26ei%3Da6yISoLQPJOuMI-Z_OkE%26sa%3DX%26oi%3Dbook_result%26ct%3Dresult%26resnum%3D2&amp;ei=a6yISoLQPJOuMI-Z_OkE&amp;rct=j&amp;q=ecb+%22block+replay%22&amp;usg=AFQjCNF-IjrE4dL7M2LELh48hYPP6A_bpQ"><I>Applied
 Cryptography: protocols, algorithms, and source code</I> </A>for
-details. 
+details.
 </P>
 <P>In both ESAPI 2.0-rc1 and 2.0-rc2, one can choose other block
 ciphers (e.g. Blowfish) or other key sizes (e.g., 512-bit AES), but
@@ -123,7 +123,7 @@ <H3>Problems with Symmetric Encryption in ESAPI 2.0-rc1 and 2.0-rc2</H3>
 </OL>
 <H2>The Encryption Changes in ESAPI 2.0-rc3 and Later</H2>
 <P>Briefly speaking, the changes being implemented for ESAPI Java 2.0
-are: 
+are:
 </P>
 <OL>
 	<LI><P STYLE="margin-bottom: 0in">Starting in ESAPI Java 2.0-rc3,
@@ -156,7 +156,7 @@ <H2>The Encryption Changes in ESAPI 2.0-rc3 and Later</H2>
 	response was deafening. There literally was but a single response
 	and that was to kill off <CODE>LegacyJavaEncryptor</CODE><CODE><FONT FACE="Thorndale AMT, serif">.</FONT></CODE>
 	(By this time, the two symmetric encryption interfaces in <CODE>Encryptor</CODE>
-	had already been deprecated.) 
+	had already been deprecated.)
 	</P>
 	<LI><P>The byte-encoding has been changed from native byte encoding
 	to UTF-8 byte-encoding throughout ESAPI 2.0 and not just for
@@ -167,7 +167,7 @@ <H2>The Encryption Changes in ESAPI 2.0-rc3 and Later</H2>
 	guaranteed.</P>
 </OL>
 <H2>The Good, the Bad, and the Ugly</H2>
-<P>Or put another way, there are always trade-offs to be made... 
+<P>Or put another way, there are always trade-offs to be made...
 </P>
 <H3>The Good</H3>
 <P>We get improved security by encouraging the use of stronger cipher
@@ -205,9 +205,9 @@ <H3>The Bad</H3>
 both to encrypt and decrypt. While it is not required that the IV be
 kept secret from adversaries, there are some attacks that are
 possible if the adversary is permitted to alter the IV at will and
-observe the results of the ensuing decryption attempt. 
+observe the results of the ensuing decryption attempt.
 </P>
-<P>So that leaves two choices for the IV: 
+<P>So that leaves two choices for the IV:
 </P>
 <UL>
 	<LI><P STYLE="margin-bottom: 0in">Using a <I><B>fixed IV</B></I>:
@@ -223,7 +223,7 @@ <H3>The Bad</H3>
 	persisted (e.g., to a database) or transmitted to the recipient this
 	random IV must be stored / made known. Therefore, the raw ciphertext
 	can no longer suffice; whatever random IV that was chosen must be
-	communicated. 
+	communicated.
 	</P>
 </UL>
 <P>Likewise, the use of padding is going to add some overhead to the
@@ -360,7 +360,7 @@ <H3>The Bad</H3>
 cipher block size is 128-bits, but more typically, a cipher's block
 size is 64-bits so the padding would be between 1 to 16 bytes for AES
 and 1 to 8 bytes for a 64-bit block size cipher and the IV would be
-IV would be 16 bytes for AES and 8 bytes for most other ciphers. 
+IV would be 16 bytes for AES and 8 bytes for most other ciphers.
 </P>
 <H3>The Ugly</H3>
 <P>Well, so far, this &quot;bad&quot; news may be bad for you but
@@ -370,7 +370,7 @@ <H3>The Ugly</H3>
 <P>But wait Skippy, don't go running off just quite yet. As Robert
 Heinlein wrote in his 1966 novel <I>The Moon is a Harsh Mistress</I>
 &quot;There ain't no such thing as a free lunch&quot;. (Some of us
-more hardened cynics know it more commonly as <I>TANSTAAFL</I>.) 
+more hardened cynics know it more commonly as <I>TANSTAAFL</I>.)
 </P>
 <P>As mentioned earlier, backward compatibility with ESAPI 1.4
 (originally planned via <CODE>LegacyJavaEncryptor</CODE>) has been
@@ -395,11 +395,11 @@ <H3>The Ugly</H3>
 complexity of handling the ciphertext result from encryption
 operations. And then there are new encryption and decryption methods
 for the <CODE>Encryptor</CODE> interface. Specifically, the encrypt
-and decrypt methods have been generalized as: 
+and decrypt methods have been generalized as:
 </P>
 <PRE STYLE="margin-left: 0.49in"><FONT COLOR="#000000"><FONT FACE="Monospace">CipherText encrypt(SecretKey key, PlainText plaintext)</FONT></FONT>
 <FONT COLOR="#000000">        <FONT FACE="Monospace">throws EncryptionException;</FONT></FONT></PRE><P STYLE="margin-bottom: 0in">
-and 
+and
 </P>
 <PRE STYLE="margin-left: 0.49in"><FONT COLOR="#000000"><FONT FACE="Monospace">PlainText decrypt(SecretKey key, CipherText ciphertext)</FONT></FONT>
 <FONT COLOR="#000000">        <FONT FACE="Monospace">throws EncryptionException</FONT></FONT></PRE><P>
@@ -409,7 +409,7 @@ <H3>The Ugly</H3>
 based on <FONT FACE="DejaVu Sans Mono, sans-serif">Encryptor.MasterKey</FONT>.)</P>
 <P>The two existing interfaces from ESAPI 1.4 and earlier:</P>
 <PRE STYLE="margin-left: 0.49in; margin-bottom: 0.2in">String encrypt(String plaintext) throws EncryptionException</PRE><P STYLE="margin-bottom: 0in">
-and 
+and
 </P>
 <PRE STYLE="margin-left: 0.49in; margin-bottom: 0.2in">String decrypt(String ciphertext) throws EncryptionException</PRE><P>
 are still supported but have been <I>deprecated</I>, mainly because

documentation/esapi4java-core-2.0-symmetric-crypto-user-guide.html

@@ -353,7 +353,7 @@ <H2>ESAPI.properties Properties Relevant to Symmetric Encryption</H2>
 <H2>How the Old (Deprecated) Methods Were Used</H2>
 <P>To encrypt / decrypt using the String-based, deprecated methods
 carried over from ESAPI 1.4, code similar to the following would be
-used. 
+used.
 </P>
 <PRE>    String myplaintext = &quot;My plaintext&quot;;
     try {
@@ -411,10 +411,10 @@ <H2>Encrypting / Decrypting with the New Methods -- The Simple Usage</H2>
 <P>Using the new encryption / decryption methods is somewhat more
 complicated, but this is in part because they are more flexible and
 that flexibility means that more information needs to be communicated
-as to the details of the encryption. 
+as to the details of the encryption.
 </P>
 <P>A code snippet using the new methods that use the master
-encryption key would look something like this: 
+encryption key would look something like this:
 </P>
 <PRE>    String myplaintext = &quot;My plaintext&quot;;
     try {
@@ -432,7 +432,7 @@ <H2>Encrypting / Decrypting with the New Methods -- The Simple Usage</H2>
 mode is chosen.</P>
 <P>Also, these new methods allow a general byte array to be
 encrypted, not just a Java String. If one needed to encrypt a byte
-array with the old deprecated method, one would first have to use 
+array with the old deprecated method, one would first have to use
 </P>
 <PRE>    byte[] plaintextByteArray = { /* byte array to be encrypted */ };
     String plaintext = new String(plaintextByteArray, &quot;UTF-8&quot;);</PRE><P>
@@ -541,7 +541,7 @@ <H3>Encrypting / Decrypting with the New Methods</H3>
 encrypted bank account numbers are to be sent to one recipient and
 the encrypted credit card numbers are to be sent to a different
 recipient. Obviously in such cases, you do not want to share the same
-key for both recipients. 
+key for both recipients.
 </P>
 <P>In ESAPI 1.4 there was not much you can do, but in ESAPI 2.0 and
 later, there are new encryption / decryption methods that allow you
@@ -553,14 +553,14 @@ <H3>Encrypting / Decrypting with the New Methods</H3>
 distributed to the recipients out-of-band. On you could distribute
 them dynamically via asymmetric encryption assuming that you've
 previously exchanged public keys with the recipients.)</P>
-<P>The following illustrates how these new methods might be used. 
+<P>The following illustrates how these new methods might be used.
 </P>
 <P>First, we would generate some appropriate secret keys and
 distribute them securely (e.g., perhaps over SSL/TLS) or exchange
 them earlier out-of-band to the intended recipients. (E.g., one could
 put them on two separate thumb drives and use a trusted courier to
 distribute them to the recipients or one could use PGP-mail or S/MIME
-to securely email them, etc.) 
+to securely email them, etc.)
 </P>
 <PRE>    // Generate two random, 128-bit AES keys to be distributed out-of-band.
     import javax.crypto.SecretKey;
@@ -587,10 +587,10 @@ <H3>Encrypting / Decrypting with the New Methods</H3>
 Second, these keys would be printed out and stored somewhere secure
 by our application, perhaps using something like ESAPI's
 <CODE>EncryptedProperties</CODE> class, where they could later be
-retrieved and used. 
+retrieved and used.
 </P>
 <P>In the following code, we assume that the <CODE>SecretKey</CODE>
-values have already been initialized elsewhere. 
+values have already been initialized elsewhere.
 </P>
 <PRE>    SecretKey bankAcctKey = ...;        // These might be read from EncryptedProperties
     SecretKey credCardKey = ...;        // or from a restricted database, etc.

documentation/esapi4java-core-2.1-release-notes.txt

@@ -8,7 +8,7 @@ ESAPI for Java - 2.1.0 Release Notes
    deprecated more than 2 years ago and they are known to be insecure
    (they are vulnerable to padding oracle attacks), the ESAPI team has
    decided to remove them in accordance to their support policy.
-   
+
    See comments for issue #306 for further details, as well as additional
    safety precautions that you may wish to take in the unlikely, but possible
    event that this vulnerability resulted in an actual security breach.
@@ -64,5 +64,5 @@ NOTE: A follow-up patch release is scheduled within the next few months to
       based on findings in Google Issue # 306. I will periodically try
       to keep the ESAPI mailing lists updated with the progress so watch
       there for emerging details and anticipated schedule.
-      
+
 -Kevin W. Wall <[email protected]>, 2013-08-30

documentation/esapi4java-core-2.2.0.0-release-notes.txt

@@ -46,7 +46,7 @@ Issue #			GitHub Issue Title
 37		RandomAccessReferenceMap.update() can randomly corrupt the map
 71		java.lang.ExceptionInInitializerError in 2.0 version
 129		Add Logging support for SLF4J
-157		minimum-config deployment fails 
+157		minimum-config deployment fails
 188		SecurityWrapperRequest seems to mishandle/swallow allowNull argument
 209		Build an encoding function specific to HTTP/Response Splitting (tactical remediation)
 213		Provide a taglib descriptor (.tld file)
@@ -116,7 +116,7 @@ Issue #			GitHub Issue Title
 386		Avoid using System.err in EsapiPropertyManager
 387		'mvn site' fails for FindBugs report, causing 'site' goal to fail
 389		Provide an option for the encodeForLDAP method to not encode wildcard characters
-394		Refactor Validator.getCanonicalizedUri into Encoder.  
+394		Refactor Validator.getCanonicalizedUri into Encoder.
 395		Issues when I am passing htttp://localhost:8080/user=admin&prodversion=no
 396		Trust Boundary Violation - while triggering veracode
 397		Update Resource path search to maintain legacy behavior in DefaultSecurityConfiguration.java
@@ -128,7 +128,7 @@ Issue #			GitHub Issue Title
 417		Add additional protection against CVE-2016-1000031
 422		Inconsistent dependency structure and vulnerable xml (xerces, xalan, xml-apis ...) dependencies
 424		issue with Filename encoding for executeSystemCommand
-425		Project build error: Non-resolvable parent POM for org.owasp.esapi:esapi:2.1.0.2-SNAPSHOT: Could not transfer artifact 
+425		Project build error: Non-resolvable parent POM for org.owasp.esapi:esapi:2.1.0.2-SNAPSHOT: Could not transfer artifact
 427		HTTP cookie validation rules too restrictive?
 429		Miscellaneous updates to pom.xml
 432		ESAPI.properties not found.
@@ -140,7 +140,7 @@ Issue #			GitHub Issue Title
 442		Remove deprecated fields in Encoder interface
 444		Delete deprecated method Base64.decodeToObject() and related methods
 445		A bunch of dependencies are out of date , I will list them below with the associated vulnerability
-447		can't generate MasterKey / MasterSalt 
+447		can't generate MasterKey / MasterSalt
 448		Clean up pom.xml
 454		about code eclipse formatter template question
 455		New release for mitigation of CVEs
@@ -194,7 +194,7 @@ Issue #			GitHub Issue Title
 
     Issue 483     More miscellaneous prep work for ESAPI 2.2.0.0 release
         Specifically, CipherText.getSerialVersionUID() and DefaultSecurityConfiguration.MAX_FILE_NAME_LENGTH have actually been deleted from the ESAPI code base. For the former, use CipherText.cipherTextVersion() instead. For the latter, there is no replacement. (This wasn't being used, but it was set to 1000 in case you're wondering.)
-        
+
 * Various properties in ESAPI.properties were changed in a way that might affect your application:
     Issue 439		Tighten ESAPI defaults to disallow dubious file suffixes
 
@@ -220,10 +220,10 @@ Issue #			GitHub Issue Title
                                                     Validator.HTTPQueryString=^([a-zA-Z0-9_\\-]{1,32}=[\\p{L}\\p{N}.\\-/+=_ !$*?@%]*&?)*$
                                                 (Left as an exercise for the reader to figure out what exactly this means. ;-)
             Validator.HTTPURI:              Changed to be much more restrictive; i.e., changed from:
-                                                    Validator.HTTPURI=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$ 
+                                                    Validator.HTTPURI=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$
                                                 to:
                                                     Validator.HTTPURI=^/([a-zA-Z0-9.\\-_]*/?)*$
-            
+
 * Other changes:
     Issue 500		Suppress noise from ESAPI searching for properties and stop ignoring important IOExceptions
 
@@ -241,7 +241,7 @@ Issue #			GitHub Issue Title
 
         Other changes in this release, some of which not tracked via GitHub issues
 
-* Updated minimal version of Maven from 3.0 to 3.1 required to build ESAPI. 
+* Updated minimal version of Maven from 3.0 to 3.1 required to build ESAPI.
 * Miscellaneous minor javadoc fixes and updates.
 * Added the Maven plug-in for OWASP Dependency Check so 3rd party dependencies can be kept up-to-date.
 * Updated .gitignore file with additional files to be ignored.