[webkit-dev] Blacklisting some sqlite functions

[Chris Evans]

On Thu, Jan 7, 2010 at 12:13 PM, Dumitru Daniliuc <dumi at chromium.org> wrote:

> in addition to these standard functions, we'd like to whitelist some
>> functions from a few extensions chromium uses:
>> full text search (fts2.c): whitelist snippet(), offsets(), optimize(), but
>> not fts2_tokenizer().
>> unicode data (icu.c): whitelist regexp(), lower(), upper(), like(), but
>> not icu_load_collation().
>>
>>
>> Is there any reason these are still Chromium-only?  Even though we're
>> having problems getting different vendors to agree on SQL dialect issues
>> with the spec, I think we should make an effort to keep WebKit unified.
>>
>
> FTS and ICU are sqlite standard extensions that live in the sqlite tree.
> Chromium compiles its own sqlite library and includes these 2 extensions;
> I'm not sure if they're included in WebKitLibraries/libWebCoreSQLite3.a
> though.
>

[resending from @chromium.org]

Probably not. Last time I tested Safari for a sqlite-related security bug, I
didn't see any fts or icu extensions.
Chromium uses icu and fts2 (even though there is a newer fts3 module). These
modules are useful to offline apps that want powerful text indexing and
search.

Isn't it every WebKit consumer's own job to deal with which version of
sqlite to use? This is unfortunate because there are a lot of factors here.
For example, we get grief on Linux for not linking to the system sqlite
library. However one of the problems with doing that is that these sqlite
extensions are compile-time options that are often simply not compiled in.
etc. etc.


Cheers
Chris


>
>
>> I'm also going to forward this message on to some of our security
>> colleagues at Apple, and we might have more feedback shortly.
>>
>
> great, thanks!
>
> dumi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100107/a632266b/attachment.html>