On Thursday 15 October 2009 20:22:15 Jaroslaw S wrote: > 2009/10/15 Adam Pigg <[email protected]>: > >> 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... > _______________________________________________ Kexi mailing list [email protected] https://mail.kde.org/mailman/listinfo/kexi
