[Kexi] pqxx and Kexi

[Jaroslaw S]

2009/10/16 Adam Pigg <piggz1 at gmail.com>:
> 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.

I have nothing against it so far. The only thing is that we may need
to keep the Driver::escape* functions (maybe with extra "encoding"
parameter) too, for cases when we want to encode strings before we
have working connection. That's assuming there's such a case in the
wild.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Libraries for MS Windows (http://windows.kde.org)
 http://www.linkedin.com/in/jstaniek