Quoting Jeremy Harris via Exim-users (exim-users@???):
> It is far to easy for someone to write a matcher which just
> untaints everything, disabling the security. Three people
> would do that, and one would post it on serverfault. Then
> it would be cargo-culted forever.
You mean like this 'hack'?
https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/
TL;DR:
echo '*' >/etc/exim/detaint
DETAINTFILE = /etc/exim/detaint
BADCHARS = \N[^A-Za-z0-9_.-]+\N
SAFEDOMAIN = ${lookup{${sg{${domain:$h_from:}}{BADCHARS}{_}}}lsearch*,ret=key{DETAINTFILE}}
... Profit!
Late to the party i see, but i was bitten by the new 'tainted
data'-feature yesterday and after reading this thread, i too would
really like to see that ${untaint{}{}} idea implemented.
I'm all for 'out of the box safety', but making it quite hard to untaint
data is not very user friendly imo. I've yet to find more situations in
my config that break. That's another peeve: there is no warning or error
until you run into it.
My frustration mostly comes from the fact that my config was working for
years, untouched, then suddenly it doesn't anymore and there is no clear
guidance on how to fix this mess as others in this thread reported too.
My situation was much like others reported, the dkim_key lookup, and can
be fixed by doing that dsearch lookup thing.
Providing a list of reported taint-issues and acompanying fixes like
that would be of great help to people that were rockin' Exim configs for
years and forgot about all the ${{acc}olade{mess}} therein.
Meh.
-Sandr.
--
| Broken pencils are pointless.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7 FBD6 F3A9 9442 20CC 6CD2
