Skip to content

fix: maxBodySize can not short circuit on frameLengh #181

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

Merged
merged 3 commits into from
Aug 6, 2019

Conversation

seebees
Copy link
Contributor

@seebees seebees commented Aug 3, 2019

In the case of a framed message that encrypts less than the frameLenght,
maxBodySize was doing the wrong thing.

Remove the check.
Add tests vectors that cover the case.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

  • Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

In the case of a framed message that encrypts less than the frameLenght,
maxBodySize was doing the wrong thing.

Remove the check.
Add tests vectors that cover the case.
@seebees seebees requested a review from a team August 3, 2019 00:16
Copy link
Contributor

@lavaleri lavaleri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To check my understanding:

The check against maxBodySize cannot be done in parseHeaderStream because it is not until we get to the body that we can decide whether we have exceeded that limit or not. Because we have a check in VerifyStream we are still good, and removing this check in ParseHeaderStream now allows the case where the actual data encrypted is less than the maxBodySize, but the frameLength is greater than the maxBodySize.

export interface ParseHeaderOptions {
maxBodySize?: number
}

export class ParseHeaderStream extends PortableTransformWithType {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh weird, for some reason I missed that change. Ignore me.

@@ -83,4 +83,21 @@ describe('decrypt', () => {
{ encoding: 'base64' }
)).to.rejectedWith(Error, 'Invalid Signature')
})

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No unit tests for ParseHeaderStream?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically, no. But implicitly, the stream test in this file will exercise just about everything.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless there is some reason why unit tests for ParseHeaderStream specifically would not be useful, we should add them.
Either in this PR, or (because the logic added in this PR seems to be sufficiently tested below) tracked in a new issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seebees seebees merged commit b07a084 into aws:master Aug 6, 2019
@seebees seebees deleted the max_body_size-final_frame branch August 6, 2019 22:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants