Yes, but its a positive match only - meaning you have to explicitly specify
allowed characters.The function should NOT be able to specify forbidden
characters - as then it would ve easy to miss bad characters.If an sysadmin
then writes a filter which is too broad - its his own fault.I mean - I have a
Email-to-sms gateway which pipes data to a system script.<number>@sebbe.eu is
interpreted as outgoing SMS.With the current structure, you need to add every
number you want to SMS as whitelist - as you need to do a successful lookup to
untaint.Its much better to be able to specify that localpart can only contain
numbers to be permitted to be piped to the script - no security risk as nobody
can escape out of a shell command with only 0-9 to their disposal.
-------- Originalmeddelande --------Från: Jeremy Harris via Exim-users
<exim-users@exim.org> Datum: 2020-11-11 14:00 (GMT+01:00) Till:
exim-users@exim.org Ämne: Re: [exim] tainted data issues On 10/11/2020 20:45,
Sebastian Nielsen via Exim-users wrote:> I think as I said, provide a untaint
tool, that allows custom data to verify> against.> > Like:> ${untaint(${var},>
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789")}No; this is a
bad idea.It is far to easy for someone to write a matcher which justuntaints
everything, disabling the security. Three peoplewould do that, and one would
post it on serverfault. Thenit would be cargo-culted forever.-- Cheers,
Jeremy-- ## 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/
smime.p7s
Description: S/MIME Cryptographic Signature
-- ## 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/
