scanner: Improve regular expression in "scanner".scanHeredoc(). #245
Conversation
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
When there are multiple cartridge returns at the end of the line, the regular expression will consider n-1 of them to be part of the string. Later, the last `\r` is removed. That may mean that a line that did previously *not* terminate a heredoc string may now terminate it, changing the meaning of the HCL file.
|
Thanks! |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR fixes two issues when parsing heredoc strings:
The regular expression was not anchored to the beginning of the line, allowing arbitrary garbage in front of the delimiter.
The regular expression did not accept an arbitrary number of cartridge returns. One optional cartridge return (
\r) and one newline (\n) were considered a line break. If a line ends in multiple cartridge returns, e.g.EOF\r\r\n, it was not considered to end the heredoc string with delimiterEOF. However, the formatter removes one cartridge return, so that a repeated parsing would consider the same line to end the heredoc string, resulting in a different interpretation of the input.In most cases parsing the output results in a syntax error, but it is fairly easy to create inputs that change semantic due to formatting. For example,
"x=<<_\n_\r\r\ny=1\nz=<<_\n_\n"evaluates tox = <string>initially, but after reformatting it evaluates tox = <string>, y = <int>, z = <string>.Kudos to dvyukov/go-fuzz for finding this!