mbedtls
mbedtls copied to clipboard
Mbed-TLS
fix test fail when seedfile not created
when MBEDTLS_ENTROPY_NV_SEED enabled, it depends on seedfile.
This patch tests if the file exists and create it.
To reproduce the issue with follow command
scripts/config.py full && make clean && make CFLAGS="-g -Werror " -j8 && ./tests/ssl-opt.sh
I don't think the test programs should create the seedfile. In production, a missing seedfile would be an error. Creating a seedfile in a sample program would be definitely wrong. In a test program, it's acceptable, but suspicious.
Do you mean that's the reason why selftest create the file ?
Therefore I object to this approach. I would prefer to improve the build and test scripts instead. I'm willing to be overridden if there are compelling arguments.
Got it, I will revert it and fix it in ssl-opt.sh
Rebased and add segment fault fail for test_suite_ssl when seedfile not created
Revisiting this a few months later, I think I've changed my mind.
In production, a missing seedfile would be an error.
Yes. But test environments aren't production: they run production code inside a test setup. So the real question is where exactly is the boundary between the production code, and the test setup.
Creating a seedfile in a sample program would be definitely wrong.
Indeed, but that's not what this was about.
In a test program, it's acceptable, but suspicious.
That depends exactly what the test program encompasses: is it just production code plus some dispatch code to call the production code with the desired inputs? Or is it also code that simulates the setup of a platform?
ssl_client2 and ssl_server2 are more than just production code plus dispatch code. They already contain things that are specifically for testing, such as a non-cryptographic implementation of mbedtls_psa_external_get_random (which is not something that must ever get into production). So creating a seedfile in these programs is fine.
Similarly, the unit test framework could create the seedfile. Specifically in mbedtls_test_platform_setup. (In fact the reason I thought about this today is that I'm working on tests for MBEDTLS_PSA_INJECT_ENTROPY, which requires a seed file like MBEDTLS_ENTROPY_NV_SEED, but a different one that's a bit more obscure. And there I decided to create the seed file in the platform setup.)
I'm willing to be overridden if there are compelling arguments.
One argument is “I'm a developer who isn't intimately familar with the project, I'm trying to run a test specifically for the feature I'm working on, and it's failing in some mysterious way, but only in some configurations, at the line PSA_INIT() which does something that's utterly mysterious to me”. Even for people on the Mbed TLS development team, we've had times when psa_crypto_init failed and it took us some time to realize that the problem was a missing (or too small) seed file. So I'm now thinking that facilitating the life of contributors (especially occasional contributors) is a pretty compelling argument.
I would welcome more opinions on the topic.
