Hello, I think this is ready for submission now. Please let me know how best to proceed.
Thanks -Nick https://github.com/bdraco/exim/commit/09792322d9224b0407783a19c2dd57fd1a8bbd52 On Mar 31, 2013, at 12:47 AM, Phil Pennock <[email protected]> wrote: > On 2013-03-31 at 00:20 -1000, J. Nick Koston wrote: >> I was actually able to get the force_command approach working after >> doing some more digging into exim guts to understand how things work a >> bit better. Its a much more simple approach. > > *phew* I wasn't crazy to suggest it then. :) > >> https://github.com/bdraco/exim/commit/force_command >> >> Please let me know what else you would like me to do to prepare this. > > As things stand, I think you've invalidated our security guarantees > about argument-by-argument expansion. Also, you do the expansion before > $1 and friends are set up. > > I suspect that the cleaner solution is to give a 'flags' parameter to > the `set_up_shell_command()` function call, then if force_command is > set, include a FLAG_VALUE or'd into the flags parameter which says to > treat $address_pipe specially, needing to be split apart into multiple > parameters. > > This way, expansion occurs in the normal place, and you have one > special-case piece of logic, which can be documented in "29.3 How the > command is run" too, noting that if force_command is set and the command > came from a router, then command is evaluated and $address_pipe is split > up and is *not* held to one option, like everything else. > > This minimises the impact, avoids expanding the string in different > places, with different variables already set up, and avoids quotes and > backslashes in data resulting from expansion ending up creating new > parameters. > > Regards, > -Phil > -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
