We don't need it. Am Mi., 19. Aug. 2026 um 21:22 Uhr schrieb Daniel Dekany <[email protected] >:
> Anyone think it realistically breaks something for someone if we remove > those main methods and mini CLI utilities from freemarker.jar? > > I try to bring the artifact into a state that's not being flagged at > security-conscious companies, and this is one of the potential annoyances. > And really, why does a "Java library" dependency have those? > > Specifically, these are the ones we might should remove: > > - > - freemarker.core.CommandLine: It just prints the version number. Of > course freemarker.jar!/META-INF/MANIFEST.MF also has that. > - freemarker.core.ASTPrinter: Prints the AST of a template... > - freemarker.ext.dom.Transform: Command line to run a template with the > single specified XML document exposed. Output is written into the > specified > file or to stdout. Internally uses > freemarker.ext.dom.NodeModel#parse(org.xml.sax.InputSource, boolean, > boolean), which doesn't protect against XML External Entity (XXE) > attacks. > Ouch! Also, I guess it's too simplistic for real-world use, and once you > need a bit more, it's quite easy to replace with custom code (it's a 200 > line class). > - freemarker.ext.jdom.NodeListModel (our long deprecated legacy XML > wrapper), which have a main method: Similar to > freemarker.ext.dom.Transform, but even more minimalistic. Certainly it's > also open to XXE attacks. > - freemarker.template.utility.ToCanonical: Small utility where you pass > in a list of FTL files as command-line arguments, and it outputs similar > files in canonical form with ".canonical" appended after the file name. > I highly doubt people use this. > > All the others are in test code (not in FreeMarker jar), so they don't > matter. >
