On Fri, Sep 19, 2014 at 12:49 PM, Kai Blaschke kai.blaschke@kb-dev.net wrote:
If you need to do something that requires admin privileges, you should
try to do it and check for an access denied error. If it fails with access denied, you should skip the test. (Ideally, you should try running your test with a limited account on Windows.)
Non-admin users lack the proper access rights to change anything in HKLM, so at least on modern systems with active UAC the test won't work.
I would be more worried about the fact that it's changing a global
user preference. Maybe you should just read the key and verify that the API matches the value there.
It's worse, to fully test both OS variants, the test would have to delete and create subkeys, since Microsoft put the value under a subkey of the name of the former value since Vista. That's nothing I'd like to do on some unsuspecting user's machine.
This is probably more depth than you should be putting into
investigating native's behavior. If it's supposed to be a boolean, and the expected values are 1 and 0, you can assume it's one of those and not worry about what happens if it's 256 (unless you know a real application that sets that value).
Yeah, that's what the documentation states, too. I tested this just out of curiosity.
I'll leave it with my current code for both the implemenation and the test, and submit the patch for reviewing.
Kai, out of curiosity, is there an app that depends on being able to enable FIPS mode? --Juan