Exim introduced variable tainting as a security measure starting from exim 4.93. Starting from exim 4.96, tainting is mandatory for commands. This means that it is no longer possible to pass variables to pglister's inject.py (which requires passing $sender_address, $local_part, $domain and $header_message-id) or pgarchives' load_message.py (which requires passing $local_part).
Exim, while enforcing these strict security policies, only provides the possibility to de-taint variables in very specific situations (explicit matching with a list). Problem is known and discussed here [1]. This is very annoying in our case, as $sender_address or $header_message-id can be pretty much anything (and no, matching against a regexp is not sufficient to de-taint). I've been scratching my head over this for a while and can't figure out a proper way to fix this issue. A possible workaround would be to blindly de-taint anything using an ugly hack [2] but that defeats the purpose of having variable tainting in the first place, and doesn't seem like a valid, long-term, production-ready solution.
I'm starting to wonder if the only solution would be to have pglister fetch information from exim in some way, instead of the other way around.
Any idea?
I'm no exim expert, so I'm explicitly copying in Stefan here in case he didn't spot this one.
Maybe we could have a switch to inject that picks these up from the environment: I *think* most of those are actually made available by default as environment variables in exim if I understand https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_pipe_transport.html point 4 correct. Or would those have the same problems with tainting?
AIUI the only thing we couldn't get that way might be the message-id? The question is, can we add that to the environment without getting into taint problems?
