[Kexi] pqxx and Kexi

[Adam Pigg]

On Thursday 15 October 2009 20:22:15 Jaroslaw S wrote:
> 2009/10/15 Adam Pigg <piggz1 at gmail.com>:
> >> This move was made necessary by a security fix in libpq itself.  As it
> >> turned out, its escaping function needs to know the encoding the string
> >> is in, because some multibyte encodings have characters that contain the
> >> byte that in ASCII or UTF-8 would have been e.g. a single quote.
> >>
> >> So for example you might have a two-byte character consisting of some
> >> byte X and one that matches the ASCII character "'": X'
> >>
> >> In that case, the naïve previous escaping function would just double
> >> that byte to "escape" it, producing X'' and voilà: a closing quote has
> >> been injected into a string--by the exact function that's supposed to
> >> prevent it.
> >>
> >> I think your options are:
> >>
> >> a) Write your own escaping function based on your own knowledge of the
> >> encoding that the code is going to run in.  I suppose Qt has some
> >> facility for breaking a string in the current locale's encoding down
> >> into unicode characters.
> >
> > Jeroen,
> >
> > Thanks for getting back, is it just the ' character which needs escaped
> > by doubling it?
> >
> > In which case, a QString::replace() could suffice, Jaroslaw, the main
> > kexi dev can advise on that.
> 
> Guys,
> Thanks for continuing the discussion here.
> QString::replace() works in test cases but in pessimistic case it's O(n^2).
> I do recommend using const QChar * QString::constData () const-
> iterating over the \0-terminated list.
> 
> If we implement our escaping (doesn't libpq itself have it if not
> libpqxx?), it's good idea to implement at least
> KexiDB::Driver::valueToSQL(), escapeString(), and check if
> escapeBLOB() is OK.

I think in this case libpq wouldnt help because it is libpq's requirement to 
have a connection to be able to escape properly based on the encoding of the 
database. (?)

Does mysql/other db's we support not have the same issue?  Could the proper 
solution not be to move Driver::escape* to Connection::escape*, that way 
strings could be escaped based on the encoding of the connection in use.


> 
> BTW, there's another job regarding pgsql support: the driver based on
> just libpq. Unfortunaltely that was never delivered.
> I think we would get benefits from going this way eventually
> (efficiency since you can see we have to implement some low-level
> features anyway).
> Either I find someone interested or myself I'll be back to this task
> after 2.2...
>