Add cosistency test for fcrypt. #81
Conversation
besser82
force-pushed
the
besser82/fcrypt_consistency
branch
2 times, most recently
from
afb276b to
75270ec
Compare
Codecov Report
@@ Coverage Diff @@
## develop #81 +/- ##
===========================================
- Coverage 96.46% 96.39% -0.07%
===========================================
Files 32 32
Lines 3109 3109
===========================================
- Hits 2999 2997 -2
- Misses 110 112 +2
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## develop #81 +/- ##
========================================
Coverage 96.39% 96.39%
========================================
Files 32 32
Lines 3109 3109
========================================
Hits 2997 2997
Misses 112 112
Continue to review full report at Codecov.
|
|
Looks like we need to get #62 working before we can merge this one, as we cannot run |
|
I have just pushed a patch on top of this branch which reorganizes the work done by the test to make better use of parallelism and also eliminate some redundant operations. I hope this make it possible to test fcrypt on top of the others without having to increase the timeouts again. Assuming CI goes green, I'm good with the branch as of this patch. Please feel free to squash my change and/or make further adjustments on top. |
fcrypt, like crypt, is not thread-safe, so have the main thread call crypt() and then fcrypt() for each test case; meanwhile, another thread calls crypt_r() and then crypt_rn(), and a third thread calls crypt_ra() and then repeats the call with the output hash instead of the original setting string. All are checked solely against the expected hash from test-crypt-kat.inc; transitivity means there’s no point in testing them against each other once they passed that check. Also, errors are reported immediately instead of being buffered up, which means we can scrap a bunch of memory management code. The collisions test, meanwhile, is moved to test-crypt-kat-gen.py. If we know that the only collisions among the *expected* hashes are the ones we anticipate, then checking the freshly generated hashes against the expected hashes is sufficient to detect new collisions. So we don’t need to do any of that work at build time.
besser82
force-pushed
the
besser82/fcrypt_consistency
branch
from
e3a6d4e to
a864b03
Compare
|
@zackw I've corrected the way |
For some reason the code generated by Clang is significantly slower than the code generated by GCC, when run under Valgrind. It’s only about ten additional minutes of wall-clock time, but it makes the test suite trip not only Travis’s documented ten-minute no-output timeout (which can be worked around), but their undocumented 45?-minute no-matter-what timeout. Switch the Clang checked build on Travis to use ASan+UBSan instead of Valgrind. This is much faster and may also detect a different subset of potential bugs.
besser82
force-pushed
the
besser82/fcrypt_consistency
branch
from
a864b03 to
0a7ada6
Compare
|
@zackw Added |
|
Will merge on CLI as soon as Travis turns green. |
As suggested / proposed in #79.