I don't follow. Is that a yes? So, what I'm saying is that freemarker-generator is inherently "unsafe", like any power-user/developer tool is. And also you add tools to it that are also "unsafe" (which is fine). So there's no point in deviating from the FreeMarker defaults, whichare, historically, about convenience. Also the defaults won't change in 2.x, because of backward compatibility (unless you specifically ask for some high incompatibleImprovements, like 2.4.x). So it won't break because of upgrading the FreeMarker dependency.
On Wed, Oct 28, 2020 at 9:27 PM Siegfried Goeschl < siegfried.goes...@gmail.com> wrote: > Hi Daniel, > > I think the outcome was that we might use more secure default settings for > FreeMarker and so I switched to the secure settings to see if I would need > them > > Thanks in advance, > > Siegfried Goeschl > > > > On 21.10.2020, at 08:01, Daniel Dekany <daniel.dek...@gmail.com> wrote: > > > > Does that mean that you agree that we should leave them on the actual > > FreeMarker 2.3.x defaults (?api enabled, ?new set to "safer")? > > > > On Mon, Oct 19, 2020 at 7:31 PM Siegfried Goeschl < > > siegfried.goes...@gmail.com> wrote: > > > >> Hi Daniel, > >> > >> yes, I disabled them since I assume that they will be the default > settings > >> > >> Thanks in advance > >> > >> Siegfried Goeschl > >> > >>> On 11.10.2020, at 20:42, Daniel Dekany <daniel.dek...@gmail.com> > wrote: > >>> > >>> I noticed that ?api and ?new are by default disabled in > >>> freemarker-generator. However, freemarker-generator is inherently > unsafe, > >>> as it has tools.freemarker.objectConstructor, and > >> tools.freemarker.statics. > >>> For a command-line tool that's probably fine, but then above two > >>> configuration settings should be left on their convenient defaults as > >> well. > >>> > >>> In general, allowing someone to specify arbitrary command line > arguments > >>> to freemarker-generator CLI means that they can do pretty much anything > >> (as > >>> they can provide an arbitrary template with the -i option, then access > >> the > >>> tools). Again, I think such risk is expected from a command line tool, > >> but > >>> it's better if we are conscious about this. > >>> > >>> -- > >>> Best regards, > >>> Daniel Dekany > >> > >> > > > > -- > > Best regards, > > Daniel Dekany > > -- Best regards, Daniel Dekany
