FileRealmTests#testAuthenticateCaching fails with an assertion error.

[jtibshirani]

The failure reliably reproduces for me locally, and may be related to the recent change to password hashing: #31234.

---

Link to the build: https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+g1gc/6006/console

Command to reproduce:

./gradlew :x-pack:plugin:security:test \
  -Dtests.seed=B944BC5A5B893131 \
  -Dtests.class=org.elasticsearch.xpack.security.authc.file.FileRealmTests \
  -Dtests.method="testAuthenticateCaching" \
  -Dtests.security.manager=true \
  -Dtests.jvm.argline="-XX:-UseConcMarkSweepGC -XX:+UseG1GC" \
  -Dtests.locale=fr-BE \
  -Dtests.timezone=Antarctica/Troll

Relevant excerpt from the logs:

FAILURE 3.40s | FileRealmTests.testAuthenticateCaching <<< FAILURES!
   > Throwable #1: java.lang.AssertionError: 
   > Expected: sameInstance(<User[username=user1,roles=[role1,role2],fullName=null,email=null,metadata={}]>)
   >      but: was <User[username=user1,roles=[role1,role2],fullName=null,email=null,metadata={}]>
   >    at __randomizedtesting.SeedInfo.seed([B944BC5A5B893131:52FC433DA47C405A]:0)
   >    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
   >    at org.elasticsearch.xpack.security.authc.file.FileRealmTests.testAuthenticateCaching(FileRealmTests.java:103)
   >    at java.lang.Thread.run(Thread.java:748)

[elasticmachine]

Pinging @elastic/es-security

[jkakavas]

This reproduces with ./gradlew but not when I run the test in Intellij ( I get the same instance of the User object ). Not sure if sameInstance makes sense here, but that indeed doesn't explain why this fails now as it was passing forever.

[bizybot]

Hi @jkakavas its happening because of NOOP hasher, looks like when we are verifying hash and trying to find the hasher to verify it can't find it from the hash as its plaintext. Hope this helps. I had this test fail in my environment so was looking at it.

[jkakavas]

Thanks @bizybot you're right. We probably need to log that warning too for easier troubleshooting. This is also an actual bug in the implementation as the NOOP hasher can't be used as is. I will address this