Google's import process strips out all these classes before committing to
our internal repo. We definitely don't need them.

On Wed, Aug 19, 2026 at 10:42 PM Christoph Rueger <[email protected]>
wrote:

> 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.
> >
>

Reply via email to