3 ms·
You can't do that. You know the test, you know the expected answers. You can trivially forge the test being run. There's no way you can get around it for determ
by viraptor 2y ago
You can't do that. You know the test, you know the expected answers. You can trivially forge the test being run. There's no way you can get around it for deterministic tests. You could write only nondeterministic tests and require a unique answer every time... but that gets rid of any other time gains you got from the system.
- viraptor 2y agoActually no, even nondeterministic tests won't work, because you can just generate the answers assuming the changed source, but submit it for the change you actually wanted. Unless you DRM the whole machine successfully (good luck), there's no way to do it.
- jiehong 2y agoFair enough. I guess if the testing framework of the language used would take into account the hash of the current file and imported sources and generate a signature based on that, it could detect on which content it ran, and certify this, somehow. But I guess it's your DRM idea: the testing lib should not be tampered with in the first place.
- viraptor 2y agoThat's an area of TOCTOU issues. You can either hash the file and then replace it before running, or replace the code which was supposed to do the hashing with a constant value you want, or just run in a VM, freeze it, and replace the hash in memory at the time you want. Unless you perfectly control everything: drive, system, application - you can't validate anything. That is unless you want to run in a signed trusted computing enclave, but those have at least one security failure a year in practice.