Joe Witt created NIFI-16371:
-------------------------------
Summary: Flaky test
PasswordBasedPropertyEncryptionProviderTest.testDecryptAuthenticationFailed
Key: NIFI-16371
URL: https://issues.apache.org/jira/browse/NIFI-16371
Project: Apache NiFi
Issue Type: Test
Reporter: Joe Witt
Assignee: Joe Witt
PasswordBasedPropertyEncryptionProviderTest.testDecryptAuthenticationFailed
fails
intermittently in CI, roughly 1 run in 256, on any OS and JDK combination.
Recent example on the MacOS Zulu JDK 21 JP job:
org.opentest4j.AssertionFailedError: Expected
org.apache.nifi.security.encryption.PropertyEncryptionException to be thrown,
but nothing was thrown.
at
PasswordBasedPropertyEncryptionProviderTest.testDecryptAuthenticationFailed(
PasswordBasedPropertyEncryptionProviderTest.java:128)
The test encrypts a value and then corrupts it by assignment before asserting
that
decryption fails authentication:
final byte[] encrypted = provider.encrypt(PROPERTY_BINARY, CONTEXT);
encrypted[0] = 0;
assertThrows(PropertyEncryptionException.class, () ->
provider.decrypt(encrypted, CONTEXT));
PasswordBasedPropertyEncryptionProvider returns a random AES-GCM initialization
vector followed by cipher text, so encrypted[0] is the first byte of a freshly
generated random IV. When that byte is already zero, the assignment is a no-op,
the
value is unmodified, decryption succeeds, and no exception is thrown. With a
uniformly
random IV byte this occurs on approximately 1 of every 256 executions.
The failure is unrelated to operating system, locale, or JDK. The Japanese
locale job
simply happened to draw a zero first byte.
The test should corrupt the value in a way that is guaranteed to change it, for
example
flipping a bit rather than assigning a fixed value:
encrypted[0] ^= 1;
Applying the same change to any other test that corrupts a random IV or salt by
assignment would prevent the same class of flake.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
