[
https://issues.apache.org/jira/browse/IMPALA-13705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930218#comment-17930218
]
ASF subversion and git services commented on IMPALA-13705:
----------------------------------------------------------
Commit 6786281541506ab26af434c0c901dff5ad4d1b21 in impala's branch
refs/heads/branch-4.5.0 from Daniel Becker
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=678628154 ]
IMPALA-13705: Environment specific errors in test_encryption_exprs
IMPALA-13039 added support for the aes_encrypt() and aes_decrypt()
functions, where the user can choose the AES operation mode. Currently
if the user chooses a mode that is not supported by the OpenSSL library
at runtime, we fall back to a supported mode. There are two issues
related to this:
1. If the mode chosen by the user requires a 16 byte encryption key but
the fallback mode needs a 32 byte one, we will read past the provided
buffer.
2. If the tests are run in an environment where some modes are not
supported, we will get incorrect results. This can for example be the
case with GCM.
The first problem is solved by disabling falling back to a supported
mode in case of aes_encrypt() and aes_decrypt(). If the mode is not
supported, an error is returned instead. Note that this does not affect
the case when the user explicitly specifies NULL as the operation mode -
a default encoding will still be chosen in that case.
The second problem is solved by dividing the test queries into separate
".test" files based on operation mode (and one for queries that are
expected to fail). Each operation mode that is not always supported is
tested first with a probing query and the corresponding tests are only
run if the probing query succeeds, i.e. the mode is supported.
Change-Id: I27146cda4fa41965de35821315738e5502d1b018
Reviewed-on: http://gerrit.cloudera.org:8080/22419
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Environment specific errors in test_encryption_exprs
> ----------------------------------------------------
>
> Key: IMPALA-13705
> URL: https://issues.apache.org/jira/browse/IMPALA-13705
> Project: IMPALA
> Issue Type: Bug
> Components: Backend, Infrastructure
> Reporter: Csaba Ringhofer
> Assignee: Daniel Becker
> Priority: Critical
>
> This happened after running the recently introduced tests from
> IMPALA-13039 in a different environment.
> The tests failed on RHEL 8.8 + OpenSsl 1.1.1k + ARM cpu.
> The passing tests I saw so far were with OpenSSL 1.0.2f/k and x86.
> An example for failed test:
> {code}
> select base64encode(aes_encrypt('ABC',
> '1234567890123456','AES_128_GCM','1234567890123456'));
> E assert Comparing QueryTestResults (expected vs actual):
> E 'x+am+BIqtrEK9FpC/zrvpOycjQ==' != 'TrL7'
> {code}
> A theory for the cause is that AES_128_GCM falls back to another encryption
> on newer OpenSsl versions
> {code}
> impalad.WARNING:W0127 17:13:02.248562 553382 openssl-util.cc:382]
> 9343d005464c6a5d:e252059d00000000] AES_128_GCM is not supported, fall back to
> AES_256_CTR.
> {code}
> Generally it seems a bad idea to fall back to another mode, I think that we
> should return an error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
