On 04/05/2021 22:33, Evgeniy Berdnikov via Exim-users wrote:
> On Tue, May 04, 2021 at 08:39:43PM +0100, Jeremy Harris via Exim-users wrote:
>> On 04/05/2021 20:10, Victor Ustugov via Exim-users wrote:
>>> Why? Many years it was possible to execute queries to different SQLite
>>> databases. Why do you want to drop this feathure?
>>
>> The syntax doesn't fit being able to check for tainted data being used.
>
> Why? It sounds strange that *syntax* influences such operational details
> as presense of tainting checks.
>
>> We need to invent some new syntax in order to re-enable the
>> facility, and nobody has done that yet.
>
> What's the problem? Write down requirements and somebody will invent. :)
>
> Let's recall how parameters for LDAP queries are passed:
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html#SECID70
> If this is acceptable, why similar syntax could not be used for SQLite?
>
> ${lookup sqlite{FILE=/path/to/file <select...>}..}
>
> But in my opinion, passing file name as option
> ${lookup sqlite,file=/path/to/file {..}..}
> is more pleasant to read.
Having made me go and look... that is what I did, in b8514d1960
(which is since 4.94). A comma-sep option "file=/foo" after
the word "sqlite".
What I was remembering, and describing above, was the 4.94
situation.
The problems with the old-style syntax, with a bare filename
whitespace-sep prefixing the initial SQL word (eg. /foo/bar select...)
were
- not very clearly defined syntactic separation
- support for embedded spaces in filename
- existing parse code handled the entire { } lump
as a unit, and taint checking was only convenient on that unit
(and we want to taint-check that failname, if there is one)
I was wrong about "nobody has done that yet".
--
Cheers,
Jeremy
