-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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 ssl_context_info.c to correctly check for EOF - type-limit bug #3449
Conversation
ChangeLog.d/bugfix_1.txt
Outdated
@@ -0,0 +1,3 @@ | |||
Bugfix: |
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.
This needs to be Bugfix
without :
ChangeLog.d/bugfix_1.txt
Outdated
@@ -0,0 +1,3 @@ | |||
Bugfix: | |||
* x509: do not include time.h without MBEDTLS_HAVE_TIME. | |||
* Fixes type-limit error programs/ssl/ssl_context_info.c. |
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.
Please use complete, grammatical sentences in the change log. Also, please write with the library user in mind. Why would the user care about a “type-limit error”? Does the compilation fail on some platforms? Is there a runtime bug?
ChangeLog.d/bugfix_1.txt
Outdated
@@ -0,0 +1,3 @@ | |||
Bugfix: | |||
* x509: do not include time.h without MBEDTLS_HAVE_TIME. |
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.
We usually acknowledge contributors in changelog entries. Unless you don't want to be credited, feel free to add
Reported and fix contributed by naynajain in #3449.
You can use your name instead of your GitHub handle if you prefer.
programs/ssl/ssl_context_info.c
Outdated
@@ -379,7 +379,7 @@ size_t read_next_b64_code( uint8_t **b64, size_t *max_len ) | |||
int valid_balance = 0; /* balance between valid and invalid characters */ | |||
size_t len = 0; | |||
char pad = 0; | |||
char c = 0; | |||
signed char c = 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.
This change doesn't look right. c
contains either a character read from a file or EOF, so the correct type is int
.
This bug fix should have a non-regression test, with an input file containing the byte '\xff'
.
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.
This change doesn't look right.
c
contains either a character read from a file or EOF, so the correct type isint
.This bug fix should have a non-regression test, with an input file containing the byte
'\xff'
.
Thanks for the review.
When you say it should have "non-regression test, with an input file... ", where are you expecting this test ? The bug fix is for one of the program file. And it seems that takes command line args for testing different cases. I have not explored ssl code in mbedtls yet, just started looking at this file because of failure with cmake to build it, so I might be missing something.
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.
There are tests for this program in tests/context-info.sh
Apparently there are also build errors in TLS code. This pull request is complementary with #3444. It would be great if you could synchronize with @raoulstrackx to fix the problem everywhere. |
I have messaged to @raoulstrackx to see how he wants to go forward. In the meantime, I was wondering if I should resubmit just another bug in this commit "type-limit" error while we are coordinating "MBEDTLS_HAVE_TIME" issue with @raoulstrackx. Thanks & Regards, |
Sorry, I don't understand what you mean by “type-limit error”. |
I meant this commit in PR - "mbedtls: Fixes type-limit error". Thanks & Regards, Thanks & Regards, |
Oh, right. Please make a separate PR for that, or reuse this one to do only that. As I said before, please fix this correctly instead of ignoring the error, and add a non-regression test. |
Sure. Thanks & Regards, |
Daniel Axtens from my team is working on MBEDTLS_HAVE_TIME bugfix. He will post his changes as separate PR. I would be using this PR for the fix related to "type-limit" issue. I am renaming this PR to "Fix the EOF check error in ssl_context_info.c " that is identified by gcc warning for type-limit. |
read_next_b64_code() function, that parses base64 encoded input doesn't recognize the EOF and returns when "Too many bad symbols are detected". This issue got identified when gcc complained for type-limit error during cmake. This patch fixes the issue by changing the variable type to int and removing type-cast of fgetc() output to 'char'. Signed-off-by: Nayna Jain <[email protected]>
This patch updates the test cases to also check for EOF correctly. Signed-off-by: Nayna Jain <[email protected]>
Before this patch, running ssl_context_info with valid file input was exiting not because of EOF but because of error "Too many bad symbols detected" Deserializing number 1: Base64 code: Mbed TLS version: Enabled session and context configuration: Session info: Certificate: Ticket:
Session others: Random bytes: Context others: ERROR: Too many bad symbols detected. File check aborted. After the fix, it is exiting correctly recognizing EOF as below. No error is reported. $ ./programs/ssl/ssl_context_info -f ./tests/data_files/base64/cli_cid.txt Deserializing number 1: Base64 code: Mbed TLS version: Enabled session and context configuration: Session info: Certificate: Ticket:
Session others: Random bytes: Context others: |
I can't reproduce that on my system (Ubuntu 20.04 running on x86-64, development branch). Perhaps this is platform-specific? |
Hmm.. so I retried on x86 with RHEL, I didn't get this error. Even if this error doesn't appear, there is a valid issue of EOF not getting interpreted correctly. So, I assume the PR and the fix is still applicable. The difference in tests behaviour.. I will try to look at separately. Sounds ok ? Thanks & Regards, |
Ok, thanks for confirming your environment. I think the difference comes from the fact that
We should have at least one build of the programs targeting Arm in our CI. We already have an issue open tracking that (and more): #3299
Yes, absolutely. As a matter of principle when a new test is added I always try to run the test without the fix to make sure the test indeed fails when it's supposed to. Here I should have done that on a Arm platform. That's not an issue with the PR, just an issue with how I tested it! I'll finish reviewing the PR soon, then. |
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.
Looks good to me.
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.
The bug fix is ok. The changelog entry needs work. The added test isn't a non-regression test.
@@ -400,7 +400,12 @@ run_test "Wrong base64 format" \ | |||
"def_bad_b64.txt" \ | |||
-m "ERROR" \ | |||
-u "The length of the base64 code found should be a multiple of 4" \ | |||
-n "bytes left to analyze from context" | |||
-n "bytes left to analyze from context" \ |
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.
There shouldn't be a trailing backslash here since there is no continuation line.
run_test "EOF base64 format" \ | ||
"def_bad_b64_eof.txt" \ | ||
-m "Finished. No valid base64 code found" \ | ||
-n "ERROR" \ |
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.
There shouldn't be a trailing backslash here since there is no continuation line.
@@ -0,0 +1 @@ | |||
/w== |
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.
There's no “EOFish” character (byte 0xff) here. This is a well-formed file containing Base64 data. The encoded data isn't a valid SSL context.
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.
There's no “EOFish” character (byte 0xff) here. This is a well-formed file containing Base64 data. The encoded data isn't a valid SSL context.
Thanks for your review.
It is actually base64 encoding of 0xFF. So, not sure what do you mean by "no "EOFish""
And yes, it is not a valid SSL Context. It is just meant to represent EOF to test that it can be interpreted correctly by read_next_b64_code() function.
Am I missing something ?
Thanks & Regards,
- Nayna
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.
The bug was in the parsing of the base64-encoded, not in the handling of the decoded data. So the fact that the decoded data contains a 0xff is irrelevant. What matters is when the file itself contains a 0xff.
@@ -0,0 +1,3 @@ | |||
Bugfix | |||
* read_next_b64_code() isn't correctly checking against EOF because it checks against 'char' rather than 'int'. This is identified via type-limit warning reported by gcc. |
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.
Please format changelog entries to 80 columns.
@@ -0,0 +1,3 @@ | |||
Bugfix | |||
* read_next_b64_code() isn't correctly checking against EOF because it checks against 'char' rather than 'int'. This is identified via type-limit warning reported by gcc. |
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.
Please word changelog entries for users of the libraries, not for maintainers. read_next_b64_code
is not meaningful to users, ssl_context_info
is. This is a bug in ssl_context_info
which, on some platforms, is silently truncating base64 data at character \377
rather than ignoring it.
Notes:
Description
Reference: Pull Request 3431
Separated bug fixes from PKCS7 feature PR
Status
READY
Requires Backporting
It is a bug fix, but the offending file is not present in any of the LTS branches, so no backporting required [edited by mpg].
Migrations
If there is any API change, what's the incentive and logic for it.
NO
Additional Comments:
Changelog is updated.