Activity

1. kwwall commented on Jan 6, 2016

   

   kwwall

   on Jan 6, 2016

   Contributor

   More actions

   @xeno6696 I'm not 100% sure, but I think if this was a failed test, the exception stack trace that you showed wasn't from the failed test.

   First, if you look closely, you'll see this:

       ...
       at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
   
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec
   
   Results :
   
   Failed tests:   testLoadEncryptedAndAdd(org.owasp.esapi.reference.crypto.EncryptedPropertiesUtilsTest): null expected:<jim bob> but was:<null>
   
   Tests run: 595, Failures: 1, Errors: 0, Skipped: 0
   

   That would seem to indicate that the failed test was in EncryptedPropertiesUtilstest.testLoadEncryptedAndAdd() rather than somewhere in EnterpriseSecurityExceptionTest. I think probably that exception stack trace that you are seeing is a legitimate (i.e., expected) stack trace that comes out as part of the logging that happens as a side effect when it is EnterpriseSecurityExceptions (and subsclasses) is thrown.

   In fact, I think what you are looking at is the log message, which likely is going to stdout or stderr (both, which by default go to your "console" / terminal) since it is using JavaLogFactory for the logger. According to that stack trace, the cause is this line (line 152) in EnterpriseSecurityExceptionTest.java:

           ex = new IntrusionException("m1","m2", new Throwable());
   

   In fact, that agrees 100% of what we would expect and corresponds exactly to:

   SEVERE: [SECURITY FAILURE Anonymous:null@unknown -> 10.1.43.6:80/ExampleApplication/IntrusionException] INTRUSION - m2
   

   followed by the exception (with empty message) and stack trace.

   So I think that is what is expected here.

   As for why the EncryptedPropertiesUtilstest.testLoadEncryptedAndAdd() test case failed, I have no explanation without some additional details like log messages or whatever. And since we are unable reproduce it, I think that we should close this issue (especially sit it is pointing fingers at the wrong test). If someone is able to reproduce it reliably, or provide a stack trace for the actual failed test, then we can either reopen it or (my preference) create a new issue that correctly describes the
   failed test case as well as how to reproduce it, etc.

   So, anyone against closing this issue?
   -kevin
2. xeno6696 commented on Jan 6, 2016

   

   xeno6696

   on Jan 6, 2016

   CollaboratorAuthor

   More actions

   Jeremiah discovered while investigating this that it was caused by some kind of internal dependency on the order of test method execution. (Or something like that.) Basically the tests write to a file and if the methods execute in a different order then how they were written--something possible in JUnit--you would get this oddball error. His concurrent test runner was able to identify this issue and it'll be resolved in his batch of patches.

   If he ever gets a github account... ;-)
3. kwwall

   assigned

   jeremiahjstacey

   on Jan 20, 2016
4. kwwall commented on Jan 20, 2016

   

   kwwall

   on Jan 20, 2016

   Contributor

   More actions

   @jeremiahjstacey If you don't want to fix this, NBD, but I thought since you were already working on it, it made sense. Let me know if you want me to re-assign it.
5. jeremiahjstacey commented on Jan 20, 2016

   

   jeremiahjstacey

   on Jan 20, 2016

   Collaborator

   More actions

   The stack trace Matt posted originally has a bit of a red herring. I believe that the maven build was running multi-threaded (2 cores?). The actual test failure was in EncryptedPropertyUtilsTest.testLoadEncryptedAndAdd, but that failure terminated the other thread's execution which was in the EnterpriseSecurityExceptionTest which resulted in the stacktrace.

   The EnterpriseSecurityExceptionTest implementation is fine.

   This issue is a multi-threading issue in the EncryptedPropertyUtilsTest which relies on test ordering. The specific issue are lines 171 and 172 of testLoadEncryptedAndAdd(), which cannot be true unless the tests in this class are guaranteed to run sequentially every time. That state expectation is a carry-over from the testLoadPlaintextAndEncrypt method which places K/V-3 and K/V-4 into the ENCRYPTED_FILENAME_1 instance.

   Delete lines 171 and 172 of EncryptedPropertyUtilsTest and this specific issue is resolved.

   171|    assertEquals(VALUE3, props.getProperty(KEY3));
   172|    assertEquals(VALUE4, props.getProperty(KEY4));

   I would recommend removing the shared file references in favor of the TemporaryFolder junit rule which can provide clean file status between tests and manage the creation/cleanup for us. This requires Junit to be upgraded to at least 4.7.

   I will work on getting a correctly-configured environment to begin active project participation, but the fix for this is small enough that I don't believe it's necessary to wait for my spin-up time.
6. xeno6696

   added 3 commits that reference this issue on Apr 20, 2016

   https://github.com/ESAPI/esapi-java-legacy/issues/352

   5951f43

   https://github.com/ESAPI/esapi-java-legacy/issues/352

   ea84364

   https://github.com/ESAPI/esapi-java-legacy/issues/352

   a6819c5
7. xeno6696 commented on May 20, 2016

   

   xeno6696

   on May 20, 2016

   CollaboratorAuthor

   More actions

   Don't know why this issue didn't close... but its fixed.
8. xeno6696

   closed this as completedon May 20, 2016
9. xeno6696

   added a commit that references this issue on May 21, 2016

   Issue #352 -- Deprecated existing HTTPUtilities.setRememberToken() fo…

   79f6bc6