DateProcessorTests#testJodaPatternLocale fails on a FIPS 140 JVM

[jkakavas]

DateProcessorTests#testJodaPatternLocale() consistently and reproducibly fails when run in a FIPS 140 JVM ( openjdk-8 with BCFIPS 1.0.1 as the FIPS 140 approved Security Provider) , passes otherwise

> Task :modules:ingest-common:test
   [junit4] <JUnit4> says jolly good day! Master seed: F1E8C351AD84D5FD
==> Test Info: seed=F1E8C351AD84D5FD; jvm=1; suite=1

  1> [2018-07-02T19:14:53,684][INFO ][o.e.i.c.DateProcessorTests] [testJodaPatternLocale]: before test
  1> [2018-07-02T19:14:53,879][INFO ][o.e.i.c.DateProcessorTests] [testJodaPatternLocale]: after test
  2> REPRODUCE WITH: ./gradlew :modules:ingest-common:test -Dtests.seed=F1E8C351AD84D5FD -Dtests.class=org.elasticsearch.ingest.common.DateProcessorTests -Dtests.method="testJodaPatternLocale" -Dtests.security.manager=true -Dtests.jvm.argline="-Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStorePassword=password" -Dtests.locale=sq -Dtests.timezone=Asia/Jayapura
ERROR   0.30s | DateProcessorTests.testJodaPatternLocale <<< FAILURES!
   > Throwable #1: java.lang.IllegalArgumentException: unable to parse date [2010 12 giugno]
   >    at __randomizedtesting.SeedInfo.seed([F1E8C351AD84D5FD:CFBDD6615AE7FA5F]:0)
   >    at org.elasticsearch.ingest.common.DateProcessor.execute(DateProcessor.java:97)
   >    at org.elasticsearch.ingest.common.DateProcessorTests.testJodaPatternLocale(DateProcessorTests.java:120)
   >    at java.lang.Thread.run(Thread.java:748)
   > Caused by: java.lang.IllegalArgumentException: Invalid format: "2010 12 giugno" is malformed at "giugno"
   >    at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:945)
   >    at org.elasticsearch.ingest.common.DateFormat$5.lambda$getFunction$0(DateFormat.java:70)
   >    at org.elasticsearch.ingest.common.DateProcessor.execute(DateProcessor.java:89)
   >    ... 38 more
  2> NOTE: leaving temporary files on disk at: /home/ioannis/code/devel/elasticsearch/modules/ingest-common/build/testrun/test/J0/temp/org.elasticsearch.ingest.common.DateProcessorTests_F1E8C351AD84D5FD-001
  2> NOTE: test params are: codec=Asserting(Lucene70): {}, docValues:{}, maxPointsInLeafNode=458, maxMBSortInHeap=7.324707524534739, sim=RandomSimilarity(queryNorm=true): {}, locale=sq, timezone=Asia/Jayapura
  2> NOTE: Linux 4.15.0-23-generic amd64/Oracle Corporation 1.8.0_171 (64-bit)/cpus=16,threads=1,free=450404656,total=514850816
  2> NOTE: All tests run in this JVM: [DateProcessorTests]
Completed [1/1] in 2.04s, 1 test, 1 error <<< FAILURES!

[elasticmachine]

Pinging @elastic/es-core-infra

[cbuescher]

Failed here again: https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_BUILD_JAVA=openjdk12,ES_RUNTIME_JAVA=java8fips,nodes=immutable&&linux&&docker/218/console

[cbuescher]

This seems to run (and fail) more often these days. Found at least four occasions just today:

https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_BUILD_JAVA=openjdk12,ES_RUNTIME_JAVA=java8fips,nodes=immutable&&linux&&docker/217/console
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_BUILD_JAVA=java11,ES_RUNTIME_JAVA=java8fips,nodes=immutable&&linux&&docker/217/console
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_BUILD_JAVA=java11,ES_RUNTIME_JAVA=java8fips,nodes=immutable&&linux&&docker/218/console

And the above. I'm not sure if we can mute based on a JDK version but will at least open a PR in case we want to do that.

[droberts195]

Sorry I removed the original muting prematurely.

But one interesting thing it's shown is that now this test has failed with Java time parsing the idea that it was caused by a bug in Joda as suggested by https://github.com/elastic/elasticsearch/pull/31666/files#diff-bddb6e873fcfacb8409882fd9eeb67b2R117 can be discounted. It really does seem to be caused by something to do with FIPS that affects both time parsing libraries.

[jkakavas]

Yes, I think you are right @droberts195. This looks like an issue with the Date parsing in the FIPS 140 provider we use in the tests from Bouncy Castle and looks awfully similar to #33081 which is tracked upstream in bcgit/bc-java#405

[droberts195]

I imagine it's only US government organisations that run in FIPS mode, so in practice as long as date parsing in FIPS mode works for the US English locale everyone will probably be happy. But if that ends up being the solution then it might be worth adding a similar test that's hardcoded to US English that's not muted in FIPS mode.