On Thu, Jan 23, 2014 at 9:41 PM, Kai Blaschke kai.blaschke@kb-dev.net wrote:
configure | 1 + configure.ac | 1 + dlls/bcrypt/tests/Makefile.in | 4 +++ dlls/bcrypt/tests/bcrypt.c | 59 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 65 insertions(+)
Hi, Kai.
- status = pBCryptGetFipsAlgorithmMode(&result);
- ok(!status, "expected status STATUS_SUCCESS(0), got 0x%08X\n", status);
- ok(!result, "expected result FALSE, got %d\n", result);
If the value depends on a registry entry how can you be sure it will always return 0? If the registry key is the only parameter required to return in this function IMO you should read the registry here and check against that instead of a fixed value.
Best wishes, Bruno
Am 24.01.2014 01:20, schrieb Bruno Jesus:
Hi, Kai.
If the value depends on a registry entry how can you be sure it will always return 0? If the registry key is the only parameter required to return in this function IMO you should read the registry here and check against that instead of a fixed value. Best wishes, Bruno
I thought about this - ideally, the test should test the function setting different values in the registry and checking the function's return value accordingly, but this value is a local security policy setting, which we cannot guarantee to be writeable for the user executing the test. I'll add some code which checks if one of the two possible keys exist and then use the actual value to check the result.
Interestingly, the original implementation uses the same "wrong", but simple logic I used in the implementation, just returning the lower 8 bits of the DWORD value to determine the enable state. The only difference is that the Microsoft implementation only returns either 0 or 1. Setting the value to 0x100 or any multiple of that causes BCryptGetFipsAlgorithmMode to return 0 on a Windows machine.
I'll send in new and hopefully final patches with these changes.
-- Kai
-
Bruno Jesus -
Kai Blaschke