Sounds doable at first glance. Some of them at least, like disabling certain built-ins. It's certainly a good idea to discuss how you intend to do things early, to avoid back-and-forths later.
Can you tell more about the kind of template security you are looking for? I assume you have seen the related FAQ entry ( https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security), but it seems you want to do some more here. Like dodging the mistakes of well meaning template authors , which then could allow XSS attacks by those who can only provide data to the templates? Exposing AST has some dilemmas for non-technical reasons. Generally, the main hurdle with FreeMarker 2 is that we have to keep backward compatibility. While we don't have a pubLISHED AST API-s, part of it is unfortunately still public. Also, after 20 years we can expect some user code to even check non-public class names, etc. Like maybe you did too. That's why the API was never cleaned up either. So, if you can have these flags, do you still need to expose the AST? I would prefer to expose higher level functionality to users instead. On Fri, Jan 13, 2023 at 7:39 PM Alon Ziv <nola...@google.com.invalid> wrote: > We have internal code @google that executes templates that aren't fully > trusted. Currently we use Java introspection on the Template object (using > internal class names 😕) to verify such templates do not use constructs we > deem "unsafe", such as disabling auto-escaping via "?noEsc" or > <#noautoesc>, as well as the "?eval" and "?interpret" built-ins. > > We are considering upstreaming these capabilities; some combination of: > > - Provide a formal API for walking the template AST (rather than the > existing test-only ASTParser) > - Create a Configuration setting for "forced escaping" - which will > disable "?noEsc" and <#noautoesc> for the affected template at parse time > - Adding Configuration settings for "disable Interpret" and "disable > Eval" (likely a bit flag so it's potentially extensible easily) > > > Will such work be welcome by the project? > -- Best regards, Daniel Dekany
