On 22/08/2022 17:30, Nick wrote:
> Regarding Andrew's reply, "so I doubt that [quote_sqlite] is intended to detaint": I think it would help to be clear in the documentation whether or not it detaints
The rule is: if if doesn't say it detaints, it does not detaint.
> specifically here:
>
>> This means that the query cannot use any tainted values, as that taints the entire query including the filename - resulting in a refusal to open the file.
That is talking about the lookup.
The quoting operator is a separate thing, even though it would be used in
association with the lookup.
> In which case either `quote_sqlite` needs to detaint, or the sqlite lookup needs to allow tainted query strings. (I would hazard a guess the former is safer.)
The latter. Hence the need for the new syntax.
(And no; it would be unsafe for the quoting operator to detaint data. It has
no knowlege that would make doing so safe).
> This is not to say that there is no way to detaint `$local_part`, just that there seems not to be one which would work for my use-case: I need some sort of wildcard match as I can't predict ahead of time what prefix an alias can have - there are an essentially an infinite, or at least a huge number of them, and this is by design.
You need a database of valid user_parts, in effect. A simple file would do;
it only affects what type of lookup you do in it. The lookup is your detaint
operation.
>
> Which means I can't use a simple list lookup, nor a wildcard lookup, as these don't support capture
In the current release of Exim, they do and you could.
> Is it the maintainers' opinion that when tainted text which *can only* be validated as safe by a wildcard or a regular expression (to use in, for example, a file path), it should nevertheless still not be possible to use that to detaint the validated text, in case someone else abuses this mechanism to create an insecure Exim configuration?
Yes.
> * Add examples of all the syntaxes supported by the sqlite lookup
> within the documentation.
Acceptable iff it does not bloat the documentation section excessively
and thereby make it harder to read.
(Footnotes would be lovely, but they require someone with *serious*
XML / XSLT / CSS expertise for an implementation for the HTML
docs output - perhaps as a slide-in sidebar?.
The PDF output does work for footnotes; I've tried it.
I've not checked the PostScript, and I have no idea what one
would do for the text output.
Since I seem to be the sole maintainer of Exim, it's unlikely
to happen.)
> * Likewise, an explanation of which versions of Exim support the new
> `file=` option syntax and which only support `sqlite_dbfile`.
The older documentation versions are still on the exim.org website.
There has not been a general policy of annotation with "since version x.yy"
and implimenting one would require a large initial effor.
Who will do this?
> * Add a warning that the old syntax is obsolete, when used.
Warn where? Logs?
Not infeasible. Bound to elicit screams of anguish from people
not wanting to change, especially when they don't happen to be
using a tainted lookup arg which taints the filename.
> * Clarify the error which seems to suggest the filename, specifically,
> is tainted. (In my case the filename is not the problem so it is
> misleading.)
The filename is tainted by the time it gets to the point of check.
Yes, code can always be complexified. And bugs added in the
process.
> * Add support for the new `file=` lookup syntax in the 4.94
> maintenance branch and/or Debian 11 - or if not, at least an error
> which states this syntax is not supported (although is present in
> the documentation)?
The Exim project does not have a "maintenance branch".
On occasion, specific backport branches have been created for
security fixes.
> * Add support to Exim for a regular-expression detainting expansion as
> in Perl, in order to support cases like mine which other lookups
> can't handle?
No. It would instantly be abused with an "accept everything" wildcard.
--
Cheers,
Jeremy
