> Also, though rarely used, it's not impossible for the > source of a string getting expanded to come from a > runtime-variable place. Exim is that flexible.
Is there a real use case for that? It sounds dangerous to me. > > Well, given that reason nobody needed taint checking to begin with. ;-) > > You've not been following the log4j mess, obviously. > It's not funny at all. It is funny that everybody appears to be so surprised about it happening. The way software is developed and deployed these days probably creates way more problems like that and log4j is only the tip of the iceberg for sure. Will people learn anything from it? No way. I did not mean to imply taint checking was not needed, but the opposite: Saying "it's documented you should quote things" does not work. > Taint tracking for Exim was introduced because just such a mistake > was found in the then Exim default config. It was a CVE. > The obvious point fix was done, but I decided it was just too simple > for anybody writing config to make a similar error. Fine with me, except I would have liked if it had been called Exim 5, because that change broke each and every configuration I had, and those did check arguments. You just don't expect that from a minor version update. Unfortunately, the ease of Exim completely went away with the specific implementation and I wonder which design could get that back. It is not just Exim, the same problem exists in much code and I have yet to see a nice design pattern addressing that. Michael -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
