paulk-asert opened a new pull request, #2810:
URL: https://github.com/apache/groovy/pull/2810
ConfigObject.writeTo documents a round trip with ConfigSlurper.parse, which
compiles its output as a Groovy script. Keys were written bare unless they were
Groovy keywords, and values were rendered by FormatHelper.inspect, which quotes
a String but not other types. What that produced was source rather than data,
and it was read back as whatever it happened to parse as.
Measured before the change, writing a ConfigObject and parsing it back:
key 'a b' did not parse
key "a'b" did not parse
key "x = <statement>; y" *** executed on re-parse ***
nested block under key 'a b' did not parse
GString value holding a dollar did not parse
StringBuilder value did not parse
GString inside a list came back altered
a value of any other type did not parse
The executing case is the one that matters: a key is data, and an
application which stores an attacker-influenced entry name and later persists
the configuration would run it.
Render every key as an identifier when it is one and as a quoted literal
otherwise, rather than only quoting keywords, and give a quoted leading key the
receiver it needs to open a statement, which is what keyword keys have always
been given. Nested blocks accept a quoted key unchanged, so only the rendering
moved. writeValue now receives a key path whose components have already been
rendered, because it is also called with a composed path and must not quote the
path as a whole.
Carry a value which has no literal form over to its text so that it is
rendered as a quoted String: a CharSequence which is not a String would
otherwise be written double quoted, where a dollar is live, and a value of any
other type would be written as a bare toString(). Collections and maps are
converted through, which covers the same value nested inside them. Numbers and
booleans already write as themselves and are untouched.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
