-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
Use readFully()
to read exactly the number of bytes we expect from the Stream
#28515
Merged
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
2ea6d2a
Changes the encryption/decryption method
jkakavas 8241318
Zerofill sensitive data
jkakavas 63a4fcd
Changed how data is read from the stream
jkakavas 4cc56cf
Merge remote-tracking branch 'origin/master' into fix-for-bcfips
jkakavas 13ae59b
Replaced * imports
jkakavas 248c73d
Merge remote-tracking branch 'origin/master' into fix-for-bcfips
jkakavas a31ab4f
Merge remote-tracking branch 'origin/master' into fix-for-bcfips
jkakavas e3d79a5
Addresses feedback
jkakavas f3274bb
Merge remote-tracking branch 'origin/master' into fix-for-bcfips
jkakavas 0526e03
Merge remote-tracking branch 'origin/master' into fix-for-bcfips
jkakavas f93e9bf
Ensure readFully reads all bytes
jkakavas 460ee62
Remove irrelevant test
jkakavas e853a6a
Adds test for trailing garbage
jkakavas 3c56cfd
Addresses feedback
jkakavas 1539793
Merge remote-tracking branch 'origin/master' into fix-for-bcfips
jkakavas 9b90e9b
Retain root cause when throwing SecurityException
jkakavas File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I think we should add a test that would have failed using the old method. This would probably require a small refactoring to do this; I am thinking instead of
new ByteArrayInputStream
we call a method that could be overridden in a test. There we would have a special stream where a call toread
would not fully populate the byte arrayThere 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.
I don't think we need to override any methods. We can form streams of bytes in whatever order we want in tests.
However, if I understand the problem correctly, it has to do with read boundaries. Eg, an input stream may choose to return less bytes to a
read
call than the array can contain, since it may just copy the rest of an existing buffer (eg a decrypted block in CipherInputStream). By callingreadFully
, multiple read calls are made to ensure the array is filled completely or EOF is reached. I think this will be very difficult to mimic, given the behavior ofread
here will be implementation dependent. The best we could do is add tests to trigger each of the possible EOFs fromreadFully
calls by truncating the keystore at certain points (although this would probably be difficult to do within the encrypted bytes).I do think we should have a test to ensure there cannot be garbage after the encrypted data.
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.
Revisiting this after coming back.
Care to elaborate @rjernst ? You mean attempting to
readFully()
into a larger array and verifying that we get the EOFException rather than keep reading garbage ?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.
I mean adding a test with garbage at the end, so that we know the last readFully logic works. The intermediate readFully's are harder, as I described above.
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.
If I understand correctly, we should fail if there is garbage right? Currently this is not the case at least based on the test @jkakavas added.
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.
readFully
reads exactly the number of bytes we instruct it to, or throws an EOFException. I interpreted @rjernst comment above to mean that we need to have a test verifying that even if there more garbage, readFully won't read them, but read the bytes it should(this is what the test I added does, and it should not fail )Another way to interpret the comment I guess, would be to write less bytes to would be to write fewer bytes to the
DataOutputStream
than we indicate with thewriteInt
above and make sure that on decryption, readFully throws the EOFException instead of reading in garbage in order to fill our byte array - I can add that too.Writing about this, the second interpretation makes much more sense I guess..
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.
That was not my intention. I meant it the way @jaymode suggested: we should fail when trailing garbage is present, and have a test for that.