Conversation
This file contains hidden or 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
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.
An unquoted string starting with
!is a YAML type tag to force the following value to a specific type registered by the decoder (as opposed to a built-in type that starts with!!). We don't register any such types so there is no valid usage for this. On the flip side, there are places where a string starting with!is appropriate such as globs, but when forgetting quotes, it gets parsed as a type tag, which effectively silently replaces the value with an empty string which we then use as is. For globs, this means ignoring!unexclude globs completely, things that shouldn't be excluded are. This actually affects both v1 and v2 to different degrees.The approach is to parse the YAML once to a YAML node to first to be able to distinguish type tags from values to find and reject them, before parsing the YAML into the config struct. Unfortunately, there seems to be no way to do it in a single pass since a config struct doesn't preserve type info and no decoder, even in other libraries, have an option to reject local tags. Parse only happens once per operation and is still microseconds for very large configs, I think the problematic case (silent corruption) is significant enough that we need to eat it.
Fixes #3973