paulk-asert opened a new pull request, #2808:
URL: https://github.com/apache/groovy/pull/2808
…rectory
{@snippet file="..."} took the file name verbatim from a doc comment and
joined it onto the package's snippet-files/ directory with no normalization or
containment check, so ../ segments escaped to anywhere the user running
groovydoc could read. JEP 413 confines javadoc's snippet resolution to
--snippet-path; the port added in GROOVY-11938 omitted the check.
This matters because it grants the author of documented source a capability
at doc time rather than at run time: a doc comment in a pull request can read a
file from the machine building the docs and publish its contents in the
rendered page.
Treat the file attribute as relative to snippet-files/, as JEP 413 does, and
confine resolution to that directory:
- an absolute name is refused outright, rather than accepted when it
happens to land inside the directory, so that a doc comment cannot resolve on
its author's machine and fail on a build agent;
- a relative name is normalized and required to stay inside;
- containment is re-checked after following symbolic links, so a link
within the directory cannot point out of it;
- an unusable name renders nothing instead of throwing.
Covered by two tests: one placing a file outside snippet-files/ and
referencing it relatively and absolutely, asserting its contents never reach
the rendered page; one referencing a file that genuinely is inside, by both an
absolute and a relative name, asserting only the relative form resolves.
Removing either guard fails the corresponding test.
--
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]
