-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix assorted issues with legacy systems #644
Changes from all commits
2f7dbe4
80524bb
0edcbc9
f8a911c
5d65d2b
15636a3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -359,6 +359,13 @@ func TestTokenProtectDetectExtendedData(t *testing.T) { | |
} | ||
|
||
func TestTokenProtectDetectCorruptedToken(t *testing.T) { | ||
// FIXME(ilammy, 2020-05-25): avoid capacity allocation panics (T1648) | ||
// This tests panics on 32-bit architectures due to "int" overflow. | ||
// The implementation needs to check for "int" range when casting "C.size_t". | ||
if uint64(^uint(0)) == uint64(^uint32(0)) { | ||
t.Skip("avoid panic on 32-bit machines") | ||
} | ||
|
||
key, err := keys.NewSymmetricKey() | ||
if err != nil { | ||
t.Fatal("cannot generate symmetric key", err) | ||
|
@@ -442,6 +449,13 @@ func TestTokenProtectDetectExtendedToken(t *testing.T) { | |
} | ||
|
||
func TestTokenProtectSwapDataAndToken(t *testing.T) { | ||
// FIXME(ilammy, 2020-05-25): avoid capacity allocation panics (T1648) | ||
// This tests panics on 32-bit architectures due to "int" overflow. | ||
// The implementation needs to check for "int" range when casting "C.size_t". | ||
if uint64(^uint(0)) == uint64(^uint32(0)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe better to split to two functions which test 32/64 bit versions and place them to separate files with specific build tags? One file will be compiled only if run on 32-bit system, another on 64-bit. Then we will not have such check and if somebody runs tests on their own 32 bit machine, tests will be checked. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that it fails on 32-bit machines and we don't want that so we temporarily disable the test. It's still there and will be shown as skipped. I believe that Themis is a portable library so the test suite should not really be platform-dependent. The same tests should pass everywhere, regardless of pointer size, number of registers, endianness, etc. (Except for natural limitations, such as impossibility of handling continuous 3 GB data buffers on 32-bit machines.) So I'd rather have this ugly wart reminding that it's an ugly wart instead of accepting different test suites for different architectures as a normal thing. |
||
t.Skip("avoid panic on 32-bit machines") | ||
} | ||
|
||
key, err := keys.NewSymmetricKey() | ||
if err != nil { | ||
t.Fatal("cannot generate symmetric key", err) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -29,8 +29,12 @@ WHITELIST="(THEMIS|themis|secure_(comparator|session)|STATE)_.*" | |
# thing to do is to split the generated code into different files for different | ||
# platforms (like themis_x86_64.rs, themis_arm64.rs, etc.) and conditionally | ||
# compile them depending on target. | ||
# | ||
# Though, we do disable layout tests which *are* architecture-specific and | ||
# we cannot include them without breaking either 32-bit or 64-bit machines. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps we could include tests depending on the current architecture? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
We could but there are a lot of ifs here. Since Docker does not support 32-bit hosts, cloud-based CI services do not offer 32-bit runners. We probably could plug in our own into GitHub Actions, but I don't know whether their runner supports 32-bit systems. Ideally we'd be testing on ARM systems as well. We can use Docker containers with 32-bit userland but that's not quite the same. Though, it'd probably catch the issues we have encountered here since they are more about integer overflow than memory limits. Another thing to consider is that it would double the test matrix since we'd better be testing all wrappers, Core alone is not enough. Overall, I'd like to get this done eventually. Right now we rely only on internal BuildBot runs to have something resembling regular testing on something other that x86_64. Or do you mean that layout tests should be there, just be different for architectures?
Well, I'd like Bindgen to be able to generate tests like that automatically, but that's quite hard. The best we could get right now is generate multiple modules:
And then conditionally build and reexport one of them. However, since the only thing that is different is the tests, I feel that it's a little bit overkill. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Of course, it would be great to have a complete set of test for each of platforms. Well, I share your view at all. Lets start from this position and have all our future plans in the backlog :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yup. I've just created an internal task to track this (T1655). |
||
bindgen bindgen.h \ | ||
--no-doc-comments \ | ||
--no-layout-tests \ | ||
--rustified-enum "themis_key_kind" \ | ||
--size_t-is-usize \ | ||
--whitelist-function "$WHITELIST" \ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,7 +38,8 @@ static char user_context[] = "secure cell user context"; | |
|
||
static bool non_zero_buffer(const uint8_t* buffer, size_t length) | ||
{ | ||
for (size_t i = 0; i < length; i++) { | ||
size_t i; | ||
for (i = 0; i < length; i++) { | ||
if (buffer[i] != 0) { | ||
return true; | ||
} | ||
|
@@ -1911,6 +1912,7 @@ static void scell_seal_passphrase_compatibility(void) | |
static void scell_seal_passphrase_stability(void) | ||
{ | ||
themis_status_t res = THEMIS_FAIL; | ||
size_t i; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hello |
||
const uint8_t passphrase[] = "never gonna give you up"; | ||
const uint8_t message[] = "never gonna let you down"; | ||
const uint8_t context[] = "never gonna run around and desert you"; | ||
|
@@ -1931,7 +1933,7 @@ static void scell_seal_passphrase_stability(void) | |
(const uint8_t*)"\x80\x00\x01\x41\x0C\x00\x00\x00\x10\x00\x00\x00\x19\x00\x00\x00\x16\x00\x00\x00\x46\xAF\xD7\xFE\x56\xEE\x07\xD7\xA6\x40\x48\xA8\x00\xA9\xD6\x0C\x80\x67\x57\x65\xFF\xB6\x59\xD8\xC8\x77\xD8\x17\x40\x0D\x03\x00\x10\x00\xC3\xA1\x85\x9A\x13\x82\x7A\xEE\x1F\xDB\x9C\xB3\x31\x4E\xF9\x27\x3F\xAC\x61\x1C\xA5\x7D\xAA\x54\x43\xF3\x78\x19\x39\x7C\x5A\x9D\x71\x42\xA4\x6F\x87\x96\x1A\xBD\xDB"}, | ||
}; | ||
|
||
for (size_t i = 0; i < ARRAY_SIZE(encrypted_data); i++) { | ||
for (i = 0; i < ARRAY_SIZE(encrypted_data); i++) { | ||
uint8_t* decrypted = NULL; | ||
size_t decrypted_length = 0; | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have we started to disable tests because we don't like them? :P
(i've read PR description, just kidding here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right. For posterity: a fix for this issue is scheduled for 0.13.1. After that decryption of corrupted data of this sort will return an error — likely a different one for 32-bit and 64-bit machines, but still an error.