<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Rémi,<br><br>> May i ask why ?<br>> <br>> A logger process interpolated strings, combined with the<br>> new shiny syntax of the template processor, make sense to<br>> me.<br><br>1. Isn't the entire purpose of String interpolation to (safely) go from raw, unsanitized inputs into a fully formed String? Java allows us to go one step further and create output values other than a String, since doing so aligns perfectly with the broad goal of interpolation -- take raw inputs, sanitize them, and produce a clean, validated output. The JEP even says so in the final bullet of the goals section -- "Enable the creation of non-string values computed from literal text and embedded expressions without having to transit through an intermediate string representation." -- <a href="https://openjdk.org/jeps/430">https://openjdk.org/jeps/430</a><br><br>2. And isn't the entire point why the Java team thought this was worth doing was not (just) because it was a simple boilerplate reduction, but because String interpolation is pretty much the front door for injection attacks? So, by attaching the "safe way" to the new shiny syntax, they have incentivized the right way for all developers.<br><br>With both of those in mind, it becomes clear that mixing side effects with String interpolation makes String interpolation inherently unsafe.<br><br>For example, let's think through your Logger example.<br><br>We just got finished (?) dealing with log4j. Somebody clever exploited our loggers, allowing them to download and execute scripts from the outside world.<br><br>If I were using your logger, where exactly would I perform validations to address this new threat? Yes, I know most of us just upgraded to the version that turned that feature off by default, but assume that you still need that feature. Because of the way your logger is designed, you have actually made it HARDER for the developer to validate the incoming request, not easier.<br><br>Maybe I could stick the validations in the logger itself? But what if I don't need those validations at every call site, only the service edges? Must I slow down all other log requests to defend myself in situations where it is not possible to be exploited? <br><br>Should I validate my String before putting it into the Logger? But now the design of your Logger forces me to do low-level validation on raw objects. String Templates allow me to output a "richer" object, which can enable richer validations. For example, if the logger takes in String a, b, and c, then a, b, and c on their own might not create a url, but together they do. I know a url on its own doesn't execute code, but you see my point. The point is, because your Logger won't let me check the outputs before using them, I must perform my validation on the "more raw" data inputs instead. This makes things harder to validate in some cases, and may require that I duplicate work that could be done by the Logger String Template (creating the "rich" output object) in order to make sure I am safe.<br><br>Alternatively, I could create different loggers that do different validations, or just forgoe validations entirely, but that's just moving the problem and complicating your solution. What if some call sites are vulnerable to ExploitA, others are vulnerable to ExploitB, and others are vulnerable to both? Do you plan to permutate through them all as individual types?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Mixing side-effects into String interpolation compromises safety.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">String interpolation is meant to increase safety, but it cannot guarantee it on its own. The idea is that you take the created String (or T), and then perform further validations upon the output that could not be done within the context of a String interpolator, AND THEN, once you have proven that the output is actually safe, then execute the output, whether that's logging it, handing it to a DB, etc. Sometimes, that won't be necessary, but sometimes it will be, so the 2 need to be separate to facilitate that flexibility.<br><br>Trying to bundle it all into a String template that executes its inputs takes away this exact opportunity from you. This is why your Logger example, and any other example that does side-effects in a String template, is a bad idea.<br><br>> And this is a slipery slope, if we have good template<br>> processor and bad template processor, how to recognize a<br>> good template processor from a bad one ?<br><br>There will be many things that make template processors better or worse than others. But as demonstrated above, state-changing side-effects are firmly in the bad category.<br><br>And as for good, it's best if you try to make your String templates "pure functions" whenever possible. The rule can be a little flexible (for example, you may have a counter that counts the number of times a Template processor was called), but you should try to stick to this unless absolutely necessary.<br><br>And since the only real benefit that your logger gives us is removing one line of code, that would definitely not be necessary.<br><br>LOGGER."\{validate(a)}-\{validate(b)}-\{validate(c)}"<br><br>Versus doing this.<br><br>final String output = contextSpecificValidations(SOME_STR."\{a}-\{b}-\{c}");<br>actualLogger.info(output);<br><br>You save one line of code and lose out on all of the flexibility. Does it make sense why the LOGGER Template Processor is problematic now?<br><br>Thank you for your time!<br>David Alayachew</div></div><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 23, 2023 at 4:09 PM <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">----- Original Message -----<br>
> From: "Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>><br>
> To: "Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>>, "amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank">amber-dev@openjdk.org</a>><br>
> Sent: Sunday, July 23, 2023 3:12:22 AM<br>
> Subject: Re: Presentation at JCrete.org<br>
<br>
>> So I don't believe a logger based on a template processor makes sense at least<br>
>> not until StringTemplate.Processor.Linkage becomes non-sealed.<br>
> <br>
> I'll take this further: I don't think a logger based on a template<br>
> processor makes sense *at all*.<br>
<br>
May i ask why ?<br>
<br>
A logger process interpolated strings, combined with the new shiny syntax of the template processor, make sense to me.<br>
<br>
And this is a slipery slope, if we have good template processor and bad template processor, how to recognize a good template processor from a bad one ?<br>
<br>
Rémi<br>
</blockquote></div>